 Yeah, I guess we're going to start. Good afternoon, everyone. I'm Theodor Biaudala. I'm a cordial script maintainer for Drupal 8 and 7. And I'm going to talk about head full Drupal. So just show of hands, who's familiar with headless, decoupled Drupal. Yeah, so you all went to the keynote this morning. So usually, on Drupal 7, when you have a client, he wants a UI for some reason. And the process of developing that, it's just pain and misery. You're just picking up the shards of your client's broken dream and trying to make them fit. And you cut yourself in a process. So let's say you're a surgeon, plastic surgeon, and you have a face to make nicer. So you have the default Drupal 7 face, which is a bit crazy. So you put a mask on top of it, could be Zen, could be Mothership, Omega, Bootstrap, and you work on top of that. But the crazy is still on the list. So whenever you want to do something a bit more involved, I get really ugly. It's a bit big for taking notes. So because people don't like crazy, they're just saying, OK, we're not going to use the Drupal UI at all. And we're going headless, whatever that means. It really picked up last year around some Drupal code as well, the term headless and making headless websites. It's like Web 2.0 at this point. Just to make sure we're in sync, this is a graph from a pension blog post. I mean, usual static websites, you have files, browser, simple. Usual Drupal websites, database, PHP, browser, simple. And the headless or decoupled way you have the database, PHP, some JavaScript stuff that will render your content and the browser, unless it's not really true. What really happens is that it's the browser that renders everything. I mean, there's no extra step. It's just more stuff on the browser. So is it really headless or decoupled to do it that way? I mean, there are proper ways to do that. I have a slide at the end where I can show you what a proper decoupled way look like. But if you do it this way, just push more stuff to the browser when you use Angular, React, all that kind of stuff. The front end logic, there's not much logic in it. You just template rendering and routing. So you go to a page and JavaScript takes care of loading everything. But if you look at blog posts or just talk with people that did decoupled implementation, they keep the Drupal admin UI. Because they're not that dumb or rich because it's really complicated. I mean, there's lots of stuff you can do in the Drupal admin UI. And it doesn't make sense to just build a whole JavaScript app for 10 person. And even 10 is a lot of people. And the business logic, it's all still in the back end. So you still have rules. You still have views, all that kind of stuff. But you just get the data in a different way. So business logic could be, it's a brain kind of. So it's not really headless. I mean, decoupled, it's kind of a fancy way of talking about headless. And the URL here, it's a kind of terminology it likes, I guess. But it's really faceless Drupal. You just keep the brain, you just don't want to see it. And if you're a surgeon and you have a faceless human being, you have to draw everything again. You have to make everything that was already there, which is like forms, authentication, that kind of stuff. It used to be there in Drupal, but because you go headless, you have to make it from scratch. And because it's all about what you see, what you don't see gets left out. And what you don't see is security and accessibility, usually, because if you get data from the Drupal back end, it's not sanitized. Well, you shouldn't do anything special with it. So you have to sanitize it on the JavaScript side. And people sometimes forget about that. And I guess it's even worse in Drupal 8, because now we use twig auto-escaping. So all the data you're going to get back from Drupal before twig, it's not going to be sanitized. So you have a lot more things to take care of on the front end. So what would something ideal look like? And if you have any questions, just stop me and you can talk about it. It's a conversation afterwards. So what you would like is some basic, non-relief opinionated baseline to work with. And you just dig stuff on top of that. It's Mr. Pat at Drupal. You just put eyes, nose, mustache. You want to enter hipster Drupal. And you don't have to be a trained surgeon to do that. You can be a kid and just dig stuff on your Drupal to make it nice. And the thing is that we have a way to make the individual pieces, features, kind of standalone. So you could use them within Drupal, but also within your own JavaScripty stuff. So you don't have to use Drupal to have some Drupal features. Hopefully it would make sense later. So the way to package those kind of features are web components. So who heard about web components? Oh, wow. Nice. Who's using web components? It's like three or four people. And web components, it's just a fancy term to describe four technologies, actually. So the way it looks, it's like that. So first, you have a standard HTML page. You can see in the head space, you have a link import. So this is an HTML file that contains a template and some JavaScript. And maybe some CSS, whatever you want. It's HTML after all. And this will be all the logic of your component. And you see in the body of your HTML, you have a custom tag, which is Hello World with some attribute. And this is, if you make a view source of your page, you're going to see only this tag. But if you inspect it with the DOM Inspector from Firefox or Chrome, you're going to see the shadow DOM. So this is additional elements added by your widget using the template that's in the imported HTML file. So if you, well, I don't have the imported HTML file to show you. But if you open that file, the Hello World HTML, you have a template tag with the P, Hello, Strong, and Closing P stuff. And then the JavaScript will replace what's in within the Strong tag with whatever is in the Who attribute of this tag. So does it make sense for some people at least? So when can we use that? Well, if you're a user on Chrome or Opera, you can use it right now. Otherwise, you need to polyfill all this stuff. So there are different polyfills available, Google Polymer, X template, others kind of things. So the first technology is HTML templates. So this is what's in the imported HTML file to just make up what's within the shadow DOM. The second one is HTML import. So the fact that you have a link, real import, that the browser will download and execute, this is what this is about. Then you have the custom element. So with custom element, you have a whole JavaScript API that you can use to react on attribute change or whatever else you want. And the last one is shadow DOM. So for example, if you have a select list, it's not just a simple tag. The browser will replace your select list with a whole widget, keyboard control, that kind of stuff. So the shadow DOM is all the elements needed to render this fancy select widget instead of just a div type, for example. Or the HTML file form inputs as well. So when you have an input number, and then there's arrows to increase the value of your field or decrease it, all of this is generated and accessible through the shadow DOM. So if you have web components, and we have a face lace Drupal, and we can just put features on top of that. And it makes the process easier to develop a website that's more accessible and less insecure, at least. So for example, you could have a Drupal table drag custom element if you have something like that. So you can reuse the whole table drag stuff from Drupal within your non-Drupal UI. But just using the bare minimum from Drupal. So you don't get all the messy stuff. So does that sound like something that you would do? I mean, so who's developing kind of face lace website or decoupled website right now? So what kind of issue do you run into? So I'm assuming you don't use the Drupal rendering at all. So you have to do all the filtering and escaping of the data yourself, yeah? So do you have anything slipped through the cracks, usually? Some kind of XSS security stuff now? Well, maybe you don't know yet about it. I don't know. So I mean, this whole session is about how to make Drupal easy to work with within a decoupled situation. So just making some features available to people who don't want to use Drupal. But I mean, they still need accessibility. They still need security. And they still need some shortcuts to implement Drupal features. So how can we get there? So the first thing is to have, at least on the Drupal side, a clean-based work with so we can choose what we want to expose to people who want to use it outside of Drupal. So I'm pretty sure people are not going to agree with that. So feel free to stop me and tell me I'm wrong. Well, within the GSM, we try to make as few assumptions as possible, which is why we are not going with a full Angular or React UI yet, at least. I don't know. We favor native functionality and vanilla JavaScript. So we don't have a huge amount of dependencies to be able to use the Drupal stuff eventually outside of Drupal. And generally, we try to stay out of the way. So who doesn't agree with some of this? Are you shy or just so wrong you can't speak? So let's assume this is correct. What are the tools that we use within Drupal or that we could use to make it easier? So first, we have ESLint. Who's used ESLint before? Or JSint or whatever, JavaScript Linter. OK, so most of you. Are you aware that now ESLint can auto-fix some of the white space issues that it finds? So if you have your function always needs a space before the opening parenthesis, ESLint can fix that automatically. So just run the command line, change your file, and you're all valid. There are a few rules about semicolon, that kind of stuff. So it's been nicer to clean up code now. NPM, we are not using it in Drupal yet because we have a messed up way of including third-party dependencies. But eventually, we would like to use it properly. But then within the build system around that, and that's not something we have yet. Who's heard of Babel.js? So we have a new version of JavaScript, ES6 or ES2015, that has some incompatibilities with the current JavaScript version, so new features but not compatible. So Babel is the whole point is to make ES6 JavaScript into ES5 so any browser can run it. So you are able to use the new features of the JavaScript language without breaking the old browsers. And if you want to use GraphQL that was shown this morning, the module is using ES6 JavaScript, so fancy features of the language, and using Babel to compile back down to ES5. So you can use it on IE, basically. Browserify or Webpack. Who heard about that? OK, most of you. Just compile all your stuff into one file or several files and use JavaScript modules and load them and all that kind of stuff. And JS doc. So it's nice to have a lot of code, but if you don't document it, it's useless, basically. So who's been searching for how Drupal Core JavaScript worked and couldn't find out? OK, a lot of you. So you'd be happy to know that we are now adopted JS doc as the official JavaScript documentation format for JavaScript. And most of the files are written in that standard. I mean, in the end, it's going to be on api.drupal.org. But for now, it's on my personal site. So you can go to this URL, and you will have the whole Drupal 8 JavaScript API documented. So the custom way, not all of them, but some custom events, all the behaviors that you have, all the behaviors that do have an attach function and the one that don't have a detach function, all that kind of stuff you can see that at this URL. And there are a few patch left for some files that are not documented yet. So if you feel like doing some documentation, let me know. I can point you to the right issue. Who's heard about isomorphic JavaScript? So I mean, some people use it as a way to say my JavaScript is going to run in the browser and is going to run on Node.js, which, you know, it's not actually a good term to use because it's misleading. And I mean, isomorphic, not everyone, especially in the JavaScript community, did computer science, especially in JavaScript. So there are some famous influential people that came up with a new term. We have universal JavaScript, which is misleading again. But the one I like is ShareJS, because it's shared between the browser and the server. It just, I mean, it's clearer that way. So I mean, who was like, or what's isomorphic the first time they heard it? Yeah, at least some people are honest, I was as well. I mean, ShareJS, it just makes more sense. Testing, who's doing JavaScript testing? Not many people, like three people. Yeah, we don't do that in Drupal either. And I mean, there's a few effort to make it happen. But it's not there yet. There's an issue open so that we are able to test. Not do you need test of the JavaScript, because it's not possible with the way our JavaScript is written, but do functional tests. So go on the node edit page, upload an image, and see if it works. So that will be possible hopefully soon, maybe. I took to Daniel about it. He's just working on that. I mean, there's been several core conversation, several presentation at Drupal Cons about front-end testing. And we're not anywhere in Drupal Core yet. So if you have anything to suggest you on anything, just let me know. And hopefully, we can get that at some point in Drupal 8, maybe. So I just said, we can't test. You can't unit test the JavaScript now because of the way it's written. And it's mainly because we put everything into one file. So for example, the vertical tabs. There's a kind of a library component because there's a small API on how to manage the vertical tabs. But there's also the initialization code within the same file. So it's messy to load the file and try to unit test every method because the initialization runs as well. And we have to mess around to prevent that from happening instead of having a proper library file and a proper initialization file. But that's something we need to fix. And while refactoring, which is probably going to happen whenever Drupal 9 happens, so I don't know. By that time, we should be able to use ES6 on all browsers because the latest version of IE is going to use, I mean, it's actually the best one to use ES6 on right now because it has implemented the most features of the ES6 specification. So we should be able to use the XE, so have a proper module. I have an example afterwards. So proper modules, some shortcuts of the language to make some constructs easier. And just separating the library from the initialization, which is basic, but we didn't do it. So now ES6, who are the next version of JavaScript? Who heard about it? Well, who know what this is about? OK, are you using it? Are you using it in production? Oh, no, too conservative. So one really nice thing about ES6, it's template strings. So it's a new kind of string where you can replace stuff within the string from some variables that are in scope. So the first line is just usual JavaScript string, nothing change. The second one shows you that you can have new line within your string, and it won't crash your JavaScript, which is nice. And the last one shows you that you can replace just placeholders with whatever the value of that variable is. So whatever you have in brackets or, I don't know, curly brackets, it's an expression. So it doesn't need to be just a variable. It could be a function call or something else. And it's going to be replaced by the value of whatever is within those curly brackets. So see the first one, the name, put that up our case, and it shows up our case. Easy. I don't know how the Drupal translation thing is going to work with that yet. Hopefully it will, but I don't know for sure. But you know, it's out there. Possible to use whenever ES6 is around. And if you use Babel.js, you can use that. And it will do all the messy work of making that work on older browsers. Who heard about that already? At least some new stuff for you. ES6 modules. Who's been using Command-GS, AMD, or the UMD definition, whatever? Yeah, some of you. Anyone tried to see the ES6 module spec? No? Yeah, quickly. I mean, it's fairly easy. You just put exports in front of whatever you want to export. And that's it. I mean, there are some more rules about how to export things. But this is, I mean, the easiest way to do it. And then within another file, you import it. So it's similar to Python or, I don't know, most language on how to import stuff. So you can import all the exported function and variables into an object or just import specific function of the whole module. I mean, there are a few more rules as well, but it's very flexible. And that way, you can keep your code fairly clean in the sense of you don't have useless variables in your scope. So promise. Who knows about promise? Are you using any version of promise, like with jQuery or Polyfill or something? Yeah. So it's nicer than ugly callbacks, right? Oh, no. I mean, you're never happy. So basically, it's a way to make subsequent callbacks not messy. I mean, there's more to it, but what you would use it day to day is more like that. So instead of having a very deep nesting of function, because you wait on that callback to finish to execute that one and so on, you can just chain them at the same level with promise. I mean, that's basically, there's more to it again. But we can talk about that. If you have questions afterwards. And now to slide a bit, question? Right, yes. Yeah, so it is a new function syntax, definition. I mean, I left there because it was in the example, but we can't really use it because I and everything. Yeah, just to make callbacks less verbose. And so now I'm just going to slip into the Drisky notes thing that he was talking about this morning about GraphQL and aggregating callbacks into one request to get more data and not do a lot of things. There's also a WebSocket that you can use to do similar thing, not the same, but similar. And it's basically just an open channel between the server and your browser. And you can send that to it and get it without making new Ajax calls or that kind of stuff. So who used WebSockets already? Right, so you know about how that works. I mean, yeah, well, we can talk about that after. So this morning, I was a bit surprised on the focus on the whole decoupled stuff of Dris. And I mean, the concept is nice, but the way it applies to Drupal Core is maybe I maybe not agree entirely with that. For example, take GraphQL, it's a piece of software from Facebook. I mean, it's just that right now Facebook is pushing out technology, features, that kind of stuff, mainly because it makes them look good and get them to hire people. But once that's stabilized and they get enough people, they're probably going to stop releasing software, that kind of stuff. And then we are stuck with it. I mean, it's great for Contrib, for example, but I'm not sure about Core. And progressive decoupling, so what do you have right on that? Yeah, don't remember, sorry. I'm sure you have lots of things to talk about. So yeah, and I mean, one more thing about the GraphQL and corporate technology is that with Drupal, at least my goal personally is to use Drupal to improve the standing of WebStandard. So to make WebStandard actually used on the website so that browser implementer can develop thing and say, oh, well, they use it. So we are going to continue improving our stuff and not rely on poly fields all the time. And so adding a specific format that is not yet a standard. I mean, maybe, but I'm not found of it. But I'm not the only one contributing, so it doesn't matter. All right, so anything you want to discuss about decoupled websites, the way we can make existing components of Drupal reusable on headless websites or whatever else? Or even if you have stories about how hard is it or easy to write a decoupled website, feel free to participate. No question. What do we have in Drupal 8? Can you just go to the mic because it's recorded? Thanks. What do we have in Drupal 8 for decoupled headless Drupal? Well, you have the whole REST API. But that's basically it. That's all we have, the REST API. Pretty much. I mean, it's headless, so. Yeah, for example, for ES6, is there any plan for implementing it or using it with polyfields, as you said before? Well, you were looking at the plan, basically. There's no plan. Well, there's no plan because, so right now, we have not enough JavaScript contributors and too many things to fix. And ES6 is not a high priority, especially given the browser support. And having Drupal rely on something like Babel is not really feasible because of all those PHP developers that like to complain. Requiring Node.js to use Drupal, they don't like it. So unfortunately, we don't have an easy way to use ES6 right now. But if you have ideas on how to improve the support in a core without having to rely on it, I'm open to it. Wow, that killed you. So how can we start refactoring all that JavaScript without having any test at all? That's a good question. Anybody want to answer? So how to refactor? Well, first, we need to get rid of the old stuff we have. Like, for example, the oldest script we have is TableDrag. It's also one of the most complex, which is why it's the oldest. So refactoring that in a way that's a bit more modern would help us start to move the other thing across. But I mean, the first step we could take is just separating out the library and initialization. So if we have two files, then we can do a bit more. There are some components that still use the Drupal.behavior object to store some state or utility function. And this should not be in the behavior object. It should be in their own Drupal.whatever library object. So they are like the machine name. This still uses Drupal.behavior for custom stuff. It shouldn't. So just removing that from the behaviors, separating the files is going to be a first step. And then we can talk about making actual ES6 or common JS modules out of them. Do you think that would be accepted before 8.0? So it's 8.1 material? Even later. I mean, because it's a lot of work and not enough people. Thank you. If there's like 20 people who want to work on it, maybe. They just die at some point, and we don't see them anymore. Is that a bootstrap question? So you were talking about using native JavaScript. And my question, I guess, is, are we going to stop relying so much on jQuery, for instance? And like, for instance, the attach and detach behaviors and stuff like that, or are we going to implement something more custom using native stuff? That's a good question. I like it, because I didn't put the slide, but I wanted to talk about that. So the first step in that whole jQuery story is first to identify whatever we were using and reducing what we used to what we actually needed. So it went from using the dot click function alias to using dot on all over the place. That way, if we have to replace it, it's much easier. So that's the first step. Then we need to identify the thing we abuse jQuery for. It's mostly done, but there are still some areas where we shouldn't be using it. And I've started working on a tool that analyze your JavaScript file and compile a specific jQuery version with only the modules that you need from jQuery. Because maybe you don't know, but for a while, I think it's jQuery 1.8, you're able to build custom version of jQuery with specific modules from jQuery. For example, if you don't use the Ajax functionality, you get rid of all the Ajax code and get a smaller JavaScript file. So the tool I worked on is jQuery. So like a query that stone and everything to dig into what you use and build the custom smaller version of jQuery. And what I'm hoping to do is to have Drupal run on the subset of jQuery that's a bit smaller. But he doesn't go as well as I thought. But yeah, we're not trying to go with Zepto or alternative jQuery stuff. No question? I got all day. So first of all, I should mention I've never, ever tried to implement nothing like you were describing. But since, actually, I'm more of a person. But since these days, the critical queue is all about finishing our SafeMarkup stuff and so on. I was wondering, when you say that with what we have right now, we are forced basically to re-implement all filtering and on escaping, on sanitizing, on the client side. Are you talking about encoding, let's say passing, encoded HTML markup into JSON data and then sticking it in the client? And so these days, we are talking about implementing alternative output strategies. They are called. And I think they are very similar to what Tweek already does. In fact, probably we will end up trying to borrow from that as much as possible. Anyway, the idea is that can we try to find a dedicated strategy so that we already have a way to have markup that's encoded into JSON data already sanitized in a way that makes sense? Or it would depend on context, even on the client side. So there's no one-size-fits-all solution for that. I think it ties into the GraphQL stuff from this morning because so with the REST API, when you query a node, you get all the attributes for your node. And half of it you don't use. And there's just body text and it's raw data. So maybe we could have the REST module give you sanitized HTML, depending on your format, text format. But then you still have all the other stuff on your node that you don't use. And something like GraphQL could just give you the stuff you need and escape it. And make sure it's escaped. I don't know. It's possible. I have something. They're thinking about the display. Back from that one. We've been discussing something like display modes for REST, so where you can just select the fields that want to show when you do the REST request. There you go. That would solve it. We actually discussed much of this when designing the REST module in the first place. And largely what it came down to is we could escape data, but escape it how? Even within HTML, the escaping for something that's going to appear between tags or something that's going to appear in an attribute is very different. And if you get it wrong, use the wrong one, that's another security hole. So our basic, in a sense, we decided to punt because we couldn't come up with a way to reliably do that. That would work for all receiving clients. You can do that for a specific site. The way Drupal is set up, REST module is there as almost a demo module. So if you have a specific site where you know, I'm going to want this node rendered this way all the time for this use case, you can do that with your own custom format, your own custom routes. All the capability to do that is there, but then you know your context, whereas Drupal can't know all of the contexts it might need. That's actually something we're running into with all the render API work that pretty much every time you make an assumption about the context something's going to be escaped for, you're wrong. Unless you are in that context already, you're going to be wrong. So it thinks a practical matter, a generic pre-escaped output is just not going to be viable. A site-specific pre-escaped output that you custom code, totally doable. Go for it. But a generic one I just don't think is going to be secure enough and stable enough to really work. And yes, I like the view mode's idea for reducing the amount of data you send. That is good. And we. That was for the format. Yeah. The format, again, then you actually have to render the format. And that's part of the problem. But selecting fields, we didn't do that in REST module again, mostly for saving time to keep it simple. But I fully support the option for RESTful view modes. Are there any plans or, on the contrary, any strong objection about introducing more event-based things, like event emitters and listeners? So events like what? In JavaScript, event emitters and listeners, in the way we have, well, attach, behave, and things like that. That could be another way. And it ties well with Node.js, and providing, sorry, callback hell, I think. So I mean, we do have a few events. But they are mostly for some UI stuff. Like, for example, if you open the toolbar, the space available to display the website changes. So we trigger an event that say, if you do something with positioning, you need to check that it's still at the right position. That's the kind of events we have. But we don't have more involved events. If you save something, there's no dedicated event, for example. Or was that what you were talking about? Yeah, more or less. If there was plan to move toward more of them, naturally. Well, in the case of behaviors, we can't really move to events because we need to be able to order them. I mean, it's not in yet. There's a patch waiting for a while in the queue to be able to choose which behavior you want to run and in which order. So anybody use the Drupal behavior weight module? No, it doesn't matter because, yeah. I mean, typically, that's to get rid of that module. So you are able to choose more specifically what you want to run. But yeah, behavior will not going to be events. And more events, it's not planned yet. Yeah, so I just wanted to share this architecture diagram because that's a good way to actually use decoupled Drupal. If you just have Drupal and then your Angular React app, I don't think it's a good use of your time to develop that. You should have some components between your Drupal and your front end that does more stuff and aggregates data from somewhere else or just aggregates data from the Drupal in a different way. I mean, that's a good way to use Angular and the whole decoupled stuff. But if it's just Drupal and Angular, not worth it. Especially in the now that the whole seeming experience is much, much nicer. Don't have to fight a crazy person. Any more questions? I guess we're done. Thank you. And you. Yes, sir. Do you remember? He's really the same manager or something else. Yeah, because he was thinking about that when I was there. Yeah, I mean, he's here. He's here. He's getting there. He's a really good guy, super smart. See you tonight for some beers? Yeah? OK. Oh, that's you. Oh, thank you. Without you, no documentation. No, no, seriously, thank you. Well, fixing bugs. Now it's separating all the stuff from behaviors and library needs. So we could start testing. Yeah, yeah, so basically you create the same file name.init. Add it to the library. I'm a bit less. I mean, I'm not a fan of the whole way. Because, you know, like, checking for export, I find. Yeah, yeah. But I mean, it's a feeling for the browser. Wait, so I don't know how they handle that. But it seems like who you're the one behind it. On that. OK. So no, no, no. Yeah, I just have a word. That's fine. Yeah, yeah, yeah, yeah. Obviously, when you were a candidate there's some people who are playing. They are the culprits. Yeah, we've got one follow. It's, you know, just hidden from the usually. Yeah, but then, if you have custom elements, you can still have a child element of that. Okay. You can still have a child element of that. Okay. You can still have a child element of that. Okay. You can still have a child element of that. Yeah, that's what I was thinking. We're trying to do the same thing for that very reason. It's more of a positioning for these bridges. I guess I should, like...