 Hi everybody. My name is David Wong. I, along with Jason Want, who is in the audience here, in the back, wear your track chairs for this new track, the Horizons track, which is something of a shot in the dark and also a labor of love for us. It's a new track. You'll notice that it's very JavaScript heavy, especially on the front end frameworks today. We have speakers today from Google to talk about Angular. The maintainer of the Ember project is speaking later about his experiments with integrating with Drupal. And then there's other stuff that's far afield of JavaScript throughout the week, but this will be a good setup for what the rest of the day is like. I know it's a topic that's on a lot of people's minds and I'm glad you're all here. I was actually really afraid in the last week or so that nobody would show up and they, you know, like, if I wanted to see this, I'd go to JSConf or something like that, not at DrupalCon. So the kind of interest that you guys are showing here by showing up is amazing and great. And I'll just introduce the three speakers here. We'll go from, you know, we're going to do the Asian guy first just because. Preston So works at Acquia. He's development manager in Akto, right? No, Acquia Labs. Matt Davis is a media current. He's worked on some pretty high profile things involving meteorological websites, which I think you guys will talk about today. And John Kennedy, former 37th president of the United States. Back to life now as his second stint. He's a program manager, I think, for lightning at Acquia and also the lead for the module acceleration program, which you can hear about later today. And so this will be a primer about sort of the topics you'll see throughout the day. So if you like what you see here, keep coming to the horizon track. And at the end of the session, please rate, you know, if they do poorly, that's fine. You can crap on them. But if they do great, you know, please leave your comments there as well. Thanks everybody. All right. Thanks, David, for that wonderful introduction. So how's it going? How was the keynote? Awesome, right? I was actually really, that was the first time I saw that video. It was pretty awesome, right? By the way, there's a lot of seats up here. Please don't be shy. We don't bite. You know, please, you know, feel free to get friendly, filter into the middle here. I always hate seeing people standing up in the back because, you know, there's always seats up here and we want to make sure everyone has a good time. So just to be very clear, this is next level Drupal. If you're looking for the Drees note that just happened already. And this is not Bourbon Street, but welcome. And we're going to have a good time today. I'm really excited because we're introducing this horizon track. And, you know, it's a very tall order. I think we've got some really exciting stuff on the docket for today and all week on this track. So should be very exciting. So just to reiterate that introduction, let me go ahead and introduce myself. Or actually, let me start with Matt because he's the first one. My name's Matt Davis. I'm a lead Drupal architect for Media Current. I'm John Kennedy. I'm the product manager for Acquia Lightning as the enterprise authoring distribution that Acquia is building and also the program manager for the module acceleration program. And you should all come here about that at 215 today as well. Alrighty, I'm Preston. So I've been involved in Drupal since 2007. I'm development manager at Acquia Labs. And very excited to be here today. Alrighty, so just to go through a little bit of what we're going to talk about today, this is going to be a pretty wide ranging session about a variety of different issues. And I think we're going to be able to provide a bit of an introduction to a lot of the things that we've been talking about quite a bit in the Drupal community. I'd like to start by talking about risks and rewards of decoupling Drupal, which I think is a good initial baseline for us to talk about. I do want to talk about progressive decoupling, which is a concept that Dries promulgated last year. And then we'll move into a couple of very interesting case studies and examples. Matt Davis and John Kennedy are going to talk about weather.com, a very interesting use case, as well as the decoupled blocks module in Drupal 8 and how that works. And John will also delve into progressive decoupling, how that looks in the outlook for aquia lightning, as well as the future of what progressive decoupling might hold for Drupal. So without further ado, let me go ahead and please, once again, for those of you in the back, there's a couple of seats up here in the front. Please feel free to come up here and join us up front. Alrighty, let's go ahead and get started. So what are the risks and rewards of decoupling Drupal? You guys have probably heard the phrase decoupled Drupal quite a bit lately, or headless Drupal, or API-first Drupal. There's a lot of buzzwords going around. And it's very important to clarify what exactly these things mean. So just to be very clear, decoupled Drupal is the process of employing, in this case, what we're talking about here, is the process of employing a different frontend from Drupal's own. We're very familiar with the Drupal theme layer, which uses twig as a templating engine. And it's most often used with a JavaScript or native application framework. In this case today, we're going to be talking about JavaScript frameworks, which are typically used in a universal or also known as isomorphic way, which means that they are capable of being executed on both the client and the server. Now, the decoupled frontend actually communicates with Drupal via what's called a RESTful API. REST standing for representational state transfer. It's a term promulgated by Roy Fielding in his dissertation. And just to distill it down to the most basic tenets of this idea, REST is the architecture of the web as we know it. If you're familiar with HTTP and these methods that are used very often, such as GET, POST, PATCH, and DELETE, these are things that are available right now in the Drupal 8 web services set of modules and are very powerful for communicating with Drupal without actually interacting with Drupal's frontend. So using Drupal actually as a data service isn't a really new concept. We had services in Drupal 6 and 7, as well as the new version of services in Drupal 8. We had RESTWS and a lot of other modules actually. There's been a really rich ecosystem that's developed of RESTful modules in Drupal 7, 8, and of course beyond. Now, the thing to keep in mind is that Drupal can be used to back other primarily backend applications, such as if you have a Rails application or if you have a .NET or other Symphony application, let's say. These days, a lot of what we're talking about is really allowing for a lot of flexibility on the frontend, meaning we can use Drupal to drive native applications or single page JavaScript applications. Now, single page JavaScript applications tend to depend on what we call universal JavaScript. And these are, you know, there are a lot of popular examples, such as Angular, which we'll hear about later today, as well as Ember, which we'll also hear about later today, and React. These clients, you know, are capable of performing client-side re-rendering without incurring additional page requests. One of the things that is problematic or, you know, one of the important things to keep in mind about Drupal's page-based model is that you have a full page refresh every time you hit a new route. Native applications, in this case, usually have their own rendering systems because they're built in Objective C, in the iOS case, or Java, in the Android case. So just to give a little bit of history and to illustrate what this is all about, right now the way that Drupal works is that, let's say you have a newsletter subscribe form. Generally speaking, when you hit that submit button, it's going to trigger a full page refresh. And as you can see here, what we've got is we've got two distinct bootstraps of Drupal. The Drupal front end is part and parcel of Drupal. It's a monolithic architecture, in this case. Data is being sent into templates, and these templates are actually what's responsible for putting together the HTML that we actually see as the generated output. Now, what happens here, in this case, is that you have to wait. There's going to be a white screen because the page is reloading. This changed quite a bit in the early to mid 2000s with what a lot of people call Ajax, asynchronous JavaScript and XML. And in this case, what happens is you have a, you know, your server side is capable of consuming Ajax requests. And in this case, what happens is you have a little spinner, you know, when you hit submit, you're going to get a little spinner and a little update is going to happen. That's a very granular, small DOM update. And in this case, what you have is you have an Ajax response, which actually gives you, let's say, the success message. Now, with dynamic pages and more client-side re-rendering, these kinds of tenants have really shifted quite a bit. Rather than actually use, you know, Ajax to really perform very granular DOM updates, we're actually using XML HTTP request, which is a JavaScript API, to actually allow us to access the REST API that lies on top of Drupal. And in this case, what we're talking about is a decoupled frontend, which is completely separate from Drupal, and interacts solely with Drupal through an HTTP request and response pattern. And as you can see, what we've got here is we've got actually a re-rendering going on, where the spinner in this case is indicating to the user that there is a state change here. And this, you know, sort of left and right sidebar, as you can see, the right sidebar completely re-renders and has the success message. So decoupled Drupal, obviously, I'm sorry, whoops, decoupled Drupal is very important because, you know, you can really use any language that you want, any sort of technology that you choose on the frontend. And so in this case, you know, there's a lot of different examples of this. The first is a single-page application in Universal JavaScript, which uses a REST API. You can have a Java-based native Android application. And of course, you can also have a single unified REST API that controls multiple applications. Let's say, you know, you might have a Silex application that is written in PHP that you're serving data to. So it really runs the gamut. There's a wide spectrum of things that you can do with decoupled Drupal. Now, what are some of the rewards of decoupled Drupal? Well, the first is separation of concerns. A lot of us are very concerned about structure versus presentation, which means that structural data, structured data should be separate from the presentational information that actually controls the aesthetic and appearance of that data. Also, content syndication. A lot of what we've been talking about today is the idea of writing once and publishing everywhere. You want to be able to write content and have that sent out and distributed out to all of your different clients. Also, differentiated development velocities. One of the things that a lot of people have alluded to recently is that if you have a separate front-end team, a completely distinct front-end team that only knows JavaScript and does not know PHP, it can be very beneficial to actually have distinct velocities. Also, a rich application ecosystem. You can actually enable a very sort of large decoupled architecture with Drupal as the centerpiece of that application ecosystem. Now, there are some risks of decoupling Drupal, which I do want to highlight, and I think many of us are aware of this. If you've read some of Thrice's blog posts on this topic recently, you'll probably have seen some of this. The first is that oftentimes when you have an additional application that lies on top of Drupal, you'll introduce an additional point of failure. For example, let's say that your front-end application is hosted on a different domain than your Drupal site. What might end up happening is that if your application goes down, you no longer have an inlet for people to be able to actually browse your to use your experience. Also, there's no cross-site scripting or input sanitization, which Drupal automatically provides out of the box. Obviously a lot of the frameworks have their own systems for actually making sure that all of the user input is sanitized. Third, there's no in-place or in-context editing or administration, which means that contextual UIs, things like contextual links, toolbar, in-place editing, which we know and love in Drupal 8, are no longer available, and some of your editors might be concerned about that. Also, the concept of layout and display management, you really don't have the ability to control layout anymore. If you're using panels, there's solutions out there for you to use the fully-decoupled front-end with panels, but you don't necessarily get the full flexibility of doing that. Also, no pre-vibable content workflow, which means that if you have content workflow where you need to make sure embargoed content does not get served publicly, that's something where it's very difficult to actually ascertain how to make the REST API serve out this content in a way that's robust and protected from the public. Also, modules affecting the front-end, if you have modules that are creating forms for your Drupal front-end, oftentimes that is completely lost because you no longer have access to the form API in Drupal. Finally, a lot of site builders and content editors rely heavily on system errors and notifications, what we know as a DSM. These things are no longer available when you're using Drupal as solely a back-end, a solely a data service. Also, one of the big compelling features of Drupal 8 is what's called cache tags or cache ability metadata in which you can use cache tags to declare dependencies on data that's provided by Drupal. This is very important because you can have differentiated caching of page components. This actually enables what is one of the most compelling features of Drupal 8, which is big-pipe progressive loading. If you have a piece of content or a piece of your site, a piece of your page which is less cacheable, big-pipe actually enables you to differentiatedly load that so that the less cacheable content comes later. Finally, last but not least, no accessible markup or user experience benefits. Oftentimes, if you are going to be decoupling Drupal fully, you are going to need to worry a lot more about your user experience and your accessibility. Drupal obviously has ARIA rules built in completely. If you are needing to serve users who are relying on assistive technologies such as screen readers or refreshable rail displays, it's a very important thing that your accessibility and user experience are first-class. One thing I like to say is that if you are decoupling Drupal, you have to become the markup and accessibility guru. When should you decouple Drupal? Oftentimes when it comes to Drupal, you might not want the heavy weight bootstrap of Drupal to be on your back end. Oftentimes you might want to use a microservice or something like that. The way that Drees recommends decoupling Drupal is if you have a site that's preexisting in Drupal, that powers other sites or powers one or more other applications, it's a really good idea to use that as the centerpiece of your application ecosystem. You should not generally use it for standalone applications or standalone sites. You don't really need the overhead of a decoupled architecture if you have a standalone site or application unless you are actually someone who's pursuing let's say a full stack JavaScript architecture. You can actually with Drupal lead to workarounds that will duplicate or obfuscate some of the integrity of end to end Drupal. So there's actually a better solution out there which I call progressive decoupling. How many people have heard of progressive decoupling? Okay great, a lot of you have. So why progressively decoupled Drupal? Well, let's go back to what we were talking about in terms of this illustration of the way that fully decoupled Drupal works in the context of JavaScript. Well, in this case, once again, you have an HTTP request that's coming in from the client side and the REST API will process that request and serve out a response that will actually be interpreted by the client side and fill in the right sidebar in this case. Now generally speaking, in this case what's happening is all of the rendering is taking place through the JavaScript framework. And this can be really beneficial if you're a front-end developer and you really value that very strong rendering process. However, in progressively decoupled Drupal, we turn this model on its head. Rather than using the JavaScript framework on its own, we actually interpolate the JavaScript framework into Drupal's front-end and allow the REST API to serve as the means of communication between the JavaScript framework that is inside of Drupal within Drupal's front-end and Drupal itself. And in this case, what this schematic is illustrating is that the left sidebar might be served out through Drupal, the overarching page structure is served out by Drupal. And then you have a right sidebar, let's say, which has a lot of client-side re-rendering, which actually is controlled by a framework such as Angular or Ember. Now, let's go back to these risks and let's talk about how progressively decoupled Drupal actually addresses all of these risks. So one of the rewards of progressive decoupling is, let's say that you have a Drupal site and you have a JavaScript framework. If you are interpolating your JavaScript framework into your Drupal site, that often means that you're going to be hosting both of them at the same location, right? So you avoid a lot of these issues, of course, which is a big point of contention right now, or a big point of concern right now in the Drupal community. You also get access to Drupal's form validation and cross-site scripting protection. And finally, if you are having editors who are really concerned about things like in-place editing, things like preview, things like contextual links, that's actually provided for in this context as well. So you can have your editors continue to preview, continue to enjoy things like, well, enjoy, things like system errors in the context of Drupal. Also, layout and display management, if you want to use panels and you want to continue to be able to leverage the block system in Drupal, those are things that you can still leverage with a partially decoupled, a progressively decoupled portion of the Drupal front-end. And a lot of people actually refer to this as hybrid decoupling, but that's a little bit confusing because of the term hybrid app, which exists as well. So the other big issue here is that you have previewable content workflow. If you have embargoed content, because of the way that Drupal is able to serve out content that is embargoed and give you access to moderated content that is not publicly visible, you can very easily do that with Drupal as well if you have, let's say, components of the page that are still content-based. Now, if you do have modules affecting the front-end, such as Webform, that's also something that can remain in Drupal. But obviously, you can also power your other forms, let's say in the sidebar with the same approach that you would find in the JavaScript framework. Finally, big pipe is a really, really big thing. You know, I think that a lot of us have seen the demo that Wyn Lears has produced about how you can see the page actually loading in this sort of differentiated fashion. And that's a very, very compelling feature that I think is very important not to jettison in Drupal 8. Finally, Drupal once again has accessible markup out of the box and a lot of UX benefits if you are using Drupal's built-in UIs, which means that a lot of those features can be leveraged right away. So without further ado, I'd like to go into a case study about weather.com. Here's some further background for some links. And actually, one of the things to keep in mind is that weather.com has actually been doing progressive decoupling for several years now. They have, you know, with the help of Media Current, have built this progressively decoupled panels implementation, which introduces, which interpolates, angular components into Drupal. So just to really quickly go over what this looks like from a schematic point of view, what's going on here is that as an editor, if I want to manipulate the page layout and I want to have a left sidebar of content and a right sidebar that's more of like an application, I am very able to do that. And what happens here in this case is that you can have a component of your page, which is controlled entirely by Angular. And so in this case, you have server-side rendered output that is served by Drupal and you have client-side rendered output which is served by Angular. And in this case, what can happen is that your server-side rendered output from Drupal can actually be the sort of starting point for Angular. And you can basically have a handover to Angular to enable you to have that initial server-side render and not wait for the spinner to, for the content to load. So with that, I'd like to introduce Matt Davis, who will talk a little bit about weather.com and their approach. Thank you. So thank you very much, Preston, for the introduction. And as he mentioned, weather.com is a Drupal site. It launched in November 2014 and has been going along ever since. So before weather came to us, they were evaluating a bunch of different CMSs. And when they first approached media current to architect a solution for them, they presented us with some metrics about their current architecture. So this is a little bit about it. At the time, they were running 144 origin servers and doing an average of about 50 million page views per day. Now, one of the things that makes the weather.com site really unique is that although there's high traffic all the time, there's also extremely high variability in traffic. So on a normal weather day, they may do 50 million page views, but when a major weather event occurs, it can spike up to like 800 million page views per day. So they were having serious problems, even with 144 origin servers keeping the site up when major weather events would happen. Part of that is also because another unique feature of weather.com is that it has to be hyper localized. At the time, they were doing about 2.9 million different locations. They were serving unique data for, now it's actually closer to a billion because they're down into sub zip codes. So it was a very unique and challenging set of problems that we had to face just in terms of the traffic and the caching strategy that we wanted to implement. So the overriding concern when architecting out a new weather.com was performance and caching. But we also had other major considerations that we had to look at. They had a large in-house front end developer team that we wanted to enable to really get a lot of traction and have a high feature velocity. They also have large editorial teams that want to be able to generate new content as quickly as possible. So let's go into each of these a little bit and how we address them. So for performance and caching, what we had to do was first take a long hard look at what a weather.com page, a typical page looks like. And what we found is that different sections, different pieces of the page had different needs in terms of how long they could be cached, how localized they needed to be, and things like that. So we began to break these pages apart into these sections. We would serve the same exact wrapper with the head and the basic foot header footer and the pieces of content that could last the longest from origin to every single person. Then we had, using Akamai's ESI, at the edge, we could do edge calculations as well for region-specific calculations that we needed to do that were still not hyper-personalized. So we had three places there we can do. Origin, ESI for edge calculations that are region-specific, and then client side for things that need to be hyper-personal or that just need a richer user experience that front-end framework could provide. The front-end framework we went with for this project was Angular 1. They've been on Angular 1.3 now for almost two years. And after that, we had to deal with how to cater to their front-end developer teams. So let's talk a little bit about what front-end developers want to do. Specifically here I'm talking about JavaScript developers. JavaScript developers want to write JavaScript. They don't want to have to care innately about Drupal or learn all of these Drupal APIs, and they want to be able to keep up with where the JavaScript world is headed, which, if any of you know, it's a very rapidly evolving ecosystem there. Things are changing really quickly. So they want to spend their time learning JavaScript and not Drupal. Editorial teams, on the other hand, want to be able to create content. And for the weather case specifically, they wanted to be able not just to create new types of content, but create entire new pages and layouts on the fly without having to go to a developer every time that they wanted a new layout. So we explored all of these independent needs and came up with a solution that we call the presentation framework. And as Preston mentioned, this is a progressively decoupled solution built heavily leveraging the panel's module. So at its root, it's a way for us to allow editorial teams to put components on pages. But these individual components can be created independently by front-end JavaScript developers. They're completely encapsulated each component in its own subdirectory with whatever JavaScript, CSS, and template files it needs, and then a small JSON-formatted file with metadata about that piece of functionality that declares it out to Drupal. Drupal walks all these directories, finds these JSON files, and ingests them into C-Tools content types, or panel spanes, as you may know them, so then editorial teams can place them on pages. And those modules, once ingested by Drupal, can be served either AdWords or by ESI. So why panels? Well, we got a lot of benefit from panels. We heavily leveraged the variants and selection rules so that we can deliver different types of displays based on device detection, for example, while maintaining URL parity. We can reuse and export these panes so we can have a nice developer workflow of being able to save everything into code. We can also use contextual information and, for example, take a zip code from the URL and generate a full-context object with a bunch of location data about that and pass it out to the client. And also, for editorial teams, it's got the drag-and-drop interface that makes it easy for them to put new pieces of content onto their pages. So that's the long backstory, and as I said, weather.com launched with this system back in November 2014, and it served their needs very well. They actually went from 144 origin servers down to 10, and most of those sit idle now due to this new caching strategy. But that's all kind of history now. So what's been happening recently is we are migrating their sister site, Weather Underground, onto the same platform. This migration began, discovery for it began last November, and I went out to San Francisco to Weather Underground headquarters, and one of the first big asks the team there had was, we don't really want to use Angular 1.3. We'd really like to explore using a more modern framework. And so we began looking at some options and settled in on using Angular 2, which at the time was still an alpha state, but Weather Underground likes to live a little dangerously, and I was excited at the opportunity. So we dove in, and I started doing investigation into what it would take to make this same exact framework work with either Angular 1 or Angular 2. Now, what makes this situation especially complex is that both sites live in the exact same code base, as in the exact same repository. So any reorganization, refactoring that we did on the presentation framework for Weather Underground had to not break weather.com as well. But we got some really exciting results out of it. So the goals of framework agnosticism, as we open this up to allow JavaScript developers to actually use multiple frameworks. But we still kept some guardrails in place because the actual framework bootstrapping and definitions were still written in Drupal code, in Drupal modules, and we were able to still leverage all the panels editorial experience that we got from this as well. I got a little ahead of myself here. So the key thing here though that I haven't mentioned is that by refactoring to allow us to use either Angular 1 or Angular 2, we really opened the door now, the presentation framework, by adding another small sub-module, we can declare a React presentation as well, and then allow people to start writing React components, or Ember, or whatever the next framework is that we haven't even heard of yet. We can just write a small sub-module that will hook into the existing presentation framework and enable those JavaScript developers to create those things. So, where is TWC, the weather company, headed? Well, as it stands today, they have the ability on a per-panels variant basis to choose which presentation they want to use. So right now that's Angular 1 or Angular 2, but we're actively working on other definitions for these frameworks as well, and we're really excited, the TWC team is really excited about how this will really open up their ability to innovate and experiment. They're also looking into the ability to use, now we're using Akamai Ion and EdgeScape to do bandwidth detection as well, so they're looking into the possibility of delivering more lightweight frameworks for lower bandwidth users, which I'm really excited about also. So, that is where things are headed with TWC. But what about Drupal 8? Because this is all still living in Drupal 7 World. Well, I'm really excited to announce that we've been working on a port of this same model to Drupal 8. It's called the decouple blocks module, and it has a few key differences from the presentation framework. One of the big ones is that this is actually open source, and you can go download it today and start playing with it. It's currently a sandbox project, but we're working on making it a full project on Drupal.org. Instead of being built on top of panels, now, panels in Drupal 8 is actually built on top of the new blocks system using the new plugin API, which is really, really, really groovy. You can reuse blocks now. You can export them to code. A lot of the things that were problematic about blocks in Drupal 7 are gone now. And the current decouple blocks module already supports Angular 2 and React, and we are actively working on an Ember definition as well, but we need a lot of help. And with that, I'll hand it over to John to talk about the progress we've made with it. Thanks, Matt. So I hit up the module acceleration program, and this was a module that we thought was really important because it opens up a new concept to Drupal, which is JavaScript component assembly. And that's gonna be, I think, a very strong concept going forward. Preston talked about it a little bit. What we did is we got a sprint together with Media Current and Acquia up in the Acquia offices in Boston to really push this concept forward and get the module out there for Drupal 8. So by Drupal Con, everyone can go and try this out and start using it on their sites. So these are the people we had along. Adam Ted, Derek Matt, Bob, Mark, and Adam. There's two Adams. And those are their Twitter pictures because that's how you're gonna recognize them. And I was there for moral support. I was there to do logistics and get the space and feed everyone, which is critical in a sprint. But these guys really put in some amazing work and got some great stuff done. So we had seven developers over three days. We went to a baseball game, and I'm from Australia, so that's novel for me. We went and ate seafood in Boston, which is pretty epic. We're in Orleans, but Boston's pretty good as well. And we did a massive refactoring of the module, which Adam Honek, who couldn't be here with us today, really spearheaded and meant that we have a match. What was the code decrease that we had? It was a massive... Well, when we started the sprint, we actually had Angular 2 still in the repos. I think we had a single pull request that was minus 100,000 lines of code. There you go. Minus 100,000 lines, yeah. Right, and we had beer. So there's the ball game. There's lots of fun. There's some of the food from Boston, so I encourage you to visit Boston at some point. And we actually released it. Well, we've got the module on GitHub, and it will be a full module on Drupal.org very soon. I think it's our TBC right now. It's our TBC, yeah. Right, so here are some of the things we got done. So it's now easy to use for JavaScript developers and Drupal developers, based on a lot of standards that we put in there. It's a single bootstrap with the underlying framework. So if you've got a ton of Angular components, you're only gonna bootstrap Angular once. Site builders can configure the components in the UI. So I'll explain these a little bit more later, but this is a brief overview. It means that I can add a field as a developer and that field is accessible by a site builder. So developers can require a context and pass through values to the JavaScript component. And components can be used rapidly. And this is a roadmap item, but we think it's really interesting to generate static page prototypes and living style guides. So to kick this off, haven't refreshed this page because actually now we're framework agnostic. You can actually use any framework on this. We've tested it with Angular 2 and React. You can use any framework. And the path of components is really simple. It's standards-based. So it's really simple to know where to put your JavaScript code. So site builders configuring the ability to configure components in UI. So the developers can write configuration files into the info.yaml file. And these fields are shown during block placement. So if you can imagine the experiences, as a developer there might be a ton of things that I want the site builder to define in a text field or in a dropdown or in a radio buttons that I want them to define so that I can build this component once and then it might be on a ton of sites just like Drupal and configured in a multitude of different ways that opens up the possibility that I might write a block or a module for my company or for an open-source module that everyone in Drupal can use. We can really think about quite agnostic use cases of these components. An example might be, and this is a very specific example, but this is a very generalized concept. The developer creates a donation component with a field for a suggested donation. And then the site builder can actually specify that amount when they're placing the block with a static value or maybe more interestingly, a token from Drupal. So this opens up a ton of things you can do, information that you're getting already in the Drupal bootstrap. So components can be contextually aware. Developers can tightly couple components, component functionality to Drupal's existing system for wrenched entities. So you imagine I might have a category, I might have a taxonomy, I might attach that to my node, and that can be passed through to a component. And the example we've got is you might be pulling recommendations with a JavaScript component, it might be lazy loading, and you can pass the taxonomy term through to that component if it exists, which is a really powerful concept, connecting Drupal and JavaScript, tightly coupling them together. So, and the component can potentially display conditionally, this is the kind of concepts that we've built in to the module. And this is a, so static prototypes and style guides, this is kind of more of a, this is aspirational at the moment, it's not built at the moment, if you can imagine your organization has a library of components that can actually use site builders can use to quickly mock up what the site is gonna be like. And then this allows for a model where all the teams can work in parallel because you can have themers changing the look and feel of those components while backend developers might be, Drupal backend developers developing Drupal, API developers outside of Drupal developing their components and all of these teams can work together from that prototype. So, it was great to have Media Current up at the Acquire offices, I think we had a great time and we got a ton done and so I wanna thank Media Current for that. This module hopefully will make a big impact in Drupal's ability to address the coupled and now Matt's gonna give us a short demo. Maybe, we'll see. So I just wanted to show you guys a little bit about how this actually looks in Drupal 8. I'm gonna be really brief but I encourage everyone if you're interested reach out to me later or find me, I have a brainstorming buff on this Wednesday and we're gonna be sprinting all day Friday on it too. So if you're interested in getting involved come find me. So, this is the module PDB for progressively decoupled blocks. You'll see inside here, we have a few sub modules for different frameworks. The Angular 2 one is currently the most fleshed out but basically the main module itself all it really does is define some block and block derivative definitions and then it has component discovery which is built on top of the core YAML discovery system in Drupal 8 that walks the directories and finds these YAML files. So we have our own custom YAML type just like modules or profiles or themes. This is the PDB YAML type that each component will have. So let's take a look inside one of these sub modules. So this is the progressively decoupled blocks Angular 2 sub module that defines this specific framework for use by the system. And we have some example components in here so I'll show you one. What it looks like is just if you're familiar at all with these component-based Angular 2, this is exactly what you would see in any normal Angular 2 component. You have your component file definition and then your template file and you have this small info file that's the only piece that you have to add to your existing Angular 2 component to declare it out to Drupal. And once this piece is here, when we go back over to the page and place a block, these are interpreted into blocks that we can place on these pages. And you'll see I already have a couple here on this page so I'll just show you what it looks like. Oh, nice, I've already done most of these. So this is the to-do list that I made last night. I can mark most of these off and something else. All of this is being stored in local storage as well so you can actually refresh the page and it'll store your to-do. That's just one example we also have over here, a little tour of heroes. This has two different components so when I click in on one, it loads a sub-component and then it can change things. So that's a really basic example but I hope that shows just how you can create these encapsulated pieces of front-end functionality without having to really know any Drupal at all and then you can just drop them in and allow your site maintainers to actually put these on pages in really dynamic ways. So we're really excited about this guys and I'll hand it back to John. Yeah, you were offline. So I may have to speak off the cuff. So I think this is ready for developers. The idea of inter-component communication that Matt was demonstrating is really powerful. Bringing JavaScript developers into your team now should be a lot easier. Preston, can you fix your internet connectivity so I can keep going? Do we want to do maximums? No, no present. Is it not, you know, on my list? Very sad. But what I think is left to do, can you do that while I talk? What I think is left to do is actually to bring this, bring more functionality of site builders as well to authors, to people assembling experiences. And so my other role, apart from DAMAP, is actually a lightning, which is really about, you know, a site builder experience and authoring experience. We want to bring this concept of assembling JavaScript experiences into lightning so that everyone can use it. So that you've at least got an example and even if you don't want to use lightning, see how to implement a couple blocks, you know, in your Drupal site. So you're back on? Yeah? Just a few seconds. Just keep going. This is all filler now. So, you know, at the moment, there's a current approach for decoupled blocks. There we go. You will be testing decoupled blocks with lightning. We're gonna continue to improve progressive decoupling and the concept of JavaScript application assembly. And I think this actually could be a concept that's great for JavaScript as well because at the moment it's still very developer driven and we know in Drupal that as soon as you enable people and other roles in teams, you can get leverage. So it's more than the developers that can actually be developing experiences as soon as you allow for assembly. So, you know, current approach, utilize the decoupled blocks module, share standards with JavaScript developers and train authors, you know, but we have more plans for progressive decoupling. So, you know, we're thinking about lightning integration in 8x1.2 and there'll be a lot of enhancement to the panel's ecosystem, making this easier and easier for authors. There will be more component configuration standards we're building into this module and intercommunication between components. So, advantages of JavaScript application assembly. You can do advanced content management. Yay, you've got Drupals. You can do layout and preview. It facilitates large teams. As I said, there's a lot more parallel development that can go on and obviously maintenance and security. These are solved problems in Drupal and they're definitely not solved in JavaScript. So, at the moment, we're still left with a situation where you can't do server side renders of JavaScript and this is an often requested thing by JavaScript developers. They wanna process in node before it hits the front end and this isn't in the model yet. And it's a two-step publishing process because you create the component and then the site builders place them on the page, not necessarily disadvantaged depending on how you look at it. But in the future, we believe we are going to integrate a model where you can activate a node server to do server side JavaScript rendering. It won't be critical, but it will be possible and socket IO integration for real-time communication JavaScript component templates, as I said before. The possibility of native compilation, I think, is it Ionic? It's the, yeah. So, in JavaScript, there's this concept that you can potentially compile your JavaScript application and have an iOS app or a, I didn't know the Google one. Android. Android app. And this is amazing. To be able to do truly native mobile but with one development experience is pretty cutting edge and this is something that we wanna eventually see in progressively decoupled. And JavaScript framework integration core. This is incredibly controversial at the moment. I'm not pushing my views on all of you. I think it would be a good thing. There's been a lot of discussion at the moment and I hope we continue to have a lot of discussion about potentially selecting a particular JavaScript framework to boost Drupal. So, some future use cases. We really think commerce integrations would be a great use case for this and customer self-service portals and other one, live content streams. There are a lot of things at the moment that you can do in Drupal but would benefit from what JavaScript can bring. So, join us for the sprints. We also need to have a Q&A though and I don't think we have a slide. So, maybe we'll just go with Q&A right now. If you wanna step up to the microphone here, I don't think we have one on the other side but it'd be great to have some questions from the audience if you have them. Hello. So, if you can go back and, because it went really fast, I think the portion about decoupled, fully decoupled verses, the progressively decoupled, maybe walking through that a little more fine-grained. Yeah. Sure. Here, actually I'll. Yeah, that'd be interesting. Yeah. There you go. So, the thing to keep in mind is that when you fully decouple Drupal, what that means is that you're basically separating the front end from Drupal entirely. So, you have a Drupal site that's sitting over here on let's say, example.com. Then you have your front end application which could be hosted on the same place or could be on a different domain entirely hosted elsewhere, which means that that introduces some cross-origin request security issues if you need to basically have communications back and forth. Now, progressive decoupling is different because rather than using decoupled Drupal as a means to serve a fully decoupled application that is completely standalone. So, your JavaScript application that you're building universally, let's say it's an isomorphic Angular application, is going to be something that is completely on its own and completely decoupled from Drupal. Which means that Drupal has no visibility, no introspection into what's going on on the client side. And Angular 2 also has no introspection to what's happening within Drupal. The only communication that's available is REST API. The way that progressive decoupling sort of turns this model on its head is that you have a framework that's introduced into Drupal as a means of improving interactivity. So, I think one of the good ways to think about it is use cases, right? If you're building a fully decoupled application, oftentimes you want to have an auxiliary single page application which is part of a sort of larger docket of applications that you might have. But if you're just looking for ways to introduce interactivity into a pre-existing Drupal site or basically enable your teams that if you have a front end team that's distinct from your editorial team, you want to be able to empower both of those teams to pursue their own velocities. That's the case where progressive decoupling is very good because as a site builder, as a site assembler, you know, I want to be able to manipulate my layout. I want to be able to touch something on the page and edit it directly. I want to be able to have my toolbar and contextual links. And when you do, when you have your standalone fully decoupled JavaScript application, that is no longer available. So, I don't know if that answers your question. So, was that accomplished by the, I think you guys are referring to the, there's like a sub-module or something? Is that what accomplishes that? That's the part I was a little confused about. Matt, do you want to? Well, the sub-module is what allows a specific framework to integrate with the overall system. The main module is what actually will walk through these directories, find these JavaScript components and make them available to Drupal for placement on pages. So, as opposed to this fully decoupled thing, we are bringing JavaScript pieces into our Drupal site as a way to think of it. And one way you can think of it is that. There's a specific section. Yeah, one way you can think of it is that if you have a Drupal site, right, the only modules that you're going to enable on the Drupal site are going to be the REST modules and core, REST, HAL, BASICGAUTH, you know. And what happens in that case is that your, all of your functionality is wrapped up in that universal JavaScript implementation. It's not wrapped up in sort of Drupal and let's say Angular together in the same bucket. Thank you. Yep, look. Yes, hi. Hey guys, so I'm an Ionic developer and a Drupal developer. And so right now I have Ionic apps that are fully decoupled from Drupal. No, at the end when you guys were talking about lightning that I'm not sure what that is still. But how does that, how does I guess doing this progressive decoupling help the Ionic and Drupal development processes? Right now they're two separate environments completely. And I have to maintain both of those. Yeah, so I think it's interesting because when you think about, you know, generally speaking when you're using Ionic, you're compiling Angular down to, let's say, you know, Objective-C or Java. And I think in this case it's kind of speculative because, you know, right now the concept of progressive decoupling is predicated on the idea of components. But there's a wide spectrum of possible limitations of progressive decoupling. There's actually a very interesting use case where you have a, you know, sort of a Drupal site that is only serving out a page shell and the rest of the entire Angular, sorry, the, everything that's contained within the body tags is driven through Angular, let's say. John, do you wanna speak a little bit to Ionic and Angular or? Yeah, I think, you know, lightning is going to be an assembler experience that we build out, you know, we have something now which really focuses on, you know, workflow layout preview media allows authors to integrate those, utilize those functionalities. As we build it out, this will be something we seriously think about in our roadmap. You know, if it's possible to have an experience where a site assembler can drag and drop components into an experience and then hit a button and compile that, that's probably a long way off, but, you know, it's something that would be amazing if we get achieved. Now, one potential use case also is that if you have, you know, component-based rendering, let's say, and you have a Node.js microservice sitting in front of your Drupal site, right? That's one case where Ionic could really be powerful because right now, obviously, you can't compile a Drupal site in PHP into, you know, using Ionic into a native application. However, if you do, you know, layer on top some kind of a Node.js service which will provide that rendering, that differentiated rendering, that, you know, processes output from Drupal, for example, using the services module in Drupal 8, then, you know, that's something that you could leverage as well. Thanks. Hey, Mark. Hey, how's it going? I had a question. So you mentioned that with the progressively decoupled blocks that one of the challenges is that they're rendered purely on the client side and don't have server-side rendering at the moment, and that you were looking into the possibility of rendering those via Node.js. So how do you see that playing out in the hosting landscape of how PHP and Node would run side-by-side? Is that something Akwi's looking to do or using an outside Node.service or, I don't know, thoughts on that? Yes. So, so yeah, just to expound on that, yes. Akwi is currently looking, you know, into the potential of hosting Node.js, and I think that what you're finding in the hosting industry nowadays is a lot of, you know, what I would call sort of a widened breadth of hosting solutions, right, where you have people who are offering both LAMP and Node.js, let's say, in the same hosting subscription, which is a really powerful idea because it means that you could just pay for it once and have all of your hosting taken care of. Now, it does introduce some difficulties, which you and I have both talked about in the past. Obviously, Node.js hosting is something that's a little bit less well-developed than LAMP, and it is something that, you know, could require potentially multiple hosting providers. So that is one thing that I think is, you know, it does require a bit of caution. In this case, you know, there are other options. Obviously, there's the PHP VHS extension, which a lot of people have been talking about lately, but a lot of people nowadays, what I find the majority of people doing for this solution, for a solution, is to actually use a Node.js microservice on top that is most often hosted elsewhere. Or, you know, yeah. Yes. Thank you. It was a good session. I enjoyed it, and I have a question. So in the first slides, you mentioned that the JavaScript developers, they don't like to use Drupal API. They don't want to know about it. So how does this module solve this problem? Does it still need to know Drupal API, or is there any, like, wrapper? So you don't really need to know any Drupal APIs at all. I mean, the components that we saw in the demo, the only interaction they had with Drupal whatsoever was small pieces of data coming through Drupal settings, which were just static pieces of data that they had access to, right? And it's the same thing with the pieces that we've built in, like configuration forms. You can actually define those configuration fields in your info.yaml file. So you're still just writing yaml. You don't have to learn the forms API. You're just saying, I want a text field with this name, and when the block goes to be placed on the page, that text field appears, and whatever someone types into that text field is sent forward through Drupal settings. So we've really tried to minimize the amount of direct interaction that they would have to have with any Drupal APIs, you know? Right, and is there any integration with views module? With views module? Yeah. Right now, it's all blocks-based. So the only integration with views module would be, for example, if you needed a specific data set and you created a RESTful views endpoint that you could still access from the client. All right, got it. And one more question. So if there are any way, like for the end user, if he has no JavaScript enable to still see the page? He would still see the entire page as rendered by Drupal, yes. You would just lose the rich user experience pieces that were JavaScript components, right? All right, and is there an option to kind of provide a foldback, like if the JavaScript is not available, then display just static HTML? That's a great question, yeah. Actually, because of the way each framework definition allows you to extend what's rendered server side by Drupal, like in the Angular case, we just have a unique element. All that's rendered on the Drupal side is an element with an instance ID that then Angular injects its templates into, but you could render whatever you wanted to server side, so you could have fallback behavior built in as well. All right, thank you. I had a question about, like, JavaScript dependencies, and I know a lot of these components oftentimes will have, you know, it won't just be just standard Angular, standard React, a majority of the components are gonna have these sub modules that are not gonna be defined in Drupal, definitely not. There are a lot of times they're gonna be like NPN modules or Webpack or something, and I would say these JavaScript developers, a lot of the reason that they wanna use their own environments is because of their package managers and the way that the dependencies get injected, and I'm wondering, I saw the YAML files, I've seen a little bit of Drupal 8 stuff, wondering how the plan, so say I have a component, I write a component, I don't know anything about Drupal, and I have these sub-angular modules that need to be used inside of that component. What would be the workflow for me to get those, those other libraries into my particular component without having to think too much about turning into a Drupal module or something? Yeah, no, that's a really great question, and it's actually one of the hard problems we're still banging our head against, because you can easily allow a JavaScript developer to run NPM install and pull whatever dependencies down that they need, but then you get into versioning conflict issues potentially where you have different components on the same page that need different versions of different dependencies, things like that, and then we really wanna preserve the encapsulation of these components so that each one lives in its own subdirectory, but if each of those component subdirectories has its own node modules folder with different things in it, how do those cascade up so that Drupal's aware of all of them as well? We haven't solved all those problems, so if you have ideas, I would love to hear them, but these are the kinds of things that we're still trying to figure out. And then just one last thing that I thought is like, if you were, you know, I know you've react in Angular. I know in Drupal, a lot of times front end performance just goes down, just include whatever block in the page without realizing the hit. I could imagine, like if you include an Angular component, it's gonna include the whole entire Angular library, if you include a react component in the same page, you know, you might have that, so I guess we all have to be wary about including it. As I mentioned, so we're trying to put some guardrails in place. As I mentioned in the Drupal 7 weather version of this, you select a presentation on a per panels variant basis, which is a guardrail we enforced on purpose because we didn't want people trying to put Angular 1 and Angular 2 pieces on the same page. We haven't imposed those guardrails on a couple blocks yet, but something like that needs to happen as well for sure. Thank you. Thanks. All righty, thank you so much everybody. We've run out of time, but feel free to come up and talk to us. Thank you. Thank you.