 So how many people went to the first Horizons talk? Okay, wow, so actually smaller than I thought. So this is the first in a series today of talks about, oh, actually, okay, let's back up. My name's David, I'm with Jason in the back, all your track chairs for this new Horizons track. This was sort of a cross between an experiment and a labor of love for us here. This is a very new thing, bringing in speakers from outside the Drupal universe and or speaking about things that weren't distinctly Drupal-centric to bring new ideas to the table. And as you can see with the audience here, it's definitely resonating with some people. This is the first talk of a series today exploring integrations with various front end frameworks. Following Steven's talk today, there'll also be a talk with Ed Faulkner from the Ember Project. And there'll also talks on Elm. And tomorrow there'll be a talk about an integration with React from Dick Olson. So lots of stuff to talk about by no means. Is this an all JavaScript track? There are other things within Horizons, so please don't expect, we couldn't fit all the frameworks in there, we'd probably kick us out. And then we'd have to rename this conference JSConf Junior or something. So I'm just gonna introduce Steven here. I wanted to say Stefan, by the way, Go Warriors. Steven is from the Developer Advocacy Team at, oh, actually he's a Developer Advocate with the Ember team. Oh my God, the Angular team at Google. He just does stuff, and he's gonna talk about Angular. How about that? I'll stop talking. Thank you, everybody. Well, thank you guys so much for having me. Can you hear me? This mic situation's a little bit weird. You hear me okay? Perfect. All right, so as he said, I'm Steven Fluen. I work for Google out in Mountain View, but I'm on the Angular core team, and I joined recently. So I get to have a lot of fun and hang out with cool people like Igor and Mishko if anybody knows them. We're gonna see if the clicker's gonna work. That's gonna be the first failure. All right, so this presentation is really gonna have about four sections. So the first one, a lot of you are probably new to Angular, so I'm gonna do a little bit of background kind of on what Angular is, where it comes from, and where we are today. Then I'm gonna go into kind of three different case studies of community works that are involving Angular and Drupal and trying to bring them together in the best ways possible. So to kind of get started, how many people here are JavaScript developers? Okay, that's more than half of you, which is fantastic. And then of those JavaScript developers, how many of you have built something with Angular? Woo, yes, give yourself a round of applause. All right, and then of those people who've built things with Angular, how many people have built things with Angular too? All right, a much smaller group, but still significant, so that's kind of exciting. And then we saw about half of you had attended their earlier presentation. So I'll try and put this presentation in context. I'm gonna specifically look at the Angular parts of some of the things that we were talking about earlier, and then I'm gonna go a little bit deeper into how to do some of the things that they were showing off. So I'll start off for those of you that aren't familiar with Angular, or haven't built anything with Angular, and talk a little bit about what Angular is. So we just launched a new website last week, and it really puts it in a really fantastic way how to start thinking about Angular. Angular aims to simplify both the development and the testing of web applications by providing a framework for client-side model view controller and model view view model architectures, along with components commonly used in rich internet applications. And so that I think actually comes from the Wikipedia page, and one of the things you're gonna see is that the Angular community is really at a turning point, it's progressing. So Angular came out about five years ago, I think, and for the past few years, we've actually been working on the second version of Angular, which really focuses on fixing a lot of the things that we identified in the first version of Angular as allowing developers to kind of shoot themselves in the foot, so to say. So Angular is a web application framework. It really aims to simplify kind of both the development and the testing of internet applications. So one of the core fundamentals that we're gonna talk about and kind of think about throughout this whole presentation is when you're building something, how do you make it testable? How do you make sure that as you're building something that's gonna scale and function across teams and you're gonna have multiple developers touching it? How do you test that? How do you build these things in isolation? Because if you contrast that to some of the ways that we've written JavaScript over the past few years without a framework, right, where you've got your fantastic Drupal backend and then you're starting to apply kind of spot improvements to the experience with JavaScript, those can kind of fall apart when you get to a certain scale. How many people have seen weather.com? Almost everyone here. So I think weather.com as they said in the earlier presentation is actually a fantastic example of a site that is using both Angular and Drupal. And so what they're doing here is they're using Drupal for all the workflows, all the management of content. And so it really puts the structure in which they as an organization relate to their website. But then what they're doing is they want a better developer experience for building these kind of rich moments within the application. And so they're using Angular to achieve that. And some of that is with Matt's help here. Angular really lets developers maintain large complex applications. And so what do I mean by large complex applications? So I was referring earlier to this concept that you build a script, right? So historically you might have done that with jQuery and then you build a modification of that script and now suddenly you've got about 800 lines of completely unmaintainable JavaScript. Does that happen to anyone? Okay, a few of you. So the idea behind Angular is that we're actually gonna give you a framework and we're gonna lay the groundwork for you to actually architect your application in a little bit more of a solid way that lets you scale and that lets you develop more effectively. So a lot of people here had used Angular 1, but as you guys may know, things are changing. So I'm gonna give a brief status update kind of where we are as of May of 2016. So we had, about a year ago, we had 1.1 million Angular developers according to our doc site, which is really exciting. I mean, that's a huge amount of growth since the creation of Angular. But then kind of flash forward to May of 2016, we're at 1.3 million users of Angular 1. So Angular 1 is still a fantastically growing platform. But even though Angular 1 up until last week was not, it was still in beta stage, we already have more than 360,000 developers building with Angular 2. So that's a very exciting kind of trend that we're expecting to see. And I think really echoes very well the growth of Drupal 7.8 from the keynote. And then as of last week, we announced that we'd finally hit RC, so release candidate status. So we've been in alphas and betas for a few years now. And so the anyone that had done anything with Angular is quite excited about the release candidate status. And what that means is that we've kind of figured out the architecture, we figured out all of the fundamentals of how the pieces are gonna go together and how you can build applications. And now we're just polishing the tooling and some of the kind of final components that make Angular great. So in this shift from Angular 1 to Angular 2, there's really this idea of shifting from a framework into more of a platform. So if anyone had built with an Angular 1 application, it's really easy to get started, right? You throw ng-app up in your HTML tag, and then you start kind of throwing JavaScript controllers onto the page. It doesn't really matter where you put them. We have kind of a style guide, and there's really good standards on how to build a great Angular 1 application. But there's not really a lot of enforcement of any of those things, which can be very powerful. It can be very easy to get started, but it kind of lacks the ability to build one of these kind of true applications in terms of the way that's maintainable and testable that is what we're really trying to support. And so as you look at Angular 2, it's not just the Angular framework. We're really looking at doing a number of different things that makes the whole application development process easier. I've got a few of these up here on the slides. Everything from, we've got a command line interface for building applications. There's browser-based tools like Augury for inspecting state, things like that. And then we've got kind of this whole suite of components and modules, such as material designs that you can apply some of the material design principles and use kind of off-the-shelf input elements that look a little bit better than the standard HTML ones, as well as something called Angular Universal, which I'll talk a little bit about later. Angular Universal is this idea that because we've now rebuilt the platform from Angular 1 to Angular 2, we can actually do a lot of really interesting things. And one of those things that you're gonna hear a lot about over the next few months is the ability to run JavaScript code on the server side and actually pre-render pages in the same way that you render them on the client but render them on the server so that on first load, you don't actually have to wait for any of that rendering. So this sounds a little bit weird in the context of a Drupal conference where Drupals kind of historically handled a lot of that, but there's some very nice ways that it can play together. One of the things that we did just prior to the release candidate status of Angular 2 is we actually broke Angular into a bunch of different kind of core modules. So you've got core, you've got common, you've got compiler, you've got browser. And so reflecting on kind of Angular 2 or Angular Universal, we're really trying to allow developers to optimize for different things. And so because we've got this modular structure, you can actually build an application that is optimized for setup. So those that are sensitive to the amount of setup time it takes to build an application, whether that's browser-based application or something running on the server side, either with Node or with some of the other compilation tools, or whether you're payload sensitive. And often what we see is that developers are actually at kind of different stages throughout the process. They have different sensitivities, right? So when you first wanna get started, when you wanna build your first Angular component and use it within Drupal, you're actually gonna be much more setup sensitive, right? You don't wanna worry about compilation. You don't really care how big your binary files are or your compiled JavaScript files are. You really just want it to work and see your code on the screen. But then we also have the ability to do payload sensitive builds. So if you care about the size and the amount of JavaScript that you're actually sending down to a user for performance reasons, there's a ton of optimization we can do around that. Even to the point of you can pre-render or pre-compile all of your templates and then just ship the parts of Angular that you actually need. So in some cases you can get down to less than 50 kilobytes for the framework and then you just need your app on top of that. One of the things that we kind of have to talk about as part of Angular 2 is this shift that we're making in terms of the kind of preferred way of writing Angular 2. So we still support JavaScript as well as Dart, but a lot of the code examples and a lot of the code that we're gonna look at today is using TypeScript. How many people here have written TypeScript or seen TypeScript before? Okay. How do you guys feel about it? Do you guys like it? Is it good? I'm seeing some thumbs up. So TypeScript, for those of you that don't know about it, it's really just an extension to JavaScript. So if you look at what we have today, the lowest common denominator across all of the browsers is we call it ES5 or ECMAScript version five. So that's the set of JavaScript functions that we all kind of have been used to building with. But over the past year or two, the standards bodies have actually picked up a ton of speed in terms of saying, hey, we can build a better language of JavaScript. Because if you've ever built a new function, for example, you can lose things like this. What does this refer to? And that gets very confusing and you get very lost when you're building any sort of application at scale. And so they're starting to fix these things in ES 2015, ES 2016. These are the sets of standards that have come out. But what TypeScript is, is they supply a compiler on top of those things that actually gets you all the way back to JavaScript. So the idea is you can write an entire application or platform using TypeScript, which gives you all of the latest features of ES 2015, ES 2016, as well as some of the draft stuff from ES 2017. But then you also get Types. And so for anyone that has come from more of a .NET Java world, typing can be very, very powerful. Because what it allows you to do is it allows you to do static analysis of your code as you write it, so that instead of waiting for runtime to see if something you're getting back from a method call is the right thing, and then ending up in kind of an odd error situation, especially if you're running code in production, you can actually discover a lot of those types of errors at right time, right? So that before you even ship that bug, you're able to find that and resolve that. The other thing that we can do because of TypeScript is I talked a lot about that Angular 2 universal mentality and the ability to run and kind of prune these things on the server. A lot of that uses Types, right? Because if we know what types of data your application is using, we can make sure that we only load the right appropriate modules. So I'm gonna jump into those three kind of community contributions that I've been a little bit involved in. And so the first one is gonna be loading Angular within Drupal. So this is one step towards decline. So earlier today we talked about this idea that historically all of the rendering happens by the Drupal server, by the templating engine, and then gets shipped down to the user as a browser page. And then anytime you wanna perform action on that page, you're clicking on a button or taking an action, that's another request back to the server, a full round trip, you need to reload all the elements and caching can help that, but there's still a round trip necessary there. Whereas when you start integrating Angular, you're actually able to do a lot of those things client-side. I will warn you that this method is not the ideal method. I just wanted to kind of show you one way of thinking about this, and this is working with the latest version of Angular as well. So let's jump in and see if I can get this demo going. And I'm gonna go into this approach a little bit, but I do wanna say that if you are not interested in helping with the framework or understanding the underlying framework, you can actually just take a lot of this boilerplate stuff and not have to deal with it. So from the user perspective, what we're gonna see here is I'm on a Drupal site, and what we've done is we've created a module called JS Exploration, and what that module does is it loads the Angular, it declares all of the Angular libraries as dependencies so that they get loaded by Drupal when you load the page, really loading any page. And then what it's doing is it's replacing the comment rendering box with an Angular one. And so we're gonna see, these are comments via Angular two, you can see all those comments. And so what's cool about this is you can actually run anything client-side. So theoretically I could hit new comment, get some text fields, edit them, submit that all without a page refresh. And so I know that that's a very dumb small example, but I wanna show you a little bit of all what's going on behind the scenes. All right, so there's really four things that we're doing here. First, we're loading the libraries onto the page. Second, we're bootstrapping the application. So this is a standard part of any sort of Angular app. And then Angular two's rendering all of the comments via components. And then we're gonna asynchronously load those comments. So first thing, loading libraries onto the page. We knew the internet would go down. I think we all knew that, right? Let's see if this loads, otherwise I'm gonna tether to my phone. You said this would happen. Hey, there we go. All right, I'll try and minimize the switching back and forth between the presentation. So what we're doing here is this is just a standard Drupal YAML file. So this is the module declaration. And in the module declaration, I'm saying I depend on all the libraries in this file. And then we're gonna flip forward to that file. And what I'm doing here is I'm loading that latest RC. So if you remember talking about setup sensitive versus payload sensitive, this is the setup sensitive one. So I'm gonna be loading all of these polyfills. So a polyfill for those that have not really come from the JavaScript world, polyfill adds features into the browser so that you can use newer modern JavaScript and TypeScript capabilities without waiting for the browser to actually support it. And so we're loading these modules. And then we're defining both a config and an import. Then what we do is we, within that configuration file and within that import file, we're gonna bootstrap our application with system.js. And so in the Angular world, what that actually means is instead of loading every requirement, every dependency that your application has as a script tag, as a lot of us have been used to doing, it's actually gonna load those via XHRs. And so the benefit of that is theoretically it's only gonna load the things that you need when you need them, right? So if your application never uses a whole module of your app, it's not gonna actually load that into the memory of the browser. So I'm defining here my application. I'm defining that I want to transpile it. So if we talked earlier about TypeScript, this, these kind of few lines of code will actually automatically handle turning the TypeScript into JavaScript that you can ship and run on the client side. And then we've got an import.js file, which is actually going to now run that bootstrapping. Second, what we're doing is we're using Angular to render the comment components here. So this is a very, very standard Angular component and I'll actually walk you through a very simple one a little bit later today. So it's got a selector and what that selector does is it takes a standard HTML tag and then says, hey, whenever you see this, we're actually gonna be rendering it as a functional component. It's taking in providers because we wanna be able to access the web. So we're gonna use both a comment service that wraps the way of reading and writing comments. And then we're also gonna look at HTTP providers, which allows us to access the web by XHR. And then we're gonna have sub-components by these directives that allows you to actually have a nested component. And so I talked a little bit earlier about the testability and maintainability of large applications built with Angular 2. And so this is really core of the concept that each of the times that you're gonna nest an application, you really wanna be building new components. And so those components really well correspond with kind of Angular with Drupal components that Dries was talking about earlier today. And then using that service that we mentioned in the previous slide, we're actually gonna now go out and get that. So it's a very simple set of code when this component loads. So it's called ngOnInit, which is just the callback for once it's loaded. We're gonna use that comment service. We're gonna run get comments and we're gonna pass in the path from Drupal. So depending on the node that you're actually in within Drupal, we're gonna load the right set of comments. So I wanna give a huge thanks to these people. So if you look at the GitHub repo, I've made a bunch of changes to bring this up to the latest RC within Angular 2, but this really is kind of a Drupal and an Angular community collaboration. I'm also gonna blame Matt Davis for any of the demos that go bad. So that's kind of a naive way of pulling Angular into an application and starting to build these kind of asynchronous loading components and pieces. A better way that's in progress here is progressively decoupled blocks. So anyone that attended the earlier presentation is already familiar with this strategy. So just a little bit about the theory for those of you that weren't there. A traditional application, as we said, is entirely rendered by Drupal and then shipped to the browser. If you look forward a little bit, there's this idea of fully decoupled where you're really just using Drupal as a backend API, which in some ways gets rid of some of the value, right? So, because Drupal has a lot of logging, it's got a lot of caching optimization, it can automatically concatenate all of your JavaScript files and put them in the header and things like that. And a fully decoupled application loses some of those things. And then you've got the idea of, finally, a progressively decoupled where you're still loading the kind of standard page from Drupal, but then you're swapping out components or you're loading Angular on top of a lot of those components. So I'm gonna do a brief demo here. Let's just try and flip it. All right, so I have another Drupal site here. So just as Matt demoed a little bit earlier, I can actually go into the structure. It's a little bit hard to see. I apologize if I miss. Is that structure? All right, I don't know what's going on there. So I will just skip that part. So I've actually loaded here what we call the tour of heroes. So if you look on the Angular.io website, the first thing that we're gonna ask you to do is part of learning the platform is to do this tour of heroes, where you're actually gonna basically render a list of items and then have a detailed view for all those items. And so we've got all of the... So this is why I don't like page flips. This is why I want more things to be client-side because you can preload them and then not have to worry about the internet as much. All right, we might just go back to the presentation here. All right, so anyone that really wants to see that demo, come and ask me later. Or Matt, his presentation should also have a version of that. And so if we compare the two approaches, one of the things that the progressively decoupled blocks has on the other one is that it only loads the Angular framework if you have a block on the page that's requiring it. So if you compare... If you think about how we were doing it before where we're loading it, kind of no matter what globally, this is much better. And then the other thing that is the benefit of this approach is that all of the components are contextually aware. So the Drupal parameters, variables, fields, all of those things that are accessible via a Drupal object within JavaScript. But then we definitely, kind of from the Angular component testability perspective, we definitely recommend you wrap those things in a service so that they're easier to mock out if you're building any sort of testability in your application. I do want to call out a couple to-dos on the progressively decoupled blocks. So I know Matt and the team are actually running sprints. So if you guys want to contribute, definitely go help out with that. But one of the things that it's missing right now is that all of the rendering of the components is being done client side. Whereas I think there's an opportunity to render some of that server side using Angular Universal so that on first load you get the full content and then the Angular platform will actually automatically kind of replace those with live elements. And so if you want to see any of that working kind of outside of the context of Drupal, check out the Angular Universal website. And then the other thing that's still kind of, I would say in progress, is the ability to build, bundle, and compile the Angular 2. So with the Angular 2 platform, you're actually able to compile templates. You're able to do all those kind of optimizations so that you get a much smaller binary, you get a much smaller framework and a much faster framework. Those things are not actually being loaded in the kind of tech demo that we've got today. So huge thanks to Matt Davis for progressively decoupled blocks. The last kind of tech demo that I want to show today is twig rendering. So if anyone's been building on Drupal 8, you're probably familiar with twig templates. And so whenever you're rendering something via the server side, that's being done via twig. And so you may be thinking, hey, we've got all these templates that we want to keep using as we kind of rebuild parts of our application as we build new components. What do we do about that? And so one of the community contributors has actually built a way that will automatically render Angular components using twig templates. And so we're going to jump over to another demo in a second here if it loads. But this is really kind of three things. So they've got what we call the twig decorator. So in Angular you're able to, and in TypeScript you're able to supply metadata about any sort of object. And so that metadata is specified using decorator syntax. And then you can either have inline templates or you can specify them out to a template URL. And then it also tries to leverage an already existing project called twig.js which is doing the specific rendering and replacements. So we're going to try and do this. Wish me luck here. All right, so this is a plunker that's publicly available. And what we're actually going to see here is that this is a, as I said before, a Angular 2 project that is using a twig template. So this script tag here is just specifying a template. You could put this in a file, you could put this really anywhere. And so what we're doing here is, if I could see, we're using all of the kind of twig conditionals, all of the twig looping, the repeats, the foreaches, the if conditions. And then we're rendering that live here. So if we go into the data model, all right, I'm not able to see that well enough. But if you go into the data model, what you can see is that what we're doing is we're loading all of the templates just via kind of XHR via standard web request. And then we're using that twig.js module or library to render all those in the same way that you use Angular templates. So you can use standard Angular templates or you can use twig now, which is very exciting. All right, and so what I've got here is I've actually got the twig decorator.ts file. And so this is a part of that library that we showed you. And so what this is doing is it's just loading the template and then it's replacing all those arguments and then doing a full rendering. So one of the things that is still kind of open is make the template rendering async. So one of the nice things about Angular is that almost everything is done via async processes and observables, but right now the twig template rendering is synchronous, which means that it's gonna block the rendering of whatever else you're doing. So that's a project by a gentleman named Wasim. He was at DrupalConf last week, which was really exciting. And so the future, as we think about loading some of these things and doing some of these things yourself, I want to do a brief little final demo here. So if you're looking to get started with any of these things, the PDB Git repo is where a lot of the development that Matt is working on is going. Just clone it into your modules folder in any Drupal install, and then really start building components. And so what I want to do is locally, because I have this one offline, I want to show you the complexity of building a new component using a URF in Drupal. So this is basically the folder structure you're gonna get from Git. And then what you're gonna be able to do is if you see this components folder, we're gonna be able to open that. If you'll help me, am I on the components folder? Great. So what this is, is this is as simple as it can get. So this is an Angular module component that is for basically a Hello World application. So we import the requirements. So we're importing what a component is from Angular. And then we're defining a component using that decorator syntax. We're saying, hey, here's the selector that I want to use. So that means here's the HTML tag that I want to replace. And then here's the template. And so what will happen is, this will actually, if you write the appropriate YAML file, which is actually longer than the file itself, this will give you a completely new block within Drupal that has the functionality of that component. And so it's kind of relatively trivial to start extending this. So if you wanted to write a constructor that initializes some state, if you wanted to start pulling in data via web asynchronous web requests, all of that code just kind of goes here. And then you start nesting components as your application gets bigger. And so getting started is intentionally very easy if you don't care about the framework kind of around it. So I definitely recommend that you contribute by importing the PDB module, build more components. Because I think one of the nicest parts about doing this sort of component architecture, which really reflects what the Drupal community has been doing for a long time, is that we can all benefit from one person's work. So if you're building a new commenting module, or if you're building a tour of heroes, or if you're building sort of anything, maybe an alerts notification system for your website that you want to load a lot of data asynchronously and allow kind of visual experiences that interact with that data, I think everyone here could benefit from those components. I would also recommend that follow Angular as we approach GA. So I think some of these examples, some of the things that the Drupal community is doing are gonna need a little bit of updates. And then really take advantage of the template compiler and bundling. So all of those things that, as we move from complexity and developer time sensitivity to payload and user time sensitivity, all of those things are definitely gonna benefit your application. And then I want to kind of end with just a little bit about kind of why Angular, because there's a lot of frameworks out there, right? We're gonna hear from Ember, we're gonna hear from Elm, we're gonna hear from about React. Rich applications can really be built a lot of ways. And a lot of people talk about this idea of kind of React versus Angular, but it's not really a versus game. I think everyone in the JavaScript and everyone in the broader web development community, we're all really trying to make the entire process of developing applications better. And so I think there's something that everyone can learn from everyone else. So for example, we have a library in Angular called NGRX. And so what that allows you to do is it allows you to use reactive programming methodologies to build functional applications. So what that means is you can actually build, for example, a search box that allows type ahead, right? So this is something that in a traditional server side web application is very, very hard, right? Because you can't be pulling in new data on the fly as a user's typing, but Angular and especially NGRX makes very easy because you can say, hey, if they type a character and it's been more than 300 milliseconds since the last character, we're gonna initiate a new search. If the last search hasn't finished, then we're gonna interrupt that and we're gonna render that out. So reactive ideas and principles are very powerful and we definitely want Angular apps to be able to take advantage of a lot of those. The other place that I really think Angular shines is when you think about enterprise. If anyone has to build an application and manage it and maintain it for multiple years at a time, that's part of the reason that companies choose Drupal. Drupal is a large scalable platform that can bend and flex to meet the needs of the business and Angular is in very much the same way, right? You can build a large application. This is not a three-page WordPress site. And then you can also kind of build and launch and run websites with Drupal and then hopefully the idea is that we're gonna be able to do that server side as well at some point. And then there were a few notes that I took earlier from the presentation. So they were saying that the progressively decoupled approach doesn't handle some of these things, so cross-site scripting, input sanitization. Angular handles all of that kind of out of the box and it's actually a little bit funny watching Angular and Drupal fight over that because the current Drupal RESTful web services return kind of raw HTML and Angular kind of automatically tries to sanitize that and says, oh yeah, you're sending me HTML. Let me render that to the screen for you and so it's already escaping everything. So there's a little bit of a fight there. One of the things that as you think about any sort of client-side framework is system notifications. How do I know that as we move from everything running on the server to everything kind of running on the client or more things running on the client, how do I know that things are working well? And so there's companies like OpBeat which allow you to deploy a module that works within Angular and then can actually monitor and capture errors on the client side. So let's say that Firefox for example, they ship a new bug into the browser and now suddenly that's affecting 10% of your users who've updated to this latest version. There are ways that you can hook into both Angular as well as other web frameworks using something like OpBeat and actually get web server-based notifications that hey, our users either the experience is suffering via errors or you can also monitor that performance is suffering. So Angular has this concept of routing so that as you shift from page to page or from state to state within your application we can actually measure the performance of all of those transitions in a way that you can monitor over time and say hey, there was a 30% increase. What happened? They talked about progressive loading. How many people here have heard of progressive web apps? Very few. That's actually the smallest number of hands I've seen today. So progressive web apps are one of the most exciting things about the web today in my opinion. So this is the idea that you build a website or you build a web application and parts of that application can be shipped and live on the user's browser. And so that sounds a little bit scary to start but if we checked each of your browsers there would probably be 20 or 30 apps already doing this today in some form. And so what progressive web apps actually allow you to do is it allows you to specify a manifest which allows the browser to treat your application or your website more like an application. So you can do things with, for example, service workers, a recent JavaScript API that allows you to run a website entirely offline. So imagine if suddenly your Drupal site you could still load it and it could show you some cache data. That caching in that and those service workers also allow you to improve performance because now instead of trying to go to the website to render it for the first time you can actually load those assets locally. So this is kind of the successor to the cache manifest if anyone remembers that. And so progressive web, and then there's a bunch of other features there such as the ability to do push notifications. Push notifications on the web that is one of the coolest things I've ever seen and installing a service worker and having this idea of a modern web application can be very beneficial. And then there was also the comment that there's no accessible markup of user experience benefits. I think the twig compilation is a little bit of a game changer when it comes to Drupal applications to interact well with Angular and client-side applications. So the ability to use the templates and run the modules that you already have in some form entirely client-side, that's awesome. Thank you, and I will take any questions. I think we have a mic right here in the middle. Yeah. So I was wondering if you could talk a little bit more about the Universal JS with, if you're looking at, is that currently focused mostly on node-based server rendering or is there looking much effort towards the PHP VHS side of things? Sure, so currently it's, I'll talk about it kind of in two ways. So on the Angular Universal side, that is node-based server. So the idea is that we're gonna be able to render, using node, the application, using the same compiler that your browser would be doing, client-side, but rendering it on the server first and then shipping it to you and then progressively replacing those components with kind of live components and then playing back any user input. So that's all stuff that works today. On the other side of things, the template compilation, that's actually something that happens at development time. So the idea is you're gonna build this large-scale application and then you're actually gonna be building it in a way that you're gonna bring down the binary size and it's gonna use the types to follow your component tree and trim it and things like that, all at development time. So when you ship, that doesn't matter if you're serving it from PHP or any server. Yeah. Do you wanna go to the mic? Otherwise, I can repeat your question. Sure, sure, NURJS2 is more than 10 times more performant. So, I mean, the big thing that we did between NURJS and NURJS2 is we really refined both the component model and what's called the digest loop. So in NUR1 or NURJS, what we were doing is we were looking at all of your components anytime anything happened and then we were running all of the expressions on every page and saying, did anything change? Did anything change that we need to re-render? And if it changed, then we re-read it to the screen. But due to the kind of cascading nature of one change triggering another, we would actually have to run that loop over and over and over until something stopped changing which is horribly inefficient. And so with NUR2, what we're doing is we're actually, we make a tree of your components because just like the web, it's non-cyclical, right? So we can tell, we start at your root node and we follow all the nodes down throughout your components and we can say, we can run the change detection once and then not loop. And so then we also have different mechanisms for actually changing how that works. So you can change it to push. So that applicator only certain events trigger that change detection. So NUR2 is much, much, much, much, much faster. And that's one of the primary reasons that a lot of developers end up switching to NUR2. Sure, so the question was, is there an NUR1 to NUR2 migration tool? So there's definitely an upgrade path. So for example, what version of NUR1 have you used? Okay, it doesn't matter. So as we shifted from NUR1 to like 13 to 15, which is the latest version of NUR1, what we've done is we've been kind of back porting a lot of the features and the ideas, most importantly. So for example, in NUR1.5, you can build a server or a client-side web application using components, using this whole idea of a component router, component trees, things like that, which then are relatively straightforward to swap out to NUR2. And there's even a tool that we've got called NG Upgrade. And so what that does is it will use the NUR2 bootstrapping so that you can have both NUR2 and NUR1 running within the same application to make it easier for large applications to be ported over more slowly, more gradually over time. Yeah, sure, so I don't think I'm as versed on DrupalGaP to answer that, but for example, PhoneGaP in the form of Ionic, NUR definitely 100% works with that. One of the kind of interesting things about Angular is because we've got this kind of deeper, semantic understanding of the application. There's a platform or a library out there called NativeScript, if you've ever heard of that. So for those of you that have used PhoneGaP or Ionic or any of these platforms, what they're doing is they're actually shipping a web view. So they're shipping a little browser that they put in the application, and then they've got JavaScript libraries that kind of interface between local JavaScript calls and native functions like get a picture from the camera or look in the user's contact database. But what NativeScript does is it uses the HTML and the CSS you write, and it actually translates it into native UI components. So for example, if you write an input box in JavaScript or in HTML, NativeScript will render that on Android as a text edit and on iOS as the appropriate equivalent. And so what that does is you've actually got a native application running that was generated from your HTML, JavaScript, CSS. And so because Angular doesn't actually depend on the browser anymore, it works very well with NativeScript and we can actually convert more of the application than you would just shipping HTML and CSS into native script. If there's no more questions, thank you guys so much for coming.