 Get started here. Just getting some set up done here. That's blinding. What's that? Yeah. There's a couple things sitting over there that I think are here. Maybe the bag is that your bag down there underneath. Under the table there? Yes. Yeah, this is great. I do not have Google Docs on my phone, so I don't have a way to see my notes. Sorry, I think here's the mic there. And then Marko is thinking if I could introduce the contents of the camera, unless I want to go back a bit further. That's right. We're already going to have it. Yeah, I mean there is an initial slide. I guess I'll jump in if there's something. I'll rip the mic up your hand a little bit. I made some edits to the slides. I also made sure they were in sync earlier today. Yeah, and then I did that probably after the video. I'm trying to think of a couple of things. That's actually something. It's still a pretty good one. Because this session, the reason why I wasn't practicing this is because I was focusing on the front end of the camera. If the tools are in core, somebody could probably use it. Although we're probably not going to have two different renderings. Don't get too much interference from that. All right, how are y'all doing? Awesome. I'm a completely new TraModerator. We're here to talk about whether or not we should include a JavaScript framework in core for the admin UI. Whether that's a good idea and also what would we want from that. I don't know if we're going to get to which one we should choose, but we have a couple of options forward. I'm not the subject matter expert here. I'm just someone who's really good at getting people to shut up and talk to each other. This is Danny Norden to give you a little more information about me. I'm the director of user experience at Pegasystems, which is a company in Cambridge that makes business software. I work on the digital team that handles all of the company's global websites. I've been part of the Drupal community since 2008, mostly contributing in terms of user experience and consensus building. Preston, actually Mark, sorry, is a front end developer at Lullabot. He is also the co-maintenor of Drupal 8's core responsive image and breakpoint modules and maintains the contrib AMP theme and Liberty theme. Preston works at Acquia in the R&D lab, correct? He does a lot of front end work, speaks at a lot of conferences about front end and is generally a cool guy wearing very cool pants. You should check out him. Alright, so because I'm not the subject matter expert, basically how this is going to go is Mark and Preston are going to present their respective viewpoints and we're going to let them talk and then we're going to have a discussion and I'm going to moderate it. So the reason I'm going to do that is because I just kind of like using my mom voice now and again and so I will use it if you get rude. So just so you know, keep it classy. Alright. Awesome, thanks Danny for that wonderful introduction. Just to give some context. That moves it. Alright, cool. Thanks so much. Alright, so just to give some context, so Mark and I obviously had a sort of very long debate about this. One of the things that we did is at mid-camp we hosted a sort of unofficial front end summit about the front end in Drupal and how we can sort of move things forward. There were people from the twig team there, lots of people in this room were there. We had a lot of core contributors there as well. And one of the things that we did is we came to a consensus about what features we want in core for JavaScript that will actually enable things like better UIs. The first is unified state management, sorry, client side state management, which means that when you have a bunch of HTTP requests happening on the page, when you have a lot of things happening, there has to be some way to manage state changes in a dynamic fashion on the client side. Right, so one of the things that's exciting about new JavaScript possibilities is in the way that the actual page gets updated. So React started this thing virtual DOM diffing where instead of directly manipulating every piece of the DOM, they're kind of calculating the DOM beforehand and then figuring out the minimum number of changes that are necessary to move from one state to the next state. And that allows for some pretty quick updates in the UI. And since then other frameworks have adopted that as well. So Angular and Ember have also come up with their own solutions for adopting quick updates in the UI, which can be pretty nice when you see it in action. Now, a third thing that we talked about was the idea of optimistic feedback because any time you have an interruption in a user's workflow, what ends up happening is that user loses concentration. For example, when you have a spinner that's for a very long time, oftentimes the user can lose track of what they were doing. So optimistic feedback involves the idea of showing state changes without having to make a full round trip to the server because of that latency. And one of the ways that, you know, what that requires obviously is a robust client-side rendering and client-side state management layer. Great. So we just completely redid our template system within Drupal and moved from PHP template to Twig. So a lot of the client-side frameworks that are out there, they tend to have their own template system. And whether it would be good to be able to reuse our existing set of templates that we've worked really hard to make really nicely, really nice on both the server and the client side. Regardless of whether we're able to use Twig or not, it would be good if we're using the same markup in both places. If we have one set of templates that's on the client side with a framework and we have another on the server side with PHP, and we have to try to maintain markup that's exactly the same in two different places, that's going to be a problem. That's going to introduce potentials for errors and inconsistencies. So when we talk about state changes on the client side, one of the big issues is that we want to ensure continued bookmarkability using the history API which is available on browsers, meaning that if you have a dynamic state change which occurs on the client side, you should be able to bookmark that state. And currently, Drupal is a system that is very much predicated on routes and we want to make sure that whatever route you hit is able to basically show what you need to show. Right, so part of that is what happens when you go from one URL to the other. So one of the advantages in theory of frameworks is that you're minimizing the amount of time that it takes to transition between one page and another. And there's some interesting things to minimize that on the PHP side of things. Winglers has been working on a project called Refresh List that helps to take advantage of all the cache context information and only swap out the parts that have changed between one URL and another which can lead to some really impressive fast page reloads. And then Fabian had a really good talk earlier today where he was talking about potential ways that we could optimize the Drupal bootstrap process and shorten that time up considerably which would also minimize page transitions and it would also be really good for REST API use as well because REST API is still getting some data that's generated on the server and if we can minimize the time that that takes for that to happen, that would be good. But in general, one of the things that frameworks are aiming to do is to kind of skip that whole server request response entirely and minimize the amount of times that we have to do a full page refresh and just get quicker to just changing the things that need to change. So one of the things we want to do now is to move a little bit into talking about the benefits and challenges that come with a JavaScript framework. So one of the first things I want to talk about is that currently Drupal has sort of not a full featured templating layer on the client side which means that we don't have something like jQuery templates which involves the use of templates that exist on the client side to do re-rendering which is a really big problem and currently you could use something like a custom solution such as TwigJS which exists and is being worked on. However, there are actually other promising solutions out there in terms of shared templating including the fact that Angular 2 recently announced that they have a Twig integration which enables you to reuse Twig templates in an Angular 2 application on the client side. Also, we've heard quite a bit this week about decoupled blocks and that also is, they are also looking as part of the roadmap to look at the possibility of shared templating. So this is already an area that is being explored quite a bit. Yeah. So templating, sharing templating would be important. Being able to share the markup between one place and other is important but that's not the only thing that would have to happen because we have consistency between the server side and the client side. Right now in Drupal in our theme layer we have a pre-process layer which basically between that and controller serves the purpose of taking the raw data that comes from Drupal and transforming it into the variables that we need on the template inside. So even if we had Twig templates in one place on a framework and in Drupal we would still need to have good ways to have that logic happen on both the server side and the client side. And we had some interesting discussions this week on potential ways that John Albin has been working on some component implementation and thought maybe we could use some Twig to do some of the things that pre-process could do, just have a separate Twig template that's purely for variable preparation that could be set in the middle there and that way you could share logic between the client and the server. And that's something we'd have to explore to see if there's enough logic power available in Twig to do that, but that might be one possible solution. But routing is another thing. So routing is saying, hey, here's your URL and here's the data that we're going to share based on that URL. And right now we have a whole bunch of routing.yaml files in Drupal 8 that defines what happens, what controllers get called, that sort of thing. And how do we make sure that if a client-side JS is happening that we don't have to define everything twice as to what happens. So we had an interesting... Ed had a really interesting demo in his Ember session where he showed how Ember was kind of taking advantage of the routing things that were already going on within Drupal. And that was interesting in a way that it might potentially minimize the amount of duplication that's going on, but it's a concern that I think we have to be careful about. All right. So one of the other things that is important to keep in mind is that client-side re-rendering is really important to achieve the usability goals of optimistic feedback and instantaneous feedback. If we do not have that, there's actually no way to accomplish the kind of uninterrupted workflow that users have come to expect and will continue to expect. Now, the other thing that I want to really state very clearly here is that we are talking about an executable on the client-side. And the only executable on the client-side, arguably apart from Dart, is JavaScript. And given that many of the UIs that we have come to expect in terms of application-like UIs are now JavaScript-driven, it's very important for us to have a robust framework to handle those things. I think you can do some cool things with JavaScript. There's some pretty neat stuff that you can do. But I get concerned about the idea of purely relying upon client-side rendering. The way that browsers work is that if you're going to be using a JavaScript framework, then the whole framework needs to be downloaded, or at least the parts that are relevant, and then it has to be parsed by the browser, and then it can execute, and then it can render your client. So relying upon client-side rendering can potentially introduce delays into when content is available on a site. And that's one of the reasons why most JavaScript frameworks have been moving to a isomorphic or universal JS system where there's an initial server-side render. So I think we have to be careful upon, if we were to rely solely upon client-side JS, a client JavaScript is a great language. It's a little bit less forgiving than HTML. If HTML, if something goes a little bit wrong, your website can still render. Client-side JS, if something goes wrong, and maybe even some unrelated piece of JavaScript, things can go off. And there's a lot of good ways to work around that and be cautious. But I'd be kind of concerned if we don't have a server-side render what that would mean. Historically, that's caused an issue on search engines for example. And that's been getting better, but whether or not search engines, if they're coming across a page that's purely client-side JS, whether it's going to be able to read the content or not. All right. So one of the other things is that if you are having a server-side render driven through Node.js, client-side rendering obviously requires you to have some client-side JavaScript. And I'm not necessarily arguing in favor of us having a complete initial render in JavaScript, right? Because that is going to lead to a huge latency in terms of your actual time to first interaction. What I do think, however, is that Drupal is very good at server-side rendering. It is a server-side renderer. And one of the things that we can take advantage of is to make Drupal's server-side render a robust initial state for our applications. Meaning that if you start out with a very, very good means that is indistinguishable from, let's say, what would be generated by Node.js execution of a JavaScript framework, then the sort of amount of time between time to first paint and time to first interaction is the only concern at that point. I went to all the JS framework demonstrations. There was a lot of really cool things that we had here at DrupalCon. Pretty much all of them are talking about when they're doing their server-side render. It's with the assumption that it's being done through Node.js, not through PHP. There is a project out there called PHP v8.js which runs JavaScript through PHP, but it's not heavily used. It's not necessarily used in production and maintained in a very solid way that is something that we could rely upon. Maybe that could change, but it's something that could be risky. So really the setup that's pretty standard is doing the initial render on Node, not necessarily doing a PHP render and then somehow replacing that with a client-side JS framework, at least from the things that I've seen. There may be some other things out there that I haven't seen, but I guess I'd be concerned that that's not a regular workflow and we'd have to do a lot of workarounds to make that work. If you did a PHP-based render, I guess the question is then how does that data then get into the client-side state and then replacing the markup with the client-side rendered JS because, again, that's just not the standard workflow. So one of the things I do want to mention is that a lot of these JavaScript frameworks are now exploring opportunities to integrate more deeply with server-side frameworks. For instance, Angular 2 has as part of their roadmap an explicit plan to provide a very easy means to integrate with, let's say, PHP-driven backends or Ruby-driven backends. And one of the things that's very compelling here is that, you know, that's building a bridge to these server-side technologies. But, you know, obviously, there's some issues that arise in terms of that distance that's generated. Yeah, there's a roadmap document for Angular and there's one line that says that they're going to try to integrate with PHP. But I haven't seen that there's a lot of discussion actually going on about that. Most of the universal Angular discussion is related upon running on a mobile app for mobile apps. So I haven't seen that there's a lot of energy behind the PHP render. Maybe that happens again. That'd be really cool if it did. But I think right now, depending upon that, would be a pretty big risk. So getting the data, the state data from the server into the client-side is called hydration or rehydration sometimes. It's kind of the term that's called. And one thing that has to be done very carefully is that even if you have the initial server-side render, the client-side JS still needs to do all of its downloading and booting up and getting all of the state data into the parts that need it so that it can do interactions on the website. And that has to be optimized or you're going to have sort of an uncanny valley even if you get a server-side render where you're going to have this gap between where it looks like you can interact with the website and when you can actually interact with it. And so trying to find ways if we were to do something, a really important thing would be to optimize that hydration process to make the most important parts of the interface interactive as soon as possible or could get a little bit awkward. So I think that what you refer to as the uncanny valley mark is actually something that exists in every single JavaScript-driven front-end. Anything that requires any sort of JavaScript requires you to parse and execute that. And so I think that that gap between the sort of time-to-first paint and the time-to-first interaction is something that every single UI that's driven by any sort of JavaScript has to deal with. For example, QuickEdit. But however, one of the things I do want to say is that I think that we do want to consider what could happen in Drupal's far future. JavaScript and Node.js are two of the best understood and some of the most sort of well-understood technologies available right now in our industry. And many people are actually using JavaScript pretty much solely across client and server without worrying about a lot of these back-end languages. So another one of the... Sorry. So what I do believe is that Drupal could benefit from actually decoupling itself. Having a PHP-driven back-end and having a JavaScript-driven front-end. Obviously, this does increase hosting requirements. It means that we have to change the way that we think about serving Drupal... about hosting Drupal. However, the hosting landscape for Node.js has improved significantly and I do believe that there are actually quite a few services that offer sort of subscription plans that incorporate both LAMP and Node.js hosting. So I do believe that this is where a lot of the front-end momentum is going and we should be able to acknowledge that. I'm pretty concerned if we start talking about trying to convert part of Drupal to run on Node.js. There once was this time and somebody said, hey, it'd be pretty cool if we converted one part of Drupal to use this component from this other thing called Symphony. And it ended up working out really, really well, right? I'm really happy that Symphony is in Drupal. I'm really happy that we have object-oriented code. Uh... No, but it worked out really well, but it took a really long time. It took a five years for us to release Drupal 8. And so when we talk about we're just going to convert one little part of Drupal to just do the rendering on Node.js, it's where do you draw that barrier? Because are there some formatters we might need to change? What about the routing system? Are we going to convert the routing system that we've run on JavaScript? Going from PHP to JavaScript is a pretty big deal. And I think the hosting requirements thing is not trivial. We've already kind of increased... It's hard to run Drupal on inexpensive hosting at this point. You know, are we going to say you know, 25... Can you run it on $25 a month hosting and have Node.js? I don't know. Or is it going to require $50 a month hosting or $100 a month hosting? I think we really need to very, very carefully figure out how much work that's going to take and what the impacts are going to be before we head down that road. Oh, that's me. So again, Fabian had a really interesting presentation this morning talking about newer PHP techniques. And that's really cool because hey, we use already PHP. So we could do maybe some things that minimize our bootstrap time which will allow us to have faster interaction patterns. We could do some things like React PHP which came before React.js, as Larry pointed out to me. Icicle. That do some things that allow for long running server connections and potentially could allow for more interactive between PHP and the client side JavaScript without necessarily having to do as much re-architecting. You know, I do see that there is one big thing that I do want to point out which is that Apache is based on a request-response paradigm. And a lot of these technologies like request PHP which is Node.js like asynchronous.io in PHP also ratchet and icicle which are some of the frameworks that rely on that actually do require a standalone process outside of Apache. And if we are concerned about sort of changing our hosting requirements with Node.js, we're also going to have to really fundamentally reinvent the way that we're going to use PHP as well and our LAMP stacks. So, you know, there are big risks requiring that could really be a big shift for the Drupal hosting landscape which could fundamentally be as complicated or as challenging as, you know, adding Node.js as a dependency. I think that's true and so I think the end result is that it's complicated on both side and you can't necessarily say that it's going to be super easy on either of these two changes would be a problem while the Node.js problem, you know, rendering would also probably be an issue and you never know on both sides the hosting landscape may change in the next few years if these newer PHP techniques become very popular and Apache doesn't adapt to work with them well something may come along and shift the server landscape on the PHP side but I think it's something that's evolving and yeah. So, I do want to talk a little bit about sort of modernizing our front-end developer experience because one of the things that's really important is that, you know, often we have an existing Drupal behaviors API we have our existing Ajax framework but how many Java developers have you worked with who will simply just not use any of that and just put their jQuery on top or put their JavaScript on top without leveraging any of that. I think that it's very important that, you know, we want to make sure that novice Drupal is people who are new to Drupal who are developing on Drupal are able to do that. Now, the other thing is that there's a great deal of coalescence happening right now in the JavaScript community in terms of concepts, in terms of approaches for example, React's virtual DOM those sorts of ideas are really percolating throughout the industry and one of the things to keep in mind is that the sharing of concepts is resulting in less fragmentation in the JavaScript landscape which means that I believe that this year and this was predicted actually by JavaScript there will be quite a lot of convergence in approaches. So, one of the reasons that I've heard a lot that why should we should move to this is that we're going to get a lot of front-end developers that are going to come into our community because we put a JavaScript framework in core. Well, so I, thanks Martin keep it classy or keep it stable, either one. So, front-end developers come in a lot of different a lot of different flavors so I think it gets stated sometimes that hey, it's a front-end developer so they're working in a JavaScript framework and there are a lot of front-end developers who are doing awesome work with JavaScript frameworks and I think that's fantastic. I am not opposed to JavaScript frameworks by any means. I think they provide some really great experiences. I'm concerned for a lot of reasons about how that would work inside of Drupal core because of some of the things that we've been talking about, but I'm also not entirely convinced that if we put a JavaScript framework into a PHP PHP-based content management system that the people who do rely upon the big landscape of JavaScript that's going on are necessarily going to be really excited to work within Drupal again. I'm not sure that that's the case and JavaScript frameworks are not necessarily the intro thing for front-end developers. I've been working with front-end development for a lot of years and I still find some of these things pretty challenging. Twig was a really cool thing because it opened the door for who could work with Drupal's front-end by making it really easy to work with HTML and CSS and that's where a lot of people start and making that a good way for people to get started has I think having some really good benefits. I'm a little bit concerned that by working with Drupal's front-end development framework which I feel are kind of more on the advanced level that that could put up some barriers to participation. There will be some people who will make it easier to work with Drupal because of that but I'm not convinced that it's necessarily going to result in a stampede of people that are coming in to help our community and I guess maybe there's going to be consolidation within JavaScript but there are different ways of doing JavaScript and if we pick one particular framework, if we pick Angular, we pick Ember or we pick React, are the people who are really big fans of the other frameworks going to be excited about working with it just because it's a framework? I don't think that's the case and we've seen a lot of churn in the landscape as well. I think it's really cool all the things that are going on but we put Backbone into Drupal just all the time. That was kind of on the leading edge at the time that we put it into Drupal and I hope that Angular and Ember and React continue to thrive but will that be the case in two to three years or will there be something different that comes along and we'll have something that's old within Drupal? I don't know, it's hard to say. All right, so just to hurry this along because we are starting to get into some time here, I do believe however that the long-term risks are actually greater than the short-term risks. One of the things that I believe is that yes, it will be a colossal undertaking to really modernize our front-developed experience and also update those accorded UIs. However, think about the fact that it took us quite a long time to use Symphony to bring Symphony up to the level that we really wanted to use it at. Now, one of the things that I want to point out is that if you look at the long-term trend at what's happening in universal JavaScript, one of the big ideas that's really about unifying, oh, sorry, unifying the entire, you know, unifying a code base, making it much more maintainable. Basically, you execute code, the same code that you use on the client can be used on the server. And so, you know, one of the questions that I have that I'd like to discuss is how important is it for us to have that kind of shared unification across client and server? How important is it? You know, for example, we talked about template reuse, we've talked about sharing of templates between server and client. Do we want to unify a rendering layer or do we want to have unified rendering across client and server? Do we even potentially want to have unified routing across client and server? And that's something that could be very compelling. I think it could be compelling. I was really impressed in the Ember demo in particular. There were some really cool things that were shown off, and I'm sure there's really cool things that are possible and angular and react that we could do as well if we integrated those. There's some big benefits, but any project that we tend to work on, we manage scope. We decide what are the things that are most important for us to do? How much time is it going to take to do them, and what's the risk-reward ratio of those things? What's the risk of that scope creeping outward? I think there's a lot of unknowns here that could result in scope creep, and I think we have to evaluate that and consider it. I'll be honest, I'm not exactly sure what the right choice is for us to do going forward, but I think we have to think really long and hard about it, even if there's really cool things that we could do as to what is that going to mean for our project? Will we be able to do with this? But what won't we get time to do if we focus on this instead of something else? All right. This got mentioned in the Andresa's keynote, but one of the other things we talked about at mid-camp was component-based theming, and not only because it would be kind of nice for people who are working with HTML and CSS, but we've seen a lot of consolidation in JS frameworks, which is great. It's really cool when we do see convergence on certain ideas, and components is a really big thing where a lot of the JS frameworks are using components. So moving our theme system to the point where we, as much as possible, can get down to one type plate per section of the page, per one design component, being able to bring in our JavaScript and CSS, that looks to be one consensus way forward within the front-end development community as a whole, so getting that in place would probably be a good thing as a first step, and maybe by the time we get some of those things done, then some of the other JavaScript things will settle out and things might look a little bit different. But, yeah. Another thing that Dries mentioned during his keynote is that one of the things that we really need is a first-class API for CMS, which means really robust APIs are very crucial. Meaning our REST APIs, I see a lot of people who are involved in whiskey in here, the relaxed web services module, for example, GraphQL even. So all of these are very important to making sure that Drupal is a very robust back-end. So whatever path we take moving forward, I think we need to enable decoupled applications to be able to consume Drupal data in a very easy way. Now, one of the things that Mark said earlier is that we have, you know, the ability of people being turned off by a framework that we adopt. But the thing is that, you know, we can still enable fully-decoupled Drupal limitations that are written in Angular or React if we, you know, for example, choose Ember. Those things are still enabled as well. So API-first Drupal obviously is a very, very big initiative, and I'm looking forward to more discussion about how we can move those forward. Yeah. I think that's definitely a point of agreement is getting our APIs in place is good for everybody. There's some really neat things going on with Drupal and we should make sure that we continue to enable that. So I, for a lot of reasons, I am on the skeptical side that the JavaScript frameworks that are kind of designed to work with Node may not work out so well when we're a PHP-based system. Maybe we can get, maybe we can do it. Maybe we can find a way to get past the challenges and make it work. But I also think it's at least worth looking to see are there some smaller open-source JavaScript libraries that would enable us to achieve the goals that we want to do but play better with PHP. And if they're not available now, and I started doing some looking, and yeah, most of the JavaScript landscape is based around Node right now, so it's kind of hard. But there's a lot of people that use PHP. It's like something like 70 to 80% of the web is powered by PHP. So maybe we can help enhance existing things, contribute upstream, or even do things where there's some gaps. And get some, bring in some, find some JavaScript developers who are interested in building new things. I think that's a thing. Building new things for, you know, maybe there's some ways to use that churn and excitement for new projects to our advantage to get some things that work well with PHP. Maybe, maybe not. There's risk with that too. All right, so I think of the interest of time, I think we should probably move forward into the discussion. Over to Danny shortly. And one of the things that I would like to ask is that we keep statements down to one minute just because of how limited time we have. So thank you very much. I'm just going to see if this goes. Hold on. All right, there's some ground rules here. Fisticuffs will not be tolerated. We're going to keep our questions and answers down to one minute. What I'm going to do is actually, I do have a couple of questions that I think we can use to guide a discussion, but I'm going to let a couple of people speak their minds first. If you see me do this, that means you should stop talking and let the other person speak. If I do this, it means just shut up now. Okay? Awesome. All right, Eric. So I'm kind of... Okay, Morten. So I'm in agreement with both of you. I kind of side with Mark in the instance where, yes, it can be really complicated to talk a little about the way we approach this, but I'm still lost as to why we want to put a JavaScript framework in core if we just want to fix the admin UX. If it's to demonstrate how we can decouple and decouple properly, there, as you said, are antecedents to that like component-based theming and general JavaScript methods that we should write behaviors for in our themes, like the admin theme and redo the UX on that. So that's why adding a JavaScript library to core. So what is the bigger why here? Why are we having this discussion? Is it only to demonstrate the right way to do decoupled? So I think there's two things. So part of the discussion is that these guys aren't going to talk a lot. Yeah. So that's a good... Okay, so then that's the question for the room. Yes, exactly. Why are we having this discussion? I don't think bringing JavaScript in is going to do that. Okay. I just want to make sure we're all on the why are we doing this? Is it to demonstrate to the community or is it to pat ourselves on the back like we included something and injected it? Okay, so that's one of the questions. Is why are we doing this? Okay, guys. Good question. Larry. So two points that I will try to keep brief. One, a line I like to quote from is that those things you don't have an answer for yet design in such a way that you can answer that later. So as Mark was saying, let's take the time. There are advantages to component-based layouts regardless of what we're doing on the front end. So let's just do that and come back to a lot of these questions later when our answer may be different, but now easier to answer at that point. I'm sure there's a bunch of other things along those same lines where those things we can do before what the JavaScript looks like become relevant and need to get answered. Point two on the Node.js versus Icicle question essentially. Yes, both of those increase the hosting expectations and hosting requirements, but only one of them means that everyone has to be multilingual in order to bother working with Drupal in the first place. Right now, you can be just a PHP dev and work with Drupal with Icicle React, PHP 7.4 with Native Async, whatever. That becomes still a single language. If you can't touch Drupal's back end without also being a top tier JavaScript developer, that becomes a much bigger problem for onboarding new devs. Good point. Hi, I'm Ed of Embercore Team, so that's my disclaimer that I'm partisan. The question that I'm hearing from the room if I can synthesize it is there's a real question about deciding what is Drupal, because if Drupal is PHP and it happens to talk to some JavaScript, that is one valid solution. And if that's the future, then your ability to be API first is what will determine whether you have a future. Because mobile devices are not going away. I think that within the next two years offline will be just a requirement for a lot of applications. And that is what is driving everybody into JavaScript. Not because anybody loves the language, but because it is the first time we've got an application platform that runs on all these devices in everybody's pockets. And the other way to redefine Drupal is to say Drupal is not defined by what runs on the server. Drupal is the whole experience. Drupal is the whole experience. Drupal is an integrated experience to the editor, to the end user visitor. That is a full end-to-end experience. And somebody is going to ship that CMS. I want it to be Drupal because I think the community has so much experience in organizing content. Drupal really cracked that nut in how you build a flexible tool. So somebody is going to build it. And I think it's going to be a great experience. And I hope you guys have a choice to be that thing. I hope you are. I want to help build it. We're going to move to the next. Hi. I'm massively concerned that it took until almost the last slide of this presentation to mention how all this data is going to work. And I think we have such a huge amount of work to do on that. We're talking about right now and we're not like the JavaScript landscape is probably going to be different by the time we fix that. I feel like a lot of breath is being wasted on this right now. Okay. And to extend to the point Sally made. I think it's great that this conversation is happening right now. I think the community is learning a lot about JavaScript. However, as Sally said, there is a lot missing on the back-end side of things. Where I work, they maintain of the relaxed module, spent two years trying to build a good REST API. And we put some serious money and efforts and put together some really smart people try to build a decoupled app and it's super hard. It's super hard and it's not because the frontend bits are missing. They are there. That technology exists. It's all out there. Why is it hard? It's because we don't have the Drupal tool set. We don't have the entity API we need. We don't have the REST API we need. That's why it's hard. The frontend bits are not necessarily hard. That's all out there. People are building these things. I think that's where we should weighing the conversation. Or perhaps we should continue this conversation. But that conversation about the REST API, I don't necessarily agree. I think there needs to be more. Okay. All right. Thank you. So I have to go. I went a little bit back in the history books back to Copenhagen 2010. Rasmus Lierdorf is doing the keynote in Copenhagen. And there's one person asking him, should we rebuild Drupal in Ruby? And it's kind of, I feel it's the same kind of question we have having right now. We have to have a new technology. Should we then jump to that so we don't make ourselves obsolete? I'm a little bit afraid that we also are driven a little bit by tech clusters at this point. Like, oh, everything is going to note. I completely agree with the, hey, we have these things that are happening. We need to figure them out. But I'm also seeing, oh, new shiny letters run after that. And we have burned ourselves down in Drupal a couple of times by adding the more we have to maintain, the more we have to maintain the less cool new stuff. I would suggest very much a thing where we do all of this out in contrib, keep it out of core, and then fix the real things first. And then contrib can go bananas and we can build the big emperor thingy with the emperor team. And that sounds like an amazing idea, but a little bit afraid that we're going to end up having a ton of crap on our shoulders and that had killed us before. Okay, thank you. Right on time. So I can clearly see here there is like two kinds of group being here. Like one which wants a front end framework in Drupal core and then there is not having a front end framework. But if we can look, I have an option of using polymer, which is not a framework. Again, but it supports frameworks. So this could be an option where it satisfies both kind of people like we had for classy discussion and we came up with a thing to support both kind of people. So polymer would be an option which so when we were discussing about needs, why we need a framework and so polymer has these all things but again, it's not a framework and it supports a framework. So we should evaluate this. Thank you. I've spent a lot of time building decoupled apps the last six months and I find I don't really, I think what should we do with Drupal core is complete the wrong answer. Much like Dick said, there's there's too much stuff that is missing on the server side part to even start considering what we do about the client side part. And I think the best way we could do the client side could evolve would be for it to grow organically. So not to create some huge initiative to you know, decide the one true framework but just let people who are interested in doing decoupled stuff do it. You know, all the guys can go together and take whatever you know let it go and tip and then we can see is this something we should include in core. I don't think this should this even could come at you know, I don't think this could be a successful top-down project that core decides we should do this because the tech the front-end tech is evolving too quickly and there's no way to say what's the right solution now. Okay, great. Thank you. Two disclaimers. I'm a back-end developer and my company is the 1007. So I have front-end developers that started with Angular and it's now moving over to React. I think the more important part of the conversation is that what they really like about your boy all the front-end and back-end guys can agree on all the conventions, the PSR conventions, we adopted to PHP 7 and be more inclusive to JavaScript. I think what we need to do is to take a step back and go back to all the tried and true formulas like what other conventions and if we can get those down then we don't need to have these conversations where we have to decide what's the color of the bike check. So that's my... Thank you. Hi, I'm Lauri. I'm one of the core team system maintainers and I do agree that in order to achieve the goals that you explained we need to have a front-end framework in Drupal and I support achieving that goal from my perspective, but we are very far away from making any decisions which technology should be using because there are so many things that need to be improved in the current systems that we have and let's say the current component based team system that we have been working on is going to be blocked on some of the things that we are going to face soon and there are going to be some things that are going to teach us what are going to be the problems implementing this JavaScript thing and one of the impediments we are going to definitely face is that even Twig which is a component that is took from other system is very heavily integrated into the very deep of Drupal so in order to integrate something like TwigJS a lot of systems a lot of bits of Drupal to be functional on the front-end in order to be able to render the templates so this is going to be a huge and massive transformation for Drupal in order to be able to make it happen we put it out from this room which are key components and API we are not... ... we selected as a session it was loaded and you showed up to it okay so we are going to have two more questions we are going to have two more comments and then I have a couple of questions I want to put out to the room based on what I think I am hearing so David I have gone on the record for a couple of years now being a big fan of this but at the same time I really acknowledge what the London contingent here is expressing it's easy a lot of more people be doing this already there is no lack of desire to see something like this done in the ecosystem and the fact that it's not widely done speaks something to the difficulty in achieving it right now and I think the focus has to be in making it easier, period rather than selecting something and then honing focus into one solution because I don't think that solves the underlying problem which is doing this kind of thing is hard no matter what the front-end framework is after we get those hard problems solved that underlie it again it feels so much like the tail wagging the dog where the dog is cancerous and dying we should probably focus on those underlying problems that remain outstanding that prevent that proliferation that seems that everybody feels like what happened were easy from happening and then I think if we did get those issues that are implied here out of the way then we wouldn't need to have a core conversation about picking a front-end framework because there would be three or four competing in the wild already and we just select one I think that's actually incorrect I think that's actually incorrect a lot of front-end frameworks interact with APIs let's say something like Jason Howell or Jason Aldi or something like that our goal shouldn't be like let's get a front-end framework that works with Drupal it's more like let's get an API system that actually works which follows whatever standard we feel like tail wagging the front-end frameworks will come that's the last thing we need to worry about the one thing I want to piggyback on this gentleman over here Edward seems like a smart guy the really dangerous part here is actually like serving when you have a split brain serving two different masters which is a bad thing we want to concentrate on if it's API-driven design that's what we want to go to because on something like this getting a front-end framework into Drupal without having the API first is just a waste of time like a waste of effort and one of the things on a project like this especially an open source project we want to kind of like diverge our resources somewhere that's going to help us grow and stuff like that where I don't know it's been said so many times before it's kind of like I'm just feeling like I'm repairing the same thing but his point is very important is that we need to figure out are we like an awesome back-end tool that gives you great APIs are we some full-on experience those are two very different things and I will go with Dresa where it's like API first right and that seems like a good direction to go I'm done the other thing is what the no no no the other thing is I can't say the last bit it's alright, you'll get your chance Larry that's it right before right before this session I was in an hour long discussion with about five different people building stuff on our core REST API I have no idea what their client was nor did any of them bother to mention because it didn't matter it was problems with the REST API how do we fix them let's go do that so there is demand for that even without having a large framework in core to drive demand also let's see if I can manage to not completely butcher this I think it's a Kent Beck if adding a feature is hard don't add the feature refactor the code to make it easy to add and then add it refactoring part may be hard but that's the process you want to go through so that you end up with a non-hack at the end right now adding all of these features that we're talking about like optimistic feedback and offline support and so on is really hard so let's improve Drupal to the point that they become easy and then what we do at that point should become obvious so throw me down in the same category let's do the component design the first design and as we do that the answers to the rest of these problems should just kind of shake out on their own before you guys talk I just want to see if I can synthesize a couple of things I'm hearing really seems to be that choosing a framework is not really the discussion the discussion is how do we make it easier for Drupal to play with front-end frameworks is that fair okay and the other thing and I really want to speak to Larry's point I think a couple of other people have mentioned this are we moving too far in the direction of requiring you to be like a hardcore developer with a serious hosting company just in order to work with Drupal and what does that mean for onboarding new contributors onboarding new users, user adoption so I think that's an important thing to discover or to discuss the other thing and I want to bring this back to as a user experience designer and I'm sure Roy and Bo Young can speak to this and probably Kevin when we talk about why your UX expectations we really want to get to especially when it comes to admin what are the actual things that people need to do that might benefit from some of these features so I would encourage based on what I'm hearing that we focus less on what framework should we choose or should we choose a framework and maybe what are the jobs that people need to get done with Drupal that could be enhanced with interactions that aren't possible now does that sound reasonable okay well yeah that's because Roy hasn't talked yet all right so one thing which is really confusing for me is that we are blending like in like a thing which maybe is fixable in three, five years or something but I think we really should actually like provide values for like our users now because I think if we like wait for five years or even if we are really fast we manage to get something done in if we are getting something done in like three years that's not going to work that will kill the project anyway if we are too slow so I think we should work on your improvements why now we should work on API improvements why now we should work on our underlying architecture right now and there are still a million bucks out there everyone can fix which makes also a lot of people out there happy not million but yes Roy you can go so yeah my very short version is that I hear comments that people want to postpone on the shiny but we need shiny because shiny attracts people and we need shiny soonish rather than later the other things there was basically really just a few people currently a framework I mean I also say a framework would be nice in general but at the moment it seems to be something which is pushed from the outside into the community rather than coming from within the community that's an observation I had had one more point that I had wanted to make so that actually is a good lead up to it one of the we've been having the discussion for the last six months and I feel that one of the reasons why it's been contentious because it was introduced as hey it's time to pick a JavaScript framework and we just had a really done a lot of work getting Drupal 8 launched we had a lot of people working to make the front end better within Drupal doing twig that sort of thing and nobody came to us and said hey we want we've got this thing we want to do how should we go about doing it the front enders within our community it was just kind of introduced as hey we need this this thing so this is what we're going to do and certainly that's within you know that's something that can be done but I would ask let's say that we take some time with the components and we take some time with the API especially I think is super important that's a lot of energy behind that but when we get ready to do this like it is great to bring in new people that are front end outside the community and get them involved I think that's great Ed has been saying some really good things I'm glad to have him here I hope we get Ed involved but let's also talk to the front end people within our community and listen to them on about this let's have more conversations like this because if you ask a front end developer hey we've got this really cool thing we want to do and you ask them how do we go about doing that we will come up and we'll do some good solutions for you but let's have a discussion and really listen to the concerns within our community thank you so we have two minutes left I think in terms of next steps it sounds like not necessarily like we need to go back to the drawing board but I think it is clear that we need improvements in Drupal's UI on the admin side we should I would my recommendation would be that we should first identify what those improvements should be before we start rushing to a solution does that seem to me also well I think the consensus seems to be that we're not even necessarily talking about a framework at this point we're getting back to what are the actual interactions that can be improved and then a framework that actually facilitates that does that seem reasonable I didn't necessarily hear a shiny thing to quote somebody else that we could spend some time on that we're not spending time on so it's not just about frameworks I think the consensus that I heard was that we can do things like projects that integrate Ember and Drupal and Drupal and move forward with that and have some really exciting things that people can use now but it may be premature to think of things more yes but I while I agree with that I think one of the biggest things is remembering the goals and remembering the vision and moving towards something as opposed to just picking a technical solution shoving it in there and dealing with whatever that gives us for the next five years are the integration of any framework if we execute those fundamentals really well we won't ever have to have this discussion of what framework we include because any framework could leverage and that's really the key here we focus on these things so I think somebody back here raised their hand yes okay exactly exactly okay alright so we're out of time I know we all want to get to the parties thank you all very much for attending this conversation thank you hope that was helpful I really appreciate you moderating that that was absolutely