 Yeah, okay. Yeah. Yeah. Wait. What is that shirt? Yeah, I think we need to make some kind of initiative shirt I think if you live more than at least All right Alrighty, hey everybody Good afternoon we're gonna go ahead and get started once again. This is a farewell to twig and This is a core conversation about the current state and the future state of our theme system First things first. We'll go ahead and introduce ourselves starting with Lauri Hi, I'm Lauri. I'm a software engineer I currently live in Bangkok, Thailand and I've worked for Acquia in the office of the CTO Great I'm Matt grill JavaScript engineer at Acquia offices CTO as well And when I'm not writing JavaScript, I'm crashing my bike My name is Preston so I normally have an extremely long bio that nobody ever has time to read so instead here's a Jeff One thing that we want to note As you can tell we're gonna have a lot of fun today One note that I do want to make if you are interested in these kinds of topics If you're interested in decoupled Drupal if you're interested in what these weird pink shirts are that two of our friends are wearing here We're having decoupled Drupal days again this year in New York City in August and we'd love to have you there If you're interested in speaking if you're interested in attending if you're interested in sponsoring Please come and talk to me afterwards. We'd love to have you Yeah, so a little bit about the the problem space and the questions that we are gonna ask today And maybe some of this gets answered on our presentation. Some of it can be Answered by you during the conversation that we are going to be having after the session but what we would like to focus on is that We want to figure out if we as a community should put more focus on decoupling than trying to create a monolithic application That could solve all different aspects of the front end development We are not sure if we even Could could proceed with the with the current state where we have one solution that that Tries to work for everyone We also know that Quite a lot of Drupal users are being using Drupal for decoupled purposes and there is a lot of complexity that comes from from from that How could we reduce the complexity that that? it causes that we have multiple different approaches of building front ends A little bit more about the problem space and Few key issues that that we have realized So we get we assume that we would like to have unified unified way to render on both client and server side Currently we don't have that Also, it's important that we have both because of if we only render on client side We cannot support browsers that are not JavaScript enabled also it's important for performance and let's say Indexing web pages is getting better on client side, but it's still a thing over there that they use the server side rendered Server side rendered content So it's definitely a valid use case still to have both of them enabled Also another question that we have to have to find answers at some point is that Which subsystems we have to be able to share between client and server are we going to have wrote routine surfed Working on both will we have rendering working on both we will have templating working in the same way on both This is all something that we have to decide later on also a big big question big topic is How can we build a unified way to serial serialize and deserialize data on both client and server side currently Are our back-end and client rendering? Works very differently From each other. There is no unified way to do it So this Corcom station is about figuring out if it's the right way forward if the current team system that we have is the Right-way forward. This is all very Experimental we are this having discussion about these topics. We are not saying that this is something that Will happen or that we someone will make it happen, but we want to have the conversation at this point yeah, so One of the things that happened a couple of years ago at previous core conversations We've had and discussions around decoupled Drupal is that there's a very big trend right now That has been ongoing for a very long time at this point around shared Templating and shared rendering and JavaScript. This is of course known as universal or Isomorphic JavaScript and everyone kind of got really crazy and said, you know, we really need universal JavaScript And it's the way forward. It's the way that we're gonna actually build modern applications that straddle that client server divide but You know one of the things that a lot of Drupal has said at that time was why don't we try to do that with twig? we just had a huge amount of amazing work to bring twig into Drupal and Why don't we see if there's a way that we can share twig across client and server because that is really the holy grail That is the way that we can get people to work On their templates in a way that is as close to universal as possible But there's a couple of problems with twig and I want to be very honest here And by the way for those of you in the back If you want to come and sit in these areas over here, there's some empty seats up front here some empty seats on the sides I always hate to see people standing. It's Anyways, so what is the problem with twig? You know twig has been great for us since Drupal 8 was released But one of the issues is that a lot of these other Templating systems that currently exist in the web development landscape like JSX like handlebars like angular directives in the way that you template an angular both of those All of those templating languages and all of those templating Technologies actually have equivalents on the client side We have one allegedly for twig which is called twig.js But here's the problem with what's happening in terms of the clean break that we have between twig.js And what's happening in Drupal's implementation of twig? right now, but our Drupal version of twig has what I would call a natively server side Focus which means that whenever we are going through the rendering process in Drupal We are assuming that all of the things that we do in twig are going to be generating a server side Output that eventually gets flushed to the browser But one of the things that we would need for this to happen on the client side is that we do need a natively Drupal twig JS implementation for this to work right now There is a bit of a difference between our own PHP Drupal implementation of twig and the twig.js framework Whereas if you look at a lot of these other templating languages They are natively client side from the very beginning from the get-go. They focused on client side templating it is primarily that that is their emphasis and Merely adding on a server side renderer Grants the ability to provide a server side rendering of that template So the way that we're thinking about it these days and the way that JavaScript developers are thinking about it these days is Backwards from how we have been thinking about it before So We believe here and once again, this is you know not meant to suggest a way forward or for us to you know Advocate that this is the way that things need to work. It's to open up a discussion We believe that Drupal should be treating client side rendering as a first-class citizen And it is our goal today to talk about how that could look and how that could work with all of you Since we got you all in the room with this provocative title so There's always a question of so can we use PHP to do some sort of like JavaScript bindings to render templates on the server and The answer is sort of if you've heard of PHP v8.js, please raise your hand and If you have ever used PHP v8.js to do anything keep your hand up Great. Hey, Sam Why am I not surprised It does work you can render Js stuff you can render react and build context and do server-side rendering from PHP with PHP v8.js and do that But it is a back-and-forth and back-and-forth process and it's not the best so Why don't we use Twig.js or other client-side libraries and this question has come up at Literally every Drupal con I've been to in the last like three years and in the beginning Twig.js didn't support hardly anything that we were doing with native PHP Twig implementations But it's also like completely different from how We do sort of server-side twig with like render arrays and all that the way the data is Abstracted to be rendered in the twig template and template includes which Larry told me is now fixed Which is a huge thing for a long time so it's You're gonna be in for a big headache to try and do to use the same template to use on the server if you try and use Twig.js so I was here. Yeah, so some more of the specific problems that we've figured out and some solutions that we could potentially propose for those So the Drupal string implementation is very tightly coupled With the with the front end Meaning that it's not very easy to replace twig with something else We are proposing as a solution that we would use web services as a bridge between back end and the front end instead and Then you could use twig or any other way of rendering As you wish Another problem statement is that front-end developers can't choose to work with what they want at the moment Basically, we do have the concept of team templating engines But it's a very complicated process of choosing to use any other templating engine engine done twig If we would move to a rendering layer that allows us to render both on client and server and is also Has the Unified way of transporting data through APIs It could be easier to use another templating engine Because of because of the problems that we have it's too complicated to work with every It's too complicated for for users to work with every JavaScript Framework so that if we support every JavaScript framework it could mean potentially that every developer has to work with every JavaScript framework, but What we are proposing is that is that Drupal would would ship with only one Drupal front-end which could be react or or view or or twig and People people could then build their own implementation and we we would try to enable them to do that Just you know me to switch to slide I just have one additional thing on that last point and that is so from Vienna if you were in Drupal on Vienna We sort of made the announce the decision and the announcement that we're gonna work with react Sort of an experimental capacity to develop a JavaScript based API powered front-end for Drupal That's not like not forced to use it It's we're working on it right now and that plan sort of is to integrate sort of all the capabilities you can do in the UI Into the API so you can build your own front-end if you'd like so Yeah, I guess I just literally said this slide But you know from Vienna we decided to pick react Because the people that were there and from a lot of the input from the community seem to be you know react was very strong It's a lot of great benefits. I really don't want to talk about that right now But the nice thing too is that the tooling around server-side rendering for react is really great and it's only getting better and faster So if we're going to use those same templates on the client you can also use them on the server and get an identical output Yeah, JSX is just Reacts templating language and if you're familiar with HTML you're probably familiar with JSX Yeah, and this is nice too is that I think what we'll find when we get to this point of building all these pieces is That the front-end will be a side effect of creating great APIs and the API part work that the API the API team is doing Will be able to enable us anybody to build a front-end either a reduced functionality set or a very robust piece Because all those things all be exposed So Yeah, there has like definitely in the past been some level of Frustration with a suggestion that we're going to put JSS JSX and Drupal core I'm I don't I'm not here to try and like assuage your fears about that. It's will happen So it's if you have questions Sorry All right, yeah, so Common question that I've heard is that shouldn't be explore bearing twig with react first Which is an option I guess but yeah next slide yes Combining the twig which react comes with huge downsides as well Even though it might sound like a good idea to use twig with react I've explored it. I I'm actually maintaining a library which bridges twig into react because I needed needed it in a project but yeah, so I know how it's like and It doesn't break And and there's also huge problems that would be triple specific not even specific to do the react like We would still have to solve big that the problems related to to do it Especially but we would also lose big part of the benefits that we act you know brings Yeah, a Good question To think about ourselves is that should we abandon templating languages altogether? What is the benefit of having any templating language itself at all because of template languages come? Huge overhead always it means if you have templating language It means that everyone has to learn a yet another language In which they have it right code they come with some downsides obviously such as like not You can go to the next. Oh, yeah, such as Not not not supporting all all different use cases because of the language might be limited Like let's say twig might not support all of the things that you can do in PHP and also what we say is that one of the major benefits of Having templating languages that it will be more secure or it will be It will restrict what people do in the in the template like let's say that they don't do note queries in their template But that could be simply avoided by just not doing it. I mean Why do you have to set these? Limitations in templates if people want to do note queries in their template I think it's their own problem to be honest like Like it's a huge overhead. We pay a very big price for for the fact that you at that we have Have the limitations in place and One of the other issues of course is that in a lot of ways the JavaScript ecosystem has really pushed forward on a lot of These ideas we see virtual DOM VDOM we see a lot of implementations of on-the-fly rendering that are extremely powerful and you know quite frankly Put a lot of the front-end implementations Out there to shame because of how performant those are and one of the things that is a big concern is do we feel that twig? Js or some other front-end can offer those same benefits of on-the-fly rendering on the client side yeah, so from the community of There are some tooling. There's some tooling out there already twig graphql I Mean listen you shouldn't put your business logic in your templates if you're doing that you're already having a bad time So there's a tool waterwheel.js, which is originally developed as a helper library around cores rest implementation It has some JSON API helpers to and some authentication pieces Made this so It's a thing the JS triple. This is the sort of organization and JavaScript modernization initiative Projects we are building a decoupled admin interface right now and trying to tackle literally all of the challenges that we've just talked about Today and if you want there's a session tomorrow where we go over all this and react twig This is the thing that Lowry created which does a thing for wrapping twig templates in rack components He says don't use it You know it has three stars on github only three Yeah JS modernization initiative is like notoriously Underheld right I think there's you know, there's some of us and then we could always use more So if you're amped about JavaScript and you also like Drupal and you want to work on this Sally and Daniel are right there and I'm right here and talk to anybody else Yeah, and we're doing a lot of really cool stuff Cool. So that's it for our content. We'd love to open it up for discussion now Just like a traditional core conversation If we could ask that people use the mic here and we're gonna do something a little different today I'd like to try out what's called a progressive stack What that means is I'd like to ask that all women come to the front if you are male Please go to the back. I want to hear from voices that are not typically represented If you are a person of color, please come to the front if you are gender non-conforming or Trans folks, please come to the front and we'll start with that. Thank you very much I have a very simple question and maybe I didn't quite get it from this from your name My name is David Wong. I I don't work anywhere right now, and I have a question my question is if You have if you had to boil down in a single statement the fundamental question that you're trying to ask at this particular Gathering, what would it be? It would be how do we make client-side rendering a first-class citizen? Indrupal in a graceful way Why does Drupal still need a front-end? Thank you, man. That was my not really question, but what I want to say is the reason oh Daniel I'm working for a three-letter company the reason why I think People have the perception that like Symphony is really easy or like why We act is really easy or embo or anything beside Drupal is because All these projects and all these approaches have limited scope and in Drupal we don't have this limited scope right now We do want inline editing but we also want to couple the APIs and We want content modeling, but we also want with civic editors And I I want to open up the question asking whether we forever want to like cover both and all the multiple dimensions of use cases and whether it might be actually way better for long-term success to more focus on let's say our content modeling and Our like API strategy while still having like a default simple front-end So I made this point Couple of years ago or about a year ago at Baltimore, which is that you know I Think that we need to have a serious discussion about whether or not we need to have a clean break in Drupal We've had this discussion quite often And I think one of the things that I've said multiple times is do we need to have? Drupal 9 be decoupled out of the box what I mean by that is do we need to have a canonical Drupal back-end that provides APIs and then an optional front-end right something that you could opt to use if you need those Things like in-place editing and layout building But that would be something written in you know some technology that we choose such as react And work on that as being completely fully decoupled The reason for this is because if we try once again to include another template language a new templating language we're going to have the exact same problems of complexity that we had before and I really want to avoid the scenario where we are stuck with Front-end technologies that we have to maintain well into the future Why don't we give that optionality to the developer have Drupal provide a single front-end that is an optional front-end and Make everything else API driven solely Had a lot of thoughts about that but that's what we came up to yeah, yeah Ted Bowman work at Acquia Ted bowman drew part or the other thing the thing I actually wanted to come up and say is that I feel like the JS Drupal is a bit of a misnomer and since like the end goal is a better UX, right? But also I think it for people who are interested in getting involved There's a lot of help that needs to happen on the PHP side to improve like Exposing the API is there's a lot of help needed on the UX for like designing the UX So if you're not a JavaScript developer, but you're interested in JS Drupal and improving the admin interface We need a lot of help. We have a support module Drupal module that exposes this stuff we could use help on we eventually want to get some of that stuff into core So if you're a PHP developer, but you want to help this project There's a lot of need for that if you're a UX person There's a huge need for that and probably other things. I'm not thinking of so yeah, thanks Ted. Yeah, that's great. Yeah Yeah, so Tim we need timid wit underwood.org. I work for Nasdaq right now, but I guess my question is we we are changing one debt for another debt, right and it's actually just Making it more obtuse in some ways right now you need to be a Drupal developer on the back end and now a react developer on the front end and What you know, how are we as a community going to keep that out of the box experience nice? Obviously, we want to bring in more communities, right? We want to say like oh your react developer Or this or that but how do we also keep our core? Community without another thing that just is like this big impedance because templating engines We're very familiar with them like the twig PHP template to twig update Wasn't too large. I mean it was big. There was a lot of effort that was put into it But as far as moving into it if we could really see the path forward the renderer raised state and all of that so For better or worse, whatever Neither here nor there, but how do we maintain the core community and the developer out of the experience bot like experience out of the box experience without sacrificing Kind of just more overhead because one one man shops, right? Like that's a huge part of our community now You're asking that one guy to be like all right now You have to get familiar with react and how that templates and you might just need to change this So yeah, you have that out of the box front end But how maintainable is that for one dude or one lady or one person non-conforming I? Mean I think if you watch the keynote yesterday, I mean it's we need to get off our island right and the island that we've been on for so many years has been PHP PHP template and twig and render arrays and Even just Like something if you know a lot about Drupal and you know a lot about how Drupal's like sort of PHP system works You may not really understand how twig works Right and the theming and all the stuff that goes into that and I think that it gets That that system has sort of like lagged behind like pretty substantially and the way the web has moved forward itself is I mean Yeah, so I'm gonna take on that as well So what we are talking about is Making all of the front the front ends that Drupal has decoupled It doesn't necessarily mean that you would have to use react or react would be the only option to use as a front-end It's just making sure that The twig twig implementation that we have would be decoupled as well In a way that the way that the data gets transported to twig would Happen in the same way as it happens for for our order order from ends and I mean if there is momentum around twig As a as a front-end it could be one of the options and then there would be very minimal change for Yeah, the developer experience the side effect of all of this is the front-end the real work Is what Ted mentioned? It's the really robust strong APIs that allow you to build a front-end in twig with to JS or react or any of the other you know oddly named tools and And just to kind of jump on this last point You know one of the things that's interesting about the way that the web development landscape just to zoom out all the way To the big picture is that the amount of complexity and the amount of knowledge You have to know at this point to be a quote-unquote full-stack developer, which is a total misnomer today is Colossal I mean you literally have to basically have the library of Alexandria in your head to be able to know how to Write a rest plug-in and also know how to create React component and also do this and that so you know from my perspective I don't really believe that You know you can be a specialist in every single aspect of the stack today it's just an impossibility and We have grappled with these sorts of things in the past we brought in jQuery We had a lot of our themers who were used to only doing PHP template learn jQuery a lot of these things happened in Drupal And from a human perspective in the Drupal community. We want to set everyone up for success We want to make sure that we're learning the right technologies and getting to the point where you know Your skills are something that are going to stay up-to-date in this in this very fast-changing landscape so my opinion is that if You are a one-man shop, you know if you are sort of a of a sort of a one one person shop You know why don't you know? We look at some of these ways that we can enable you to only focus on react and leave one of these You know leave the API is up to something like contenta or up to something Like a web services distribution that allows for you to innovate much more rapidly. I think at this point We have to acknowledge that There's just no way that you can know both the front end and the back end Completely at this point. There's just there's just there's just no way I think Hi Mark drummond I do front-end development at Lullabot Let one of the last projects I got to work on I did a react project was my first full react project as a progressively decoupled portion of a larger Drupal site and and it was a pleasure I Really enjoyed, you know being able to start with Jason as my data and being able to you know Crypt you know put together all the components I needed around that and that was great I This is the session. I have been most anxious about for all of Drupal con So and frankly everybody I've talked to about this has been you know, I'm sorry But about ready to flip a table over this Not an HTML table But So If this was called a farewell to twig parentheses For the admin side of Drupal like I Totally hear you right that makes a ton of sense like if you're gonna be doing redoing The admin aside of things and react which I think is sounding like it makes a lot of sense and everything like that Trying to reuse twig for that just like it sounds like bonkers town right like and nobody needs that that just sounds totally Painful and so I have no concerns about getting JSX and stuff like that in there For that side of things but that's an entirely different animal then the front-facing portion the public-facing portion of a website and And I know that like within core There's a lot of work that has to go around the admin experience and so that can seem like the most important thing but for most people working on Drupal sites, it's the front front-facing portion of the client site and And and not all of those need to be decoupled sites. I mean D. I think decoupled is fantastic when it makes sense And and that's great where where we can do that and we should totally like make Drupal API friendly and do everything We can to make that a great experience But I I don't know what the exact percentage is if it's 90 percent 95 percent of sites that probably don't need to be decoupled sites, but there's a lot and For the most people, you know, twig is great people were really excited about twig We put in a ton of time to make twig, you know, and and it's not all roses But I I think I think if you did separate out and had not twig for the admin side That probably actually gives a lot of possibilities for improvements on the client-facing side because right now It is challenging to theme Drupal sometimes because all of our theming is based around data structures And that's a large part driven by the admin side of things and like if we could change things around and have like a more Component-based architecture and twig was still on the front end of that. Maybe you know that there could be great opportunities there but I think if you're talking about throwing twig out when we've got We've had so much effort to get there and for a lot of people that's one of the things They're happiest about with Drupal 8 on the front end. I think maybe don't you know throw the baby out with the bath water and and think about like the separation between the two and Yeah, and I guess the only other thing is is on the admin side I just want to you know understand about There's times when you need to override things and like how we would do that when in a react world I don't know Can I ask a quick question just so when you mean decoupled do you mean decoupled as in React JavaScript or do you mean decoupled as in the way that we transform the data between our front-end rendering and the back-end I Guess I don't fully understand I mean if you're saying that like we get some JSON and then we like put some Theming around that like within the Drupal server side. Is that what you're talking about? Yeah, like because there we could decouple and use twig as an option to render still Yeah, I mean I guess I'd just be curious how that's gonna work Like if that's just happening entirely on the server or you're having to make you know client requests over a rest API I'd have concerns around so around that but yeah, so the serialization would happen in a similar way So we would use a serious Serialized way to transform to transport the data for the templates But other than that it could be similar to what we have right now I don't fully understand that so like let's say transport and node object for the template and use PHP Methods from that so that couldn't happen, but other than that the experience could be very similar. I Want to learn more and I'll sign up for your newsletter, so I don't know yet, so but thanks for talking about it. Yeah, thanks Mark And I also want to say thank you to those who who have we stacked aggressively here and let Some new voices come to the front. Appreciate it Uh hi I'm Sam and I've been working on Like a web component twig integration just like as an experimental project And yeah, I ran into twig.js performance issues and so far the only thing that I didn't make but I used was Like template pre-compiling in the JavaScript so that the client actually doesn't process the template string So that's a good start. It's kind of like PHP's twig caching But I was wondering what performance enhancements would need to happen to twig.js for it to be considered viable for your project I would say You know a bare minimum is something that is competitive with Dom-diffing that currently exists right now or some similar kind of performant rendering Just because you know right now in JavaScript all the rage is performance right performances all the rage It's important people are not going to opt to use twig.js if it doesn't provide a means to Render on the fly in a very fast and performant way. I don't know twig.js very well I don't know if that exists. I don't think that exists and please yes But that would be I think an important first step Yeah, I mean I think the thing is that twig and twig.js kind of just look like handlebars to me and Though it's take your JSON blob and apply it to your template and get HTML back Right, and then every time you want to restructure. It's new JSON re-render your whole template re-insert and that It's almost equivalent to like doing a round trip to a server, which doesn't feel very great to me and It in my opinion, that's not where the web is going. We're moving much farther away from that. It's like every day Yeah, if they could do something like that then sure, but then we might as well just use some of the other things so and I think one one crucial point here that I wanted to bring up from earlier is that You know when when when we talk about a sort of clean break and decoupling Drupal out of the box We're talking also about the need to maintain backwards compatibility I think that's what Lauri was referring to earlier when you know We would need to have some kind of a twig php front end that is one of the canonical front ends that people use To enable that kind of backwards compatibility Thank you in a way you've answered one of my questions and the other one was I'm sorry. I'm Michael and as Taking couple people here we I mean pretty much many of these issues we are talking about I mean we can fix them if you want to but I wonder if this discussion is guided by Some kind of data on what would be the implication if if we switched from say twig to something else and How would we stack up to the competition cause? Drupal 8 as as we keep building it will become this huge application of this and and and you find that smaller shops or A Freelancers might find it difficult to to present it as a solution or as As a solution to certain types of clients that they have so have we we have any Kind of information or data that we that we can go by that has that get that will guide this discussion the future I Don't I mean I don't think we have any Like hard numbers to suggest That this is the right path forward I mean the only thing that I can Say is when we decided to pick react we got a bunch of people from the community and got a bunch of sort of issues and conversation around that and Sort of it was the one that a Seemed like the right choice and had people excited about working with it as a technology So and there are some intrinsic issues with performance benchmarking a lot of times people look to things like to do list Rendering as a means to benchmark But there have been flaws called out in that methodology There is no single way to Benchmark JavaScript performance or to benchmark rendering performance in a way that really gives us empirical data that we can really confide in I think that as a result, you know what we would need to do for us to get that robustness of data Would be to take typical use cases that exist in Drupal today You know that could be something like let's take a very heavily themed view or You know something like that look at how that would be re-rendered in each of these things on the fly on the client side based on a change in the configuration or what have you and Determined based on that what would happen because we won't be able to get a realistic sense of of this from just doing to do lists or You know rendering rows Hi, I enjoy decoupling and do some interesting projects with react and have fun with it, but I Feel like If you just just based on some of the comments that people are saying and where we're going in general people are saying like Oh, you can't even be a full-stack developer. Everything is so complicated and we have to learn this and this and all this complicated stuff It's like when you look back 15 years ago, and we were just writing custom PHP and pushing it up to FTP on Dreamweaver Those sites were just about as good as the ones we're doing now They're not we haven't like really accomplished a lot with all this additional complexity other than we're charging people you know 20 times more than we were before we're doing all this work But like my clients are still mostly coming and saying that they want to show their upcoming events and their news and their their campaigns and their staff bios and I just feel like sometimes in these fun like technical Interesting conversations. Are we forgetting like? What we're actually building which is just like websites for people to just read stuff and like sign up for a mailing list That's how I feel Does one of us want to respond to that I Mean I think a lot of the benefit here is hidden in the developer experience improvements But I think that's number one. So I recently started working on rebuilding my own site and react and immediately one of the things that You notice is that yes, I am building a normal website. There's nothing special about it I'm not building some, you know whiz spang, you know Facebook clone or Twitter thing or you know sports live feed I'm just building a regular content website But the you can already tell that there are certain performance benefits that come into play when you click on a link You don't get a blank page. It's instantaneous I mean you are you know that in and of itself is a huge performance benefit that is available in Drupal right now thanks to refresh lists and And and some of that work, but it's it's something that is standard now across people who build websites in react and More and more these days you're seeing people building Literally pure content websites in react and in these technologies. You're you know, that is something that we do have to acknowledge and take a look at But I certainly Agree with you that you know, we shouldn't inject more complexity just because we want to play with the coolest things and the really nifty things There should actually be a lot of rhyme and reason to it And I think one of the questions we have to answer is does the benefit of adding this and let's say You know to some people Providing a means that brings us into a more modern landscape Potentially or gives us a better developer experience or a better user experience. Does that outweigh? The drawback of the added complexity. That's an important question. We have to answer obviously I Wanted to go back to the point which we had previously about the community aspects of it I think Like the people which are already building the corporate sites I mean yes, there might be problems, but they are like minor problems in quote in like compared to like the overall problem of like people Not having modern Well, no, I won't don't want to say that but like people which are like used to like a more common stack and I think Like no matter which technical solution we pick like all of them will work in some way I think the actual hard problem is like a deciding whether we want to go there and be like if we decide that How do we transition the community towards that? How would you advocate people like like how do we get the mindset? How would you change the mindset of people to think the coupled right to start with the content model first and We'll move the like rendering aspect in from your content types for example And I would like to propose at least a couple of ideas. We have the umami theme Why do we not have the umami application? Which does exactly the same thing as in you render the umami Magazine we put that maybe in core by that we dog food ourselves. I think we really valuable We could we could do the same with the editor UI, right? We could have a dedicated UI Targeted towards the recipe magazine Sure, nobody would use it in real life, but like it would still be dog fooding and Be maybe produce the components which also the admin UI thing will produce components And then like people can pick them up and I think by having like small steps We we could move the community on the long run into a better future where those Just like throwing them them into cold water wouldn't work Cold water Yeah, I mean maybe I Mean don't you think that like the sort of read-only decoupled front-end problem is kind of solved already? Yeah, it's a demo This is what you want No, I want to wait for I want to wait well I want to wait for the community to move along like to want to wait for For the community to learn Yeah experience so the reason why for example redux is used is because sorry redux is a thing in react Yeah, it's a it's a kind of a complex thing in react and People like which just start with all that which I've never used it Don't see the reason why it's there or like don't see why it's good and I think In react like making the process of like Making these experiences and then like stumbling upon react redux and see oh, yeah Yeah, that's actually a thing which solves these problems I think we as a community need to make the same transition process as in we see that like our Rendering's I mean that's what we see right now right or a rendering system and player configuration and trick templates and cleaning system All is so super complex and we make the experience that this is not the way to go and like much We will make the experience that like pure server side trick rendering for example But in a take up it way it's also not the way to go because we need JS rendering But like I think we as a community make to have to make the experience and we need to direct the community along In order to be actually successful on your own one That that's something that I think would be a lot of fun to work on Well many more people Hello, I'm a tail. Thank you for the session and for opening the discussion I have a bunch of thoughts that have been piling Gonna summarize them really quickly I think that we should not underestimate the boredom of the engineer like we don't keep doing the same thing that we did 15 Years ago, right? We we need challenges and we need to stay passionate in order to do new things and You know create new UX patterns and implement them in a performant matter also wanted to to say something related to what that mentioned about Needing help in different layers of the JS Drupal We just got out got out of a buff where we for the API first initiative where we discussed Ways that we can better help in these two. So if you find yourself in the In the urge to be creative and you're bored and you want to do other stuff just reach out and maybe we can find a way to collaborate all together and Finally and more targeted to what you were saying I've got a question. There are many things that come with the monolith and I guess that you would not expect that for me, but They are very good reasons to stay in monolith and maybe we can learn some of those When we go decoupled because because it's happening. It's gonna happen eventually or that's my opinion I was in a accessibility session yesterday and It was highlighted how the umami theme had like very good things added in there and that kind of struck to me that we are providing good examples on How to and helpers more importantly on how to build a lot of things that go for free in Drupal, right nowadays so and This is the question Do you think that we should really still provide a front-end that implements all of these features and serves as the starting point so We know that Drupal sites or Whatever this is called in the decoupled apocalyptic picture feature Should start from is that something that we should leave to another project to Care about and implement all these features, or is it our responsibility? It's a very good question I think it would be pretty radical if Drupal wouldn't come up with way of rendering in Inside its main package. I don't think we have discussed of that option at all yet. I Don't think any of us is arguing. Sorry go ahead Mateo Sorry, I guess that I got that idea from a comment that said Then we could use any front-end in maybe Drupal 9 Maybe it was mentioned and by any front-end that kind of got me the idea that there was known That was preferred. So maybe there was wrong. Actually, there was another problem statement which said that I Would have to learn all of the different JavaScript frameworks and on that one we suggested a solution that we would come up with the one Which we choose to use in core but we would would enable anyone who wants to use another approach and When we have this way of rendering in court, of course It allows us to provide the examples as well with it with it But if you don't have a way to render inside Drupal course, that are difficult to provide any examples In what should come to literally no surprise to anyone in this room. I think they should be split I don't think any of us is advocating for Drupal's Feature set to be reduced to solely back-end concerns. Oh, no, I am. Okay. Well, all right. Well, obviously We haven't discussed this prior to this But what we are advocating for is, you know that we decouple by design and have or at least I am Let me just not speak for loud now that I just spoke for them and you know, obviously not real You know, you know, we should have those back-end concerns covered But for everyone who trusts in the Drupal monolith, I think, you know, you raised a very good point Which is that people get a lot of benefit from the monolith people like the fact that we have in place editing and it's all Tied together people like oftentimes that the Drupal isms leak out to the front end because it makes it easier to theme and easier to style We need to keep that in place to some degree. So what I'm saying is basically we need a You know decoupled architecture that is that looks monolithic But that you can but okay, so you know what I mean, you know What I what I mean by that is that under the surface it is decoupled But for the user for the for someone who is working with the system for all intents and purposes It acts looks talks feels like a monolith Brian Yeah, I'm a Brian Perry. I work at HS2 solutions and you know some of these concepts are definitely attractive to me But you know as we've talked about Providing like a twig rendering option, you know, that does seem important I think about people that I work with people walking around here who would be sad if that didn't exist But but like maintaining that and another option at the same time like that sounds hard I wonder how that would work and then that kind of got me thinking that You know, maybe there's a subtext here or You know something else Potentially behind this or like a conclusion that you have to reach here That part of what we might be saying if we're talking about this is that we think that You know having Drupal be decoupled first or making that more of the primary focus is like critical to the success of the project and our ability to grow and Maintain relevancy so yeah, I just haven't heard people say that out loud So it felt good But yeah, I was wondering if you guys agree with that basically So just to be clear, maybe I just wanted people to clap. I don't know so so sorry Just just to make it clear what you were saying. So you're saying that do do people feel that We need to even make these changes and Drupal should keep on the trajectory that it's on is that sorry? The other way so we should Go in this other I actually I'm just curious to What side do you guys fall on? I mean I have a guess But I just haven't heard people say it out loud as far as like that a motivator to to some of these things might be You know the relevancy and health of Drupal's project. Well, let me put it this way in my experience selling decoupled Drupal sort of you know consulting on decoupled Drupal deals and And and and advising a lot of aqueous customers What I can say right now is that there is absolutely no reason that somebody who is looking for That application like experience or that kind of user experience is gonna opt for Drupal unless they already have pre-existing Drupal Expertise on that team and that is solely because people perceive of Drupal People perceive Drupal as something that is almost too big for its own good And almost too packed with features for its own good That's why people are going for you know symphony API implementations or some of these things that you see now in the wild So I do think that I will give you a you know my Full I don't want to make anyone uncomfortable. I mean no, no, no, but but that is my belief I think that if we don't do this and I'm gonna be forthright here because I think that you know We all should hear it. I Think that we're in a lot of hot water if we don't do this I do hot water. That was strong very strong I'm trying that too. So I just want to ask question from the audience. How many of you have Experienced with decoupling Drupal Quite a few and how many of you had fun find out decoupling Drupal difficult or hard Almost everyone and that's exactly the problem that we are trying to solve We want to make the couple in Drupal easy We don't want people to think that the couple in Drupal is difficult and once we make Drupal decoupled out of the box It means that it will be easier because we have figured out the solutions for the hard problems already by the by the core team itself So I'm also advocating that we should be trying to solve these problems I don't know how it's going to look like in core in future. That's something we will see but So we only have three minutes left. Maybe just one one more point I'm very sorry to those of you who are still in line. We can talk afterwards. Oh, no, this is going to be the loaded point So Michael Babkar. I'm Juma was released lead right now A lot of what I see with the decoupling efforts my perception not actively being engaged in Drupal But kind of like following along what's happening is an open source in general I don't get the feeling that decoupling is necessarily making the data model in the presentation layer standalone I kind of get the feeling what you hinted at a bit ago where almost make us a Drupal Doesn't have a UI layer by default you plug in whatever the case may be kind of that hard split framework application type thing Why do you feel like you need to go that far as far as decoupling goes Whereas just ensuring that your data layer and your presentation layer stay separate so that you can do these decoupled type operations without necessarily giving the impression that you are framework first not a UI Based application almost competing in the symphony space for lack of better terms Let's look at what Drupal is really good at right it's data modeling and relationships and Managing those pieces right the front end has traditionally lagged along and limped For lack of a better word for a long time while the rest of the web has made enormous leaps and bounds to get better and There's always been a very low investment in making Drupal's rendering in front end better. So let's Stop doing that and focus our efforts on the things that Drupal is really good at already That also don't seem to get a lot of investment either. So I Mean we spend a lot of time on these like fancy inbuilt features, but we don't Invest into things that are really important. So I mean I just let's just stop and do the front end someplace that can have its Own release and its own cycle and can consume Drupal's API's and to build these things sounds fair. Yeah Let's just have one more person and then mark. Let's talk afterwards. Hi, my name is Chris Caldwell I am curious Basically, I see us go. I think this is an awesome direction. I think we all kind of feel like we need to go here My concern is more with the choice for going with react Specifically in light of web components and native browser support of them We and by the time we get there with react. Are we gonna be kicking ourselves going? Wait now the thing is web components. Why aren't we doing that? You know, I will definitely answer this question. Okay web components miss a mark, right they were have been announced long before react and They've been around but web components and react solve two completely different problems, right web components are around to provide a Strong ish encapsulation of your styles and your custom html Modules react is all about keeping your data and your data structure in sync with the presentation And I think the we're being naive if you think you can use web components without a JS framework like People are like, oh, we're gonna use web components and then they just go these polymer and it's like Right We went we had like an enormous discussion about this and we picked react And I think the sad thing is is that we picked react because the people that are gonna do the work like react they like so All right, thank you all very much one last note once again If you are interested in these topics come to decouple Drupal days And if you are interested in contributing as a volunteer or an organizer, we're about to have a bof to Meet about this right now. So thank you And like