NDC Oslo 2015 - Aurelia: Next Generation Web Apps
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Eisenberg, Rob
Do you want to see what the future of web development will be like? Are you looking for a simple framework or set of libraries that can help you build complex web or cross-platform apps? If so, you’ll want to attend this session. We’ll introduce you to Aurelia, a new framework with a rich heritage stemming from Caliburn.Micro and DurandalJS. You’ll learn about the fundamental features of the framework, such as dependency injection, templating, databinding, and routing, while we build a simple application. You’ll leave with all the knowledge you need to get started building your own applications with Aurelia.
 Good morning. I hope everyone is enjoying the conference and I welcome you on this third day and I'm thankful that you have chosen this first session this morning to be with me and to hear about Aurelia. So without any further ado, let's kind of jump into the conversation and the demos for Aurelia today. A bit about myself first. If you don't know me, I've been working in the space of front end frameworks and libraries for about ten years now and have built frameworks similar to Aurelia in many ways across a host of different platforms starting with the Windows platform as early as 2005 and also working in Flash, Flex, Silverlight, Unity 3D and the web building frameworks and platforms similar to this across all those different technologies. The ones that are most well known for are Calibre Micro which has been around for about five years now and is still in steady great use in the XAML world by both big and small companies all over the world and also Durandal.js which is targeting the web platform which again is still quite healthy, mature and being used by both big and small companies all over the world. Just to give you an example, the types of companies that are using these frameworks still today includes customers like Microsoft, Walmart, Twitter, GitHub and more. So a lot of names you probably recognize have built software on these open source products that I've produced over the last ten years and particularly these within the last five years building really cool exciting things. And early last year Google took an interest in what I was building and planning to do with the next generation version of Durandal and so they contacted me and they said, hey, let's work together on Angular 2.0 and I said, well, that sounds interesting. We began working together and I worked with them for about ten months after which I get the distinguished reputation of the guy who quit the Angular team. So you may know me through that as well. So suffice it to say after a number of months of development, a series of what I would consider serious disagreements in philosophy, design, features, et cetera around the development of front end frameworks kind of came to a head and mounted to, you know, just a significant amount where it was no longer possible to continue really working on that project with them. So I left to return to my existing community which was still very alive and well with Durandal.js and still is to this day. And to pick up where I left off building a next generation framework based off of those previous, all those previous years of developing front end technologies. And so that brings us to Aurelia which we just announced in February of this year. And so I'm the creator of that but really playing a big, more of a project lead role right now as we have a team of 15 developers working daily on Aurelia and the surrounding ecosystem. So that's what the bulk of this talk will be about of course, Aurelia. And here's our basic short agenda for the rest of our time together. First I want to talk about the what and the why of Aurelia. You know, what specifically is it? What is the design philosophy? Those sorts of things. And why are we building it? You know, why another JavaScript framework, right? You know, you've seen how many days since the last JavaScript framework. Have you seen that site? So, you know, there's so many frameworks. Why another one? And we think that there are some interesting distinctives with what we're doing. We think that things will be very interesting to you and important to you and what you want to do with your businesses. And so I want to share a little bit about the why as well. Then we're going to spend the bulk of the middle section of the talk building a simple application showing you features. Hopefully you get a sense of how things are put together, what the methodology is for building apps. And then we'll conclude the talk with the status of the project and a look at what we're working on right now. What are our next steps and what are kind of our road map is for the next few months. So first, what and why are we building Aurelia? Well, what is it? Okay, so first it's plain and simple. It's ECMAScript 6 and 7. So if you had the chance on two days ago to hear my ECMAScript 6 talk, then you know that it's like we're virtually getting a brand new language in the browser, right? So at its core, Aurelia is just JavaScript. But it is written targeting literally two versions into the future almost of JavaScript. ES6 was actually finally approved two days ago. So I guess it's just one version in the future now. But we're targeting next generation JavaScript and Aurelia is just JavaScript. But interestingly, it's not one gigantic JavaScript library. It's actually a collection of collaborating libraries. So with the emergence of modules in ECMAScript 6, we have a standard way to kind of break apart our framework into collaborating modules each with a particular feature or a particular responsibility that they're concerned with. So Aurelia is broken into a number of feature modules, many of which can actually be used independently of the larger framework. So for example, we have a dependency injection library, which you're free to take and use on the server in a Node.js app. It has no connection to client-side apps or to the larger Aurelia framework per se, but it's an enabler piece for us. And so the framework itself is built as this set of collaborating libraries, many of which you can use in different ways outside of Aurelia. That's great for us for a lot of reasons, of course. We can develop in parallel. We can independently version and release them and do a lot of nice things that help us to be very agile and also to assist you in getting you the features and the bug fixes and those sorts of things that you need. So it's just JavaScript, just JavaScript. The purpose of it, though, really in the grand scheme of things, when you bring all these collaborating modules together, it's really targeted about building an next-generation JavaScript client apps. This means targeting the browser with rich interactive experiences. This means targeting the desktop with technologies like NWJS or Electron. And this means targeting devices, mobile devices, with things like PhoneGap, Cordova PhoneGap. So anywhere that Web technology is, that's where you use Aurelia. As a rich client technology to enable rich interactive experiences for your customers or your audience. So building JavaScript clients. What is the philosophy of the framework? How do we think about the framework? How do we want you to think about the framework? Well, the first thing that's very important for you to realize is that it's completely open-source. It's MIT licensed and that's not going to change. Now, if you know much about open-source licenses, you know that MIT is a very permissive license. So this is a framework that you can take, you can use, and you can feel very confident using, feel very comfortable in terms of the licensing model around that. And so first and foremost, it's open-source. Second, we're focusing, you know, in our philosophy on clean code. This means we want, of course, our code to be clean, but it's also an enabler for you to write clean code. Standards-based code. I've talked about ES6 and ES7. What we really want is you to write apps with these latest standards, and we want you, when you look at your app, when you look at your code, we want you to, for the most part, see your code, not see our framework. We want to encourage you and help you in writing very clean, modern JavaScript code. So the framework is very much about modern standards, clean code, and staying out of your way. And we do a lot of this kind of staying out of the way by leveraging simple conventions. You know, when I look across the last ten years of framework development that I've been doing and the consulting I've done with a bunch of companies building all kinds of apps, certain sorts of patterns tend to emerge for the ways that we build things. And so it makes sense to take those patterns and teach the framework what those patterns are so that we as developers don't have to go configuring the framework for every single little piece that we build when we're doing the same thing over and over again. So the framework should understand those kind of things, and it should do that work for you so you don't have to do that work, so you don't have to write that code, so you don't have to maintain that code. So when you bring new people on the project, you don't have to teach them about that kind of code. All right, so the result, of course, is clean code, but with simple conventions, it means you write less code. It's easier to read. It's easier to learn. It's easier to understand. It's easier to maintain. And another big part of this, of course, is that is testable, meaning the framework itself is testable, but it's also very concerned with making it possible for you to test your own apps. This means unit testing your apps as well as end-to-end testing of your apps. So these are all kind of core parts of the philosophy of the framework. Things that we think about constantly, things that we talk to ourselves about, so to speak, when we're thinking about how we're implementing things and what features we're implementing or how we're building the framework overall. And finally, I want to talk about, you know, the status of this. When we say what, what's really kind of neat is even though it's barely been, you know, known to the public, so to speak, for more than four months, there's already an extremely rapid adoption happening in a large, active community. We have close to 4,000 stars on GitHub, so that's an average of almost 1,000 stars a month for an alpha framework, like I said, barely over four months old. So people are getting very excited. People are getting involved. There's about 1,500 people in our Gitter chat room right now, all over the world talking about the framework, helping each other, working with it. We've got a 15-person developer team on this. They're not the only ones contributing. Of course, there are contributions coming in from regular community members all over the world doing really cool stuff already. People adopting it, building apps, again, both big and small companies everywhere. So really, really cool stuff already happening in terms of the community and the adoption. And hopefully, when I get into the demos, too, you're going to see why. Hopefully, that will resonate with you and it will make sense why people are getting excited about this. And as a subtext to that, I also want to say that Aurelia is commercially backed. So it's open source, but commercially backed by Durandal Inc. and some strategic partners we have. And this is really an important part of a framework when we're looking at this next generation and you're building apps and you're building businesses on a framework. So when you use something like Aurelia, it's not just like some small little library you toss in and you can pull back out and easily replace. If you're going to choose a framework that's going to help you to build your entire app, that's going to be the base of your application architecture, you want to choose something very carefully. So one of the things that we've done is we've created a new company. We've been creating strategic partnerships with other companies in order to make sure that we can take this framework and fully commercially support it and build an entire ecosystem around it that rivals the best ecosystems in the native app development world. And so I don't have a bunch of announcements to make about that today, but you'll be very interested to see some things that we're going to be doing in the next few months. But suffice it to say that there is a company behind this, it is commercially backed, and the framework is tied to the success of the company. So our community is very important to us, but it's not just lip service. We have to meet your needs as a community or else our business fails. And we have intentionally made that connection between the business and the open source project because we think that that is the best result in terms of tying our success to your success. So this is very important. There's a number of other frameworks out there, some of them made by very, very large companies. I won't name any names, but there's absolutely no connection to the business from the open source framework. So this is something very strategic that we're doing. We think it's really important with something at this level. Okay, so why are we building it? And this does kind of crossover with a little bit of what I just said at the what. There's obviously a connection there. But first point there is, you know, browser technology is advancing and changing amazing in amazing ways, right? Again, I talked a couple of days ago about ECMAScript 6. That's now approved. ECMAScript 7 has been parallel developed already. You know that the, you know, you may hear me saying ES6, ES7. The correct names are ES2015, ES2016, just so you know. I can never say that because I've been saying ES6 for too long. So it's an old habit. But fundamentally, the language of the browser is evolving in rather extreme ways. You know, again, if you haven't seen ES6, it's almost like there's a new language in the browser. So wouldn't it be great if there was a modern JavaScript framework for building apps that was built on and assumed this modern JavaScript language and used all the constructs of this modern JavaScript language to represent the framework from the beginning? Wouldn't that be nice? And what else has happened? Well, in the last few years, the DOM has significantly advanced in terms of its performance, in terms of its consistency across browsers, in terms of new APIs that allow you to say not use jQuery. And wouldn't it be great if a framework was built on top of the modern DOM that did not use any DOM abstractions but used the raw power of the modern DOM and exposed that to you? And wouldn't it be great if a framework was built with web components in mind? Another big change has come into the browser, the ability to exchange reusable components for the web. Wouldn't it be great if the framework was designed with that and utilized that technology from the beginning, and that was part of the core? And these are some reasons why another or a new JavaScript framework, because really there isn't anything out there that does this today. And we think that these are significant improvements and enhancements to the web platform, and so much so that the way that you build a framework and the way that you build apps is fundamentally different, and it deserves a framework that takes these things into consideration as of first importance. We also wanted something with no external dependencies, so except for polyfills. So really the polyfills are things that patch up across browsers, these next generation features which aren't consistently implemented everywhere yet. So the idea with this is that we want to be able to support our framework, we want it to be reliable, and we don't have to wait on some other company or open source project to fix a bug that is affecting you when it's not in our code. So it's better for us if we have no external dependencies. The interesting thing about the polyfills is, is when you design a framework built only on polyfills, is that over time the framework will actually get both smaller and faster, because the polyfills will fall away and be replaced by native browser implementations. So we actually designed this framework to get smaller in the future and to get faster in the future just because of the way that browser technologies are advancing. So this is an important reason why in terms of building a framework in this style. We wanted a simple and powerful programming model. If you've looked at any other JavaScript frameworks out there, there's tremendous learning curve associated with just about any framework that you look at. And frankly, to me, I just wasn't happy with that. It was just, things were just too complicated. I really wanted a framework where we could just, for the most part, write plain ECMAScript 6 and just have it work, and have a data binding syntax that was simple, easy to pick up and remember. So we want a simple, powerful programming model. We don't want something simplistic, but we want something simple, easy to use, but that doesn't sacrifice power and flexibility. And so, really, again, looking across the landscape, there wasn't anything that I felt met that criteria. We wanted modern and future compatible two-way data binding. And you may have heard a lot about two-way data binding recently with React kind of saying, oh, it's an anti-pattern, blah, blah, blah, blah, blah. But this has a lot to do with the way that two-way data binding has been implemented in particular other frameworks, which causes problems. But as I've mentioned, the browser is changing. ECMAScript 7 is bringing native observability to objects. There are modern APIs that let us polyfill that in various ways. So wouldn't it be nice if we had a framework that assumed native observability of JavaScript objects and polyfilled that for browsers all the way back to Internet Explorer 9? And it built its data binding framework on top of that in order to create a high-performance, modern, two-way data binding framework. And so, again, it literally does not exist in any other framework. And so that's why, another reason why, Aurelia. And of course, as I mentioned earlier, commercial support may not be really interesting to all of you, may not be needed or wanted by all of you, but there are a bunch of companies out there that when they've looked across the JavaScript landscape, they said, you know, we're building apps on this, we're building our business on this, we're spending millions of dollars, but I can't get commercial support for anything. And so we want to provide that, that's part of our business plan, of course, we need to have a framework that we can reliably provide that for. And so that's also another reason why, from a business perspective. And of course, we want a pathway forward. You know, there's a lot of people in my existing community using Durandal. There's already also a lot of people using Calibre Micro on the Windows side that are looking to move to the web. So we want to provide a pathway forward to them that makes sense, that's easy to learn and easy to transition to. There's a lot of people also using Angular that are looking for kind of the next generation framework. We wanted to provide something for them that made a lot of sense, but that gave them a very smooth transition and that was simple and easy for them to understand. And so that's another reason why, a pathway forward for people invested in existing frameworks, but a pathway that's an easy to understand transition, that makes a lot of sense to them. Okay, enough talking about that. Let's build an app. So how do we do that? Well, we're in an early stage right now, so the hardest part of building an app is the setup. I'm going to skip that whole part today, right? But this is how you do it. Basically what you do is you go to GitHub and you download our Skeleton Navigation repo. So this is basically a starter project. And it's actually a pretty cool starter project because we've set up a whole bunch of things that you need in the real world. Like, we've already set you up for unit testing, for end-to-end testing, for building your ES6 code, for doing code coverage reports, for browser sync. There's a Node server you can use to serve up your assets. A whole bunch of stuff is already pre-configured, so you just download it and you get all that for free. It's designed to actually be a production quality starter kit. So you can go download that, you unzip it, and then you're going to need to install the build dependencies. The world of modern JavaScript really is connected with Node.js. All the tooling is built on Node.js. So I want to be clear about this. Aurelia itself has zero dependencies on Node.js. No dependencies on Node.js whatsoever. But the build tooling for modern JavaScript is pretty much all based on Node.js. So you need to install Node.js. If you haven't done that, it's not something to be really afraid of. You just download it, install it, it's no big deal. And then you're going to install a few things through Node, using Node package manager, MPM. First, you're going to install Gulp. And this is the actual build task runner that our starter kit uses. Again, Aurelia, Node dependencies on Gulp, you can set things up any way you want. But this starter kit uses it, so you'll need to install that. Then you run MPM install inside of that directory and it's going to bring down all the modules that Gulp relies on to do the building. So everything for building your ES6, everything for setting up your unit tests, all that stuff is going to get installed with that command. Then you're going to install JSPM. And JSPM stands for JavaScript package manager. It is a package manager oriented towards client side package management. Built with the notion of ECMAScript 6 modules being the primary mechanism for distributing JavaScript code. So this is a package manager that understands the ES6 module system and that understands the nuances of client side development. It's not a repository. It can actually install packages from MPM or from GitHub directly. But it is a package manager that will manage those packages. It understands multiple module formats, so you can bring in an AMD library, a Kamajaya library, an ES6 library, a global JavaScript library. And it will understand that and it will make them all work seamlessly together. And it will make them all integrate into the ES6 module system. So this is a fantastic way to handle your dependency management for your client side apps. And it's fully integrated with the ECMAScript 6 loader. So that's, again, not a requirement of Aurelia, but we think it's a really great product that really is going to enable you and empower you in your client side development. So that's kind of our default option there. So you install JSPM. Once JSPM is installed, you then ask it to install the client side packages. And that's going to actually download Aurelia and install it. For the starter kit, it's actually going to also download Bootstrap and Font Awesome. Those are, again, not requirements of Aurelia, but the starter kit uses them so it's not hideously ugly, right? So that's going to install all the client side packages used by your app. So once you've got this set up, then you say, go up Watch. And this is going to spin up a little server to serve the static assets. And then you can begin editing code and viewing it in the browser. And we set up browser sync. So every time you save a file, your browser will automatically refresh across all browsers and all devices connected. Everything will be synced. So that's all set up for you, too, for cross-browser, cross-device development. Now, that's a little bit complex. I want to tell you that we're about to release our own command line tooling. Literally, it'll either be today or early next week. And our command line tooling, one of its main purposes is to simplify getting started with Aurelia. So be on the lookout for that. You can read up on our blog, blog.durandal.io, about that. We have blog content there every single week about releases, about features, and all kinds of things like that. So realize that this is because we're almost in a beta, but not quite in a beta. So getting started is a bit more complicated than, of course, it will be when we hit beta and when we hit the 1.0 release. But if you want to get started, this is good, and this will give you really a production quality setup. And all you do is delete the code out of there and start writing your own app. So this is where we're going to start our demo with today. I've already downloaded this, unzipped it, installed everything, and got it all set up. So let me just jump out of this and let's start building an app. So the place I want to start today is in the index HTML file. So this is the place where you would probably look anytime you looked at a new app anyway. So we're going to start there. Notice in the head of the document, there's really nothing too bizarre. I've got Bootstrap in there. I've got Font Awesome in there, and I've got some custom styles. None of that's really important. That's all standard stuff. What we want to look at is what's in the body of the document. And this is important because almost every Aurelia app is going to have an index HTML that looks basically the same. There's almost nothing in there. Its purpose is to Bootstrap or start up the framework. Okay? So first, we're going to include SystemJS. SystemJS is the module loader, the ECMAScript 6 standards-based module loader that is distributed with JSPM. So you get that package manager and module loader integration. So we're going to include the module loader because even though it's a standard yet, it's not implemented on all the browsers. So this is one of those polyfills, basically. So we're going to include SystemJS to get the ES6 module loader. Then we're going to include ConfigJS. This is actually a file that's generated by JSPM. This is how it figures out how to make all the different module systems work together. When you install a package, it looks at the JavaScript code and specs it, figures out what it is and how it works, and puts a little configuration in there automatically for you. So you never have to touch that. Whatever you ever work with, require JS, for example. You know you have to write the map, the path, and the shim config for every library just about to get it to work right. JSPM understands those things and generates it automatically for you, so you don't have to write that kind of thing. That's what's in ConfigJS. So your module loader and the configuration for the loader just include those scripts. And then what you want to do is you actually want to use the ES6 standards module loader to load up Aurelia. And so that's what system is. When you say system import, this is a standards-based API for dynamically importing a module in ECMAScript 6. So we're importing the Aurelia bootstrapper, which is really Aurelia's module that starts up the framework. It kick starts everything, configures everything, and gets your app running. So how does it know what to do? Well, simple conventions. It's going to look at your HTML document. It's going to find anywhere that you've put an Aurelia app attribute. And it's going to assume that you want that HTML element to become the place in the DOM where your app is rendered. And by convention, it's going to look for your app to be implemented in an AppJS JavaScript file, and its view to be rendered in an AppHTML HTML file. Now, everything we build in Aurelia pretty much has two parts. The JavaScript part, which will have your behavior, usually exporting an ES6 class, and the view part, which has a standards-based HTML template that contains the view that is the rendering of that JavaScript file. So we isolate your behavior and your state from your rendering and your view. Now that you know that, you know how, you know, 50% of building in Aurelia app. That's the same pattern over and over again we're going to use. You're going to see it. So to start building our app, we're going to create our AppJS and our AppHTML file. So I'm going to create AppJS. And the code in there is going to be a simple ECMAScript 6 class. Notice you do not see the Aurelia framework anywhere. This is just a simple class. Actually, it's an ES7 class. I'm using some ECMAScript 7 features here. It's a class. It's got three properties, three simple properties, heading, first name, last name. It has a computed property, a full name that concatenates the first name and last name. And then it has a simple method on it called submit. That just shows an alert. So if you know ECMAScript 6 or 7, there's nothing special here. It is a plain class. Pure ES6 and 7. But Aurelia, it renders JavaScript objects. The simple pattern allows us to now create an AppHTML. And we're going to put some HTML in there. First thing to notice is that there's a template tag. Again, this is a standards-based template tag from the Web Component spec. A cross-browser standards-based way of defining templates. And inside of that, we're going to put some HTML. And that HTML is going to be bound to the instance of our class. So that any property or any method in our class can be connected with the HTML. And Aurelia's data binding engine will keep those two things in sync. So if I open up this JavaScript side-by-side with the HTML, you're going to begin to see how the two pieces are connected. And you're also going to notice in certain instances that for our templating language, for our data binding syntax, we've actually tried to follow and borrow from ECMAScript 6. So you may have noticed the ECMAScript 6 string interpolation right here with the dollar sign and the squiggly. So this is a way of including variables interpolated into string bodies. But we have borrowed that same exact syntax in HTML with the dollar sign and the two curlies. And so you can use that to interpolate into the body of the HTML any value that is a property on the class. And it will be one directionally bound so that any time it changes in the JavaScript object, it will automatically update the DOM. Of course, it will be batched asynchronously so that it's done in a highly performant way. So one directional data binding through the same syntax in HTML that already exists in ECMAScript 6. That's called string interpolation binding. You may also see down here value.bind. And so now you see a second way to do data binding. Any HTML attribute, you can append.bind to any HTML attribute to data bind that attribute to a property or to an expression. In this case, it's just a simple property of first name, but it could be customer.address.city. So it can be a simple expression. Now you know how to data bind any HTML attribute.bind. What does.bind do? It does what we call a default data binding. So this means usually it's one directional data flow from the JavaScript world into the HTML. One direction. There is an exception to that and that is input controls, text areas and selects. These kinds of form controls. By default, they will do two directional data binding. Because usually when you're binding to an input control, you want to recapture the input that is typed in that control and push it back into the model. So this is what we call another convention here around binding. You just say.bind and we pick what is the most sensible way to data bind the thing you're binding. It's usually one way data binding, but with forms controls, it's two way. Now of course, you always have control over this. So if I want to be explicit instead of saying.bind, I can say.2 way. And I've now said this is explicit two way binding. Anytime the model changes, it's reflected in the HTML. Anytime it's changed inside the input control, it's pushed back into the model. But I could also say one way. If I only wanted the data to flow from the model to the HTML. Or I could say one time, in which case no synchronization will occur. Just the initial value will be taken from the model and placed in the input. So you have complete control, but usually what you want to do is just say.bind. Because the default behavior is the most sensible thing for 90% of the use cases. So this is again a simple convention. You've now learned about 80% of the data binding syntax for Aurelia. You've learned string interpolation and you've learned how to bind any HTML attribute. The next thing you want to learn is how to connect events. Look up here at the form control. Submit.trigger. This says anytime the submit event fires, trigger the submit method on my class. So that's going to cause submit to be executed. Anytime the submit event of the form fires. Now you may notice a pattern here of something.something. And this is an easy visual cue for you in our templating language. Anytime you see a. in an attribute, that's invoking something from Aurelia's binding engine. A binding command. In fact, that's fully extensible. You can even write your own binding commands. But we provide you a bunch by default that makes sense for the common scenarios. But that's just an easy visual cue. So you can look at a view and see all the data bindings really quick by just looking for that. in there. Okay? So let's go ahead and run our simple app. It's not too exciting, but let's go ahead and start the server. And there it is. Oh, there it is. That was the old version. So you can see we have our view. It's rendered. You can see how the values from the JavaScript object, John and Do, are in the inputs. You can see that as I type in there, the full name is updated. Because there was some string interpolation there. I didn't show that to you, but if you look right here, data binding to full name. So you can see that as I update in those fields, that stays update. Updated and as I click the submit button, that method on the view model is attached. Okay? And fired. So you can see that is how you build a simple screen. It's the same pattern you're going to use over and over again. The same simple set of patterns to build your apps, no matter how complex or how simple they are. So let's get a little bit more complicated. You know, this is a single page, literally a single screen app. And that's not very interesting. So let's add a router in. Let's get some navigation. Let's get another page in there. So to do that, I'm going to turn the existing app that we created into our first screen. So I'm going to rename it Welcome HTML and Welcome JavaScript. And then I'm going to create a new app file. So I'm going to create app.js. And again, I'm going to create a simple ECMAScript 6 class. This class is a one special method on it called configure router. So we're going to have a client-side router that synchronizes with the history state of the browser and that maps history state to screens that we're going to load and display. So all we have to do for that is implement a configure router method and give it a set of patterns to map. So we configure the router and then we say map these routes. And for each route, we're going to give it a pattern or a collection of patterns. And any time that pattern is matched in the URL, it's going to load a module and it's going to render it and its view into the DOM. And notice that now we're pointing at that welcome module that we've already created. So we're going to take the screen that we already created without making any changes to it and turn it into a screen that's embedded inside of a navigation app where we can swap back and forth. So following the same pattern we've got app.js, we need app.html. We need to show how the Chrome or the layout of the app is going to render. And this is a little bit more HTML, but it's not bad. I'm going to collapse the nav part at first and just show you again. It's just a template, just an HTML template. But notice I've got a custom element in here, router view. This is a custom HTML element that's provided by the framework. And it automatically connects itself with the router that you've configured over here. So that any time the router matches a pattern and it finds a module to load, it then communicates with the router view to display the current screen. So wherever you put this router view, that's literally the location in the DOM where that screen will be displayed, right? And so you can put any HTML you want around that. So one of the things I added was a nav bar so that we can actually have, you know, bootstrap tabs to click on to navigate from screen to screen. So I created a nav bar. Mostly it's just a bunch of bootstrap classes, but you can see some things you've already seen in here, such as some interpolation to get the title property from the router. And you can see some new data binding system syntax here. Look at the LI, repeat dot four. Remember I told you anytime you see the dot, this is really as data binding. Also remember I told you we tried to borrow from ECMAScript 6 syntax wherever it made sense. So if you know ES6, you may notice that we borrowed the syntax from the new four of loop in ES6. So repeat dot four row of router navigation. What does this do? Well, notice how we marked our route with nav true. You have the ability to select particular route configurations which you want to appear in a visible navigation structure. And I really will take all those routes and create a navigation model for you so that you can actually use it to render a user interface. So all this does basically is it says, find me all the navigable routes that I should generate a UI for. For each one of those, create an LI. Repeat over that array, generating an LI for each. And inside that LI is an ATag. And look, there's a binding expression again. href.bind. So bind that to the href that's generated for that route. And of course put the title of that route inside of the content of the ATag. So you can see how the pieces of the data binding system are coming together here. The string interpolation, the dot bind for basic attribute binding, and now we've got repeat dot four for repeaters. You can also see something interesting in the class here. We're able to use string interpolation in the content of any attribute to mix static and dynamic content inside of the body of an attribute. So here, the router knows which route is currently active. So based off of which route is active, I'm adding a class. That way I can highlight the proper menu item when the particular associated route is displayed. Okay? So again, we just added a couple of new concepts, the router view and then the repeat binding. You may also notice down here there's an if dot bind. And this lets you conditionally include parts of the DOM based off of an expression. So when the router is navigating, we're going to show a spinner. And when the router is not navigating, that LI is actually going to be removed from the DOM entirely. So we have all those capabilities. And that's all there is to it. If we flip back over here, you see it's already refreshed. And now we've got that nav bar up at the top. And then the original screen is being displayed below it. So really, it's not too exciting again because we didn't create a second screen. But now you can see how our original screen without any changes is now embedded, composed inside of the other view based off of what the router says the current state is. So let's add a second screen. For the second screen, we're going to just create a simple flicker image view based off of photos from NDC Oslo. So again, it's really simple, but it will show you a couple of additional things. So let's create a new route. We're going to have to set up a route for that, right? So I'm going to create a route and we're going to match just on the letters NDC. That will be our pattern, real simple pattern. I should mention you can have parameterized routes. You can have query strings, all those sorts of things. But these route patterns are really simple. We're going to map it to a new module we're going to create. We're just going to call that NDC. So that's the module we're going to load when this pattern is matched. We're going to definitely display it in our nav bar and let's give it a title and call it just call it NDC. Okay, so we've now configured a simple another route. Pretty simple, straightforward. So let's go create that screen. How are we going to do it? NDC.js, NDC.html. Now this one's going to be a little bit more interesting because I'm going to start to show you some additional features of the framework. So let's start with the JavaScript. So here now you see I'm starting to take some more advantage of the ECMAScript 6 features. I'm now using the module system. So you can see I'm importing some external modules. I'm importing something called inject from the Aurelia framework. And then I'm importing the HTTP client from Aurelia HTTP client. Now what is inject? Well, as it turns out, all of Aurelia is built with the dependency injection framework. So inject allows you to declare dependencies of your class, which the framework should instantiate for you and provide through your constructor. So you'll notice that there's an ECMAScript 7 decorator on line 4 decorating the class with this injection metadata, which basically says inject an instance of the HTTP client into my class. And you can see the constructor on line 10 has a single argument that is called HTTP. And so that's going to be provided by the framework. So if you've ever used dependency injection on the client side or on the server side, we have that core capability across every component in Aurelia. And this is how you use it. You just say what you want injected and we will provide those services through the constructor to you. You can see the class itself has just a number of properties again, a heading, an array of images, a URL. And then we have this activate method. And what's interesting going back to the router is that the router is very careful to ensure a specific life cycle when it navigates from one page to another. And you as a developer can tie into that and take control over navigation in your application. In this case, we're looking into something called the activate hook, which allows you to execute code when the new screen is about to be displayed. So what we're going to do here is we're going to make a JSONP request out to Flickr and get a collection of images for NDC Oslo. And then when that asynchronously returns, we're going to grab the data and store it in our images array. Notice that this method is returning the promise. Well, Aurelia understands promise and asynchronous code throughout. So if you return a promise from activate, that tells the router that you're doing some asynchronous work and that it should wait for that work to be completed before it displays the new screen. That way, if you don't want it to, your screen won't display without the data loaded. So you can go load that data asynchronously. The router will wait on you. Or not. If you don't return the promise, it will just display it. But you have that control. All right? So this is, again, a pretty simple JavaScript class. There's not a whole lot of Aurelia here. This is the first time you're actually seeing the Aurelia API at all. Notice that before, you've just seen plain JavaScript, right? And here we're just very minimally involving the framework, basically, for HTTP requests, which you could use your own library. You don't have to use ours, but I'm using it for convenience. And then for dependency injection. Okay? Let me create the view. ndc.html. Again, pretty simple and straightforward. We've got a template. We've got some string interpolation. Notice the div. We've got repeat.4. So I'm going to generate a div for every image in that array. And I'm going to data bind the images source to that data. So what image is displayed is based off of the data. Same syntax. You've already learned all the syntax. I haven't added anything new here in the view. All right? Notice now there are two links up in the header. And when I jump over to the next one, there's our list of images. You may have also noticed the spinner very quickly while it was loading. You see it? Right? It's fast, right? It's not always fast, but it's fast. So you can see there's a bunch of images. There they are. I want to show you something really powerful because I'm a bit frustrated with the way that my app HTML looks. It's got all this stuff. It's got too much markup for me. I'm going to extract it. I want to show you how really I can do composition of user interfaces. I'm going to extract the nav bar into a nav HTML file. So I'm going to create a new file, nav HTML. I'm going to put a template in there because every view has a template tag if I can type. Sample it. And then I'm literally going to take that markup as is out of here. And I'm going to paste it into this template tag. Okay? Now I'm going to dynamically compose that component that I extracted, that view that I abstracted, back into my original HTML. And I'm going to use Aurelius composition capabilities through the composed element. So I'm going to compose a view. I'm going to compose a view right back in there. So I've extracted that. I've refactored my view by extracting the nav piece into its own HTML file. And then I've composed that right back into the original view where it was. And of course it looks exactly the same. If I show you down here, it's a bit small probably. Let me make it a bit larger. You'll see that now there's that compose tag and inside of that is the nav. Now that's a bit frustrating too because now my DOM structure is changed. I didn't have that compose element in between the nav and stuff before. So you can actually control that as well by saying that this composition is containerless. And now you'll see that the nav is right there in line without the containing element. Okay? So this is composition of views. But guess what? I can also compose entire screens with JavaScript behavior. So I'm going to show you nested recursive composition of screens. All right? I'm going to come into my welcome screen and I'm going to compose my welcome screen inside of my welcome screen infinitely. Now this is a really bad idea. But I can say view model. I'm saying view model instead of view. View model equals welcome. Now I'm not actually going to do it quite like this because this would go on and on forever, recomposing the whole thing. So what I'm going to do is I'm going to put a nice little input type check box. I'm going to show you element binding. I'm going to give a name to this check box with the ref attribute. So I'm going to call it ref is recursive. All right? And then I'm only going to compose myself if bind is recursive dot value because I'm reaching into the value of the input control and of data binding the value of the input control to whether or not that compose is data bound into the view. So when the check box is checked, the composition will happen. And let us flip back over here. Now you can see this little dinky. Oh, there is a bug then. Now it's infinitely composing. If bind, did I spell it right? Oh, sorry, is recursive dot checked. That's a little oddity with the world of HTML. Now I can check that and there it is. Check that and there it is. Check that and there it is. It just keeps going. So now I'm dynamically composing that screen recursively inside of itself. I can even do something cooler. I don't want to dynamically compose. I want to statically compose it. Because I should mention that all the properties are composed can themselves be data bind. So you can actually data bind view model to a property and dynamically compose in based off of data different screens. But what I'm going to do is I'm actually going to show you how the same view model that we've already been working with, the same original screen we navigated to, the same original screen we now dynamically composed is actually a custom HTML element. Now I'm using a custom HTML element recursively. You see now it's statically composing that custom HTML element. I made no changes to my JavaScript code. That welcome screen is still a plain ES6 class, but now it's a custom element in my HTML. So this is some of the power of Aurelia with its dynamic composition, with its simplistic simple conventions around building custom elements and screens. Once you learn the basic couple of patterns of my JavaScript.js, my view.html, and the simple templating language, you learn how to navigate the different screens. You learn how to do dynamic composition. You learn how to do custom elements. Now of course there are more interesting things to learn as well, but my point here is that this is not a huge learning curve you have to go through. It's a very steady, smooth learning curve. And you can reapply what you've learned in one phase to the next phase. And so your knowledge expands very smoothly across the framework. Well, I don't have time to show you animation. Well, no, I don't have time to show you animation. But suffice it to say that we support a pluggable animation system, and we have support for animate CSS, velocity, green sock, and tiny animate today. All you do is plug it in, put some classes in your HTML, and then we can animate between different screens. We can animate things that are repeated in, all kinds of interesting stuff. But let's get back to our slides and let us round up our talk with that real quick. So what is the status of this project? Well, it's in a public preview, which basically means that it's quite far beyond an alpha, but not quite a beta yet. All right? So it's very full-featured. Even in this short amount of time, I showed you quite a few features, and there's a lot of other things you can do, too. But you saw custom HTML elements. You saw dynamic composition. You saw the router with navigation. I mentioned animation. You see the use of dependency injection. So there's a lot of very advanced features already implemented. There's only two or three that we have left to implement before we lock down. But we have people building very large and very complicated apps right now that are not dealing really with any missing features. So it's extremely fully-featured at this point. We have preliminary documentation. If you go on the website, aurelia.io, you'll see a docs tab. You can go there and you can read more. You can read about all the data binding stuff. You can read about how to create more advanced custom elements. You can read about how to create custom attributes, because we let you create attributes that you can then reuse across different elements that attach new behavior to existing elements. So you can do all these kinds of things. You can read more about the router, about child routers. You can do nested recursive routing as well, the same way we did it with composition. All these kinds of things is documented there. We call it preliminary docs because it's not really our ideal docs. It's really designed to answer the most common questions. But we'll come back to our next steps in a minute on that. As I mentioned, there are real apps in development, very non-trivial apps, while a good collection of companies. And there's a very active community already, as I already mentioned. So really good adoption, really good community participation. What are our next steps? Well, we recently announced support for IE9 and IE10. So that was the next step for us that we checked off. We started this down this path. We said we're only going to support IE11 and above. We realized that it didn't require too much work to actually get it up and running all the way back to IE9. So we can support the IE9 and IE10 as well. So that's done. We're about to release, like I mentioned, the next couple of days, our new command-line tool. One of the things is to help you get started faster, but the main thing we're going to focus on with this release is bundling. So you can actually take all your JavaScript and all our HTML, bundle it together as a deployable app, and that's better optimized for actually deployment scenarios. So the tooling will do that for you. So there's a blog post coming on that soon. So that's done. Stabilizing the API, almost done. Everything I showed you today is stable. The bulk of the major use cases that everybody is, you know, using, that stuff is stable. There are a few more edge case APIs which we're changing a little bit. Most people don't even know those exist. We haven't told them because we wanted to change them. So there's some stuff like that happening around the fringes, but the bulk of the API is fairly stable at this point. Performance optimization is happening right now. Now, hopefully you noticed there really wasn't any issue with performance, but there's a lot we can do to make it even faster. And especially as I mentioned, we're targeting mobile, so we're going to squeeze every bit of performance we can out of the framework on mobile. So as it turns out, we already know how to optimize it quite a bit. The hardest part of optimization is not doing the optimization. It's actually measuring the performance and keeping records of that and tracking all that and putting all the infrastructure in place to actually do that in the correct way, really, that we can track and report those things. So we've actually been building infrastructure for benchmarking and tracking performance and doing all that testing. So now that that's built, we're in the process of writing our benchmarks and beginning serious performance optimization. And we're going to blog a lot about that too, so it's a great opportunity to kind of learn some of the interesting things that go into optimizing a framework like this. All the really weird things you wouldn't do in your normal code, but that you have to do in a framework because of the way JavaScript virtual machines work. So if you're interested in that or curious, definitely follow the blog, blog.derandal.io, because we're going to be talking about the optimizations we're doing. And we're also right now working on a rich interactive documentation experience. Like I mentioned, we have preliminary docs. We have a much broader vision for what we think will be a very nice experience for you as developers, either getting started or wanting to go through a tutorial or needing to use reference or watch videos or all these different scenarios. So we're working on a very rich interactive documentation experience, and that's being designed right now. Also, what's being developed right now is plugins. I mentioned that we have four animation plugins because the animation system is pluggable. We also have plugins for modal dialogues. We have plugins for validation, data validation, plugins for internationalization. And these plugins work together. So validation and internationalization work together, and that also works with routing so you can have internationalized routes and all this kind of stuff. So the number of plugins, some of them are official, and a number of them are just being created by the community now. Like I mentioned, really great community participation. So they're out there creating reusable plugins as well. And all this is leading up to our official beta, which is sort of like a release candidate, to be honest, because it'll be a solid, stable, fully featured beta with real documentation and a full plugin system and all this kind of thing. And so we're hoping that it's going to happen in about two months from now. Give or take. And so these literally are the last things that need to happen before that beta. And it's mostly about really the optimization piece and the documentation piece and the final stabilization of the API. So that's really where we're at. Once we hit beta, we'll officially kind of say, now you definitely can go to production with this. We have people already in production with it. They're brave and have a little bit of additional experience usually around deploying and bundling and these kind of things that we haven't finished yet. But we're telling people to wait to the beta to actually go to production because when we hit beta, we'll certify that this is really ready to go. This is production quality. We're just letting it sit a little bit before we officially call it V1.0 release to make sure that any last minute bugs and things that crop up we can take care of before we put that stamp, that final stamp on it. So that's happening in the next couple months. And yeah, so that is Aurelia. Hopefully that made sense to you. Hopefully you saw the clarity of the code, the focus on writing simple clean code, the focus on standards-based code. And hopefully that you understand that you actually learned like 80% of the framework already because you just follow these simple patterns and conventions. You learned almost all the data binding syntax. You learned how to create custom elements, how to do routing, all these sorts of things already. So you just got a little bit more incremental learning to do as needed when you build apps. So hopefully I will see you out there in our community building apps. You can jump in the Gitter channel. Like I said, there's about almost 1,500 developers in there asking questions and helping each other. So you can get assistance there. We'd love for you to contribute to the project. We have a lot of community members writing plugins, contributing bug fixes and features, and just playing an active role in the community. So we invite you into that. We invite you to build apps. Please, if you're building things, let me know. I love to hear your stories. I want to hear your challenges. I want to hear all about that. As I mentioned, it's open source, but it's backed by business. And so we really care about you as our customers, and we want to make sure that you're able to do what you need to do, and we want to serve you in that way. So thank you very much for being here this morning. Please check out Aurelia, and I look forward to talking with you more soon. Thank you. APPLAUSE Also, there's some stickers here. I don't have very many left, but I'm going to toss them down here on this step. If the front row gets dibs, I guess. There's really only a few left, sorry. APPLAUSE APPLAUSE
 Good morning. I hope everyone is enjoying the conference and I welcome you on this third day  and I'm thankful that you have chosen this first session this morning to be with me and to hear about Aurelia.  So without any further ado, let's kind of jump into the conversation and the demos for Aurelia today.  A bit about myself first. If you don't know me, I've been working in the space of front end frameworks and libraries for about ten years now  and have built frameworks similar to Aurelia in many ways across a host of different platforms starting with the Windows platform as early as 2005  and also working in Flash, Flex, Silverlight, Unity 3D and the web building frameworks and platforms similar to this across all those different technologies.  The ones that are most well known for are Calibre Micro which has been around for about five years now and is still in steady great use in the XAML world  by both big and small companies all over the world and also Durandal.js which is targeting the web platform which again is still quite healthy, mature and being used  by both big and small companies all over the world. Just to give you an example, the types of companies that are using these frameworks  still today includes customers like Microsoft, Walmart, Twitter, GitHub and more.  So a lot of names you probably recognize have built software on these open source products that I've produced over the last ten years  and particularly these within the last five years building really cool exciting things.  And early last year Google took an interest in what I was building and planning to do with the next generation version of Durandal  and so they contacted me and they said, hey, let's work together on Angular 2.0 and I said, well, that sounds interesting.  We began working together and I worked with them for about ten months after which I get the distinguished reputation of the guy who quit the Angular team.  So you may know me through that as well. So suffice it to say after a number of months of development, a series of what I would consider serious disagreements  in philosophy, design, features, et cetera around the development of front end frameworks kind of came to a head and mounted to, you know,  just a significant amount where it was no longer possible to continue really working on that project with them.  So I left to return to my existing community which was still very alive and well with Durandal.js and still is to this day.  And to pick up where I left off building a next generation framework based off of those previous, all those previous years of developing front end technologies.  And so that brings us to Aurelia which we just announced in February of this year.  And so I'm the creator of that but really playing a big, more of a project lead role right now as we have a team of 15 developers working daily on Aurelia  and the surrounding ecosystem. So that's what the bulk of this talk will be about of course, Aurelia.  And here's our basic short agenda for the rest of our time together.  First I want to talk about the what and the why of Aurelia.  You know, what specifically is it? What is the design philosophy? Those sorts of things.  And why are we building it? You know, why another JavaScript framework, right?  You know, you've seen how many days since the last JavaScript framework. Have you seen that site?  So, you know, there's so many frameworks. Why another one?  And we think that there are some interesting distinctives with what we're doing.  We think that things will be very interesting to you and important to you and what you want to do with your businesses.  And so I want to share a little bit about the why as well.  Then we're going to spend the bulk of the middle section of the talk building a simple application showing you features.  Hopefully you get a sense of how things are put together, what the methodology is for building apps.  And then we'll conclude the talk with the status of the project and a look at what we're working on right now.  What are our next steps and what are kind of our road map is for the next few months.  So first, what and why are we building Aurelia?  Well, what is it? Okay, so first it's plain and simple. It's ECMAScript 6 and 7.  So if you had the chance on two days ago to hear my ECMAScript 6 talk,  then you know that it's like we're virtually getting a brand new language in the browser, right?  So at its core, Aurelia is just JavaScript.  But it is written targeting literally two versions into the future almost of JavaScript.  ES6 was actually finally approved two days ago.  So I guess it's just one version in the future now.  But we're targeting next generation JavaScript and Aurelia is just JavaScript.  But interestingly, it's not one gigantic JavaScript library.  It's actually a collection of collaborating libraries.  So with the emergence of modules in ECMAScript 6,  we have a standard way to kind of break apart our framework into collaborating modules  each with a particular feature or a particular responsibility that they're concerned with.  So Aurelia is broken into a number of feature modules,  many of which can actually be used independently of the larger framework.  So for example, we have a dependency injection library,  which you're free to take and use on the server in a Node.js app.  It has no connection to client-side apps or to the larger Aurelia framework per se,  but it's an enabler piece for us.  And so the framework itself is built as this set of collaborating libraries,  many of which you can use in different ways outside of Aurelia.  That's great for us for a lot of reasons, of course.  We can develop in parallel.  We can independently version and release them  and do a lot of nice things that help us to be very agile  and also to assist you in getting you the features and the bug fixes  and those sorts of things that you need.  So it's just JavaScript, just JavaScript.  The purpose of it, though, really in the grand scheme of things,  when you bring all these collaborating modules together,  it's really targeted about building an next-generation JavaScript client apps.  This means targeting the browser with rich interactive experiences.  This means targeting the desktop with technologies like NWJS or Electron.  And this means targeting devices, mobile devices,  with things like PhoneGap, Cordova PhoneGap.  So anywhere that Web technology is, that's where you use Aurelia.  As a rich client technology to enable rich interactive experiences  for your customers or your audience.  So building JavaScript clients.  What is the philosophy of the framework?  How do we think about the framework?  How do we want you to think about the framework?  Well, the first thing that's very important for you to realize  is that it's completely open-source.  It's MIT licensed and that's not going to change.  Now, if you know much about open-source licenses, you know that MIT is a very permissive license.  So this is a framework that you can take, you can use,  and you can feel very confident using,  feel very comfortable in terms of the licensing model around that.  And so first and foremost, it's open-source.  Second, we're focusing, you know, in our philosophy on clean code.  This means we want, of course, our code to be clean,  but it's also an enabler for you to write clean code.  Standards-based code.  I've talked about ES6 and ES7.  What we really want is you to write apps with these latest standards,  and we want you, when you look at your app, when you look at your code,  we want you to, for the most part, see your code, not see our framework.  We want to encourage you and help you in writing very clean, modern JavaScript code.  So the framework is very much about modern standards, clean code, and staying out of your way.  And we do a lot of this kind of staying out of the way by leveraging simple conventions.  You know, when I look across the last ten years of framework development that I've been doing  and the consulting I've done with a bunch of companies building all kinds of apps,  certain sorts of patterns tend to emerge for the ways that we build things.  And so it makes sense to take those patterns and teach the framework what those patterns are  so that we as developers don't have to go configuring the framework  for every single little piece that we build when we're doing the same thing over and over again.  So the framework should understand those kind of things,  and it should do that work for you so you don't have to do that work,  so you don't have to write that code, so you don't have to maintain that code.  So when you bring new people on the project, you don't have to teach them about that kind of code.  All right, so the result, of course, is clean code, but with simple conventions, it means you write less code.  It's easier to read. It's easier to learn. It's easier to understand. It's easier to maintain.  And another big part of this, of course, is that is testable, meaning the framework itself is testable,  but it's also very concerned with making it possible for you to test your own apps.  This means unit testing your apps as well as end-to-end testing of your apps.  So these are all kind of core parts of the philosophy of the framework.  Things that we think about constantly, things that we talk to ourselves about, so to speak,  when we're thinking about how we're implementing things and what features we're implementing  or how we're building the framework overall.  And finally, I want to talk about, you know, the status of this.  When we say what, what's really kind of neat is even though it's barely been, you know,  known to the public, so to speak, for more than four months, there's already an extremely rapid adoption  happening in a large, active community.  We have close to 4,000 stars on GitHub, so that's an average of almost 1,000 stars a month  for an alpha framework, like I said, barely over four months old.  So people are getting very excited. People are getting involved.  There's about 1,500 people in our Gitter chat room right now, all over the world talking  about the framework, helping each other, working with it.  We've got a 15-person developer team on this.  They're not the only ones contributing.  Of course, there are contributions coming in from regular community members all over the world  doing really cool stuff already.  People adopting it, building apps, again, both big and small companies everywhere.  So really, really cool stuff already happening in terms of the community and the adoption.  And hopefully, when I get into the demos, too, you're going to see why.  Hopefully, that will resonate with you and it will make sense why people are getting excited about this.  And as a subtext to that, I also want to say that Aurelia is commercially backed.  So it's open source, but commercially backed by Durandal Inc. and some strategic partners we have.  And this is really an important part of a framework when we're looking at this next generation  and you're building apps and you're building businesses on a framework.  So when you use something like Aurelia, it's not just like some small little library you toss in  and you can pull back out and easily replace.  If you're going to choose a framework that's going to help you to build your entire app,  that's going to be the base of your application architecture,  you want to choose something very carefully.  So one of the things that we've done is we've created a new company.  We've been creating strategic partnerships with other companies  in order to make sure that we can take this framework and fully commercially support it  and build an entire ecosystem around it that rivals the best ecosystems in the native app development world.  And so I don't have a bunch of announcements to make about that today,  but you'll be very interested to see some things that we're going to be doing in the next few months.  But suffice it to say that there is a company behind this, it is commercially backed,  and the framework is tied to the success of the company.  So our community is very important to us, but it's not just lip service.  We have to meet your needs as a community or else our business fails.  And we have intentionally made that connection between the business and the open source project  because we think that that is the best result in terms of tying our success to your success.  So this is very important.  There's a number of other frameworks out there,  some of them made by very, very large companies.  I won't name any names, but there's absolutely no connection to the business from the open source framework.  So this is something very strategic that we're doing.  We think it's really important with something at this level.  Okay, so why are we building it?  And this does kind of crossover with a little bit of what I just said at the what.  There's obviously a connection there.  But first point there is, you know, browser technology is advancing and changing amazing in amazing ways, right?  Again, I talked a couple of days ago about ECMAScript 6.  That's now approved.  ECMAScript 7 has been parallel developed already.  You know that the, you know, you may hear me saying ES6, ES7.  The correct names are ES2015, ES2016, just so you know.  I can never say that because I've been saying ES6 for too long.  So it's an old habit.  But fundamentally, the language of the browser is evolving in rather extreme ways.  You know, again, if you haven't seen ES6, it's almost like there's a new language in the browser.  So wouldn't it be great if there was a modern JavaScript framework for building apps  that was built on and assumed this modern JavaScript language and used all the constructs of this modern JavaScript language  to represent the framework from the beginning?  Wouldn't that be nice?  And what else has happened?  Well, in the last few years, the DOM has significantly advanced in terms of its performance,  in terms of its consistency across browsers,  in terms of new APIs that allow you to say not use jQuery.  And wouldn't it be great if a framework was built on top of the modern DOM  that did not use any DOM abstractions but used the raw power of the modern DOM  and exposed that to you?  And wouldn't it be great if a framework was built with web components in mind?  Another big change has come into the browser,  the ability to exchange reusable components for the web.  Wouldn't it be great if the framework was designed with that  and utilized that technology from the beginning, and that was part of the core?  And these are some reasons why another or a new JavaScript framework,  because really there isn't anything out there that does this today.  And we think that these are significant improvements and enhancements to the web platform,  and so much so that the way that you build a framework and the way that you build apps  is fundamentally different, and it deserves a framework that takes these things into consideration  as of first importance.  We also wanted something with no external dependencies, so except for polyfills.  So really the polyfills are things that patch up across browsers,  these next generation features which aren't consistently implemented everywhere yet.  So the idea with this is that we want to be able to support our framework,  we want it to be reliable, and we don't have to wait on some other company  or open source project to fix a bug that is affecting you when it's not in our code.  So it's better for us if we have no external dependencies.  The interesting thing about the polyfills is, is when you design a framework built only on polyfills,  is that over time the framework will actually get both smaller and faster,  because the polyfills will fall away and be replaced by native browser implementations.  So we actually designed this framework to get smaller in the future and to get faster in the future  just because of the way that browser technologies are advancing.  So this is an important reason why in terms of building a framework in this style.  We wanted a simple and powerful programming model.  If you've looked at any other JavaScript frameworks out there,  there's tremendous learning curve associated with just about any framework that you look at.  And frankly, to me, I just wasn't happy with that.  It was just, things were just too complicated.  I really wanted a framework where we could just, for the most part,  write plain ECMAScript 6 and just have it work,  and have a data binding syntax that was simple, easy to pick up and remember.  So we want a simple, powerful programming model.  We don't want something simplistic, but we want something simple, easy to use,  but that doesn't sacrifice power and flexibility.  And so, really, again, looking across the landscape, there wasn't anything that I felt met that criteria.  We wanted modern and future compatible two-way data binding.  And you may have heard a lot about two-way data binding recently with React kind of saying,  oh, it's an anti-pattern, blah, blah, blah, blah, blah.  But this has a lot to do with the way that two-way data binding has been implemented  in particular other frameworks, which causes problems.  But as I've mentioned, the browser is changing.  ECMAScript 7 is bringing native observability to objects.  There are modern APIs that let us polyfill that in various ways.  So wouldn't it be nice if we had a framework that assumed native observability of JavaScript objects  and polyfilled that for browsers all the way back to Internet Explorer 9?  And it built its data binding framework on top of that  in order to create a high-performance, modern, two-way data binding framework.  And so, again, it literally does not exist in any other framework.  And so that's why, another reason why, Aurelia.  And of course, as I mentioned earlier, commercial support may not be really interesting to all of you,  may not be needed or wanted by all of you, but there are a bunch of companies out there  that when they've looked across the JavaScript landscape, they said, you know,  we're building apps on this, we're building our business on this, we're spending millions of dollars,  but I can't get commercial support for anything.  And so we want to provide that, that's part of our business plan, of course,  we need to have a framework that we can reliably provide that for.  And so that's also another reason why, from a business perspective.  And of course, we want a pathway forward.  You know, there's a lot of people in my existing community using Durandal.  There's already also a lot of people using Calibre Micro on the Windows side  that are looking to move to the web.  So we want to provide a pathway forward to them that makes sense,  that's easy to learn and easy to transition to.  There's a lot of people also using Angular that are looking for kind of the next generation framework.  We wanted to provide something for them that made a lot of sense,  but that gave them a very smooth transition and that was simple and easy for them to understand.  And so that's another reason why, a pathway forward for people invested in existing frameworks,  but a pathway that's an easy to understand transition, that makes a lot of sense to them.  Okay, enough talking about that. Let's build an app.  So how do we do that?  Well, we're in an early stage right now, so the hardest part of building an app is the setup.  I'm going to skip that whole part today, right?  But this is how you do it.  Basically what you do is you go to GitHub and you download our Skeleton Navigation repo.  So this is basically a starter project.  And it's actually a pretty cool starter project because we've set up a whole bunch of things that you need in the real world.  Like, we've already set you up for unit testing, for end-to-end testing,  for building your ES6 code, for doing code coverage reports, for browser sync.  There's a Node server you can use to serve up your assets.  A whole bunch of stuff is already pre-configured, so you just download it and you get all that for free.  It's designed to actually be a production quality starter kit.  So you can go download that, you unzip it, and then you're going to need to install the build dependencies.  The world of modern JavaScript really is connected with Node.js.  All the tooling is built on Node.js.  So I want to be clear about this.  Aurelia itself has zero dependencies on Node.js.  No dependencies on Node.js whatsoever.  But the build tooling for modern JavaScript is pretty much all based on Node.js.  So you need to install Node.js.  If you haven't done that, it's not something to be really afraid of.  You just download it, install it, it's no big deal.  And then you're going to install a few things through Node, using Node package manager, MPM.  First, you're going to install Gulp.  And this is the actual build task runner that our starter kit uses.  Again, Aurelia, Node dependencies on Gulp, you can set things up any way you want.  But this starter kit uses it, so you'll need to install that.  Then you run MPM install inside of that directory and it's going to bring down all the modules that Gulp relies on to do the building.  So everything for building your ES6, everything for setting up your unit tests,  all that stuff is going to get installed with that command.  Then you're going to install JSPM.  And JSPM stands for JavaScript package manager.  It is a package manager oriented towards client side package management.  Built with the notion of ECMAScript 6 modules being the primary mechanism for distributing JavaScript code.  So this is a package manager that understands the ES6 module system and that understands the nuances of client side development.  It's not a repository.  It can actually install packages from MPM or from GitHub directly.  But it is a package manager that will manage those packages.  It understands multiple module formats, so you can bring in an AMD library, a Kamajaya library, an ES6 library, a global JavaScript library.  And it will understand that and it will make them all work seamlessly together.  And it will make them all integrate into the ES6 module system.  So this is a fantastic way to handle your dependency management for your client side apps.  And it's fully integrated with the ECMAScript 6 loader.  So that's, again, not a requirement of Aurelia, but we think it's a really great product that really is going to enable you and empower you in your client side development.  So that's kind of our default option there.  So you install JSPM.  Once JSPM is installed, you then ask it to install the client side packages.  And that's going to actually download Aurelia and install it.  For the starter kit, it's actually going to also download Bootstrap and Font Awesome.  Those are, again, not requirements of Aurelia, but the starter kit uses them so it's not hideously ugly, right?  So that's going to install all the client side packages used by your app.  So once you've got this set up, then you say, go up Watch.  And this is going to spin up a little server to serve the static assets.  And then you can begin editing code and viewing it in the browser.  And we set up browser sync.  So every time you save a file, your browser will automatically refresh across all browsers and all devices connected.  Everything will be synced.  So that's all set up for you, too, for cross-browser, cross-device development.  Now, that's a little bit complex.  I want to tell you that we're about to release our own command line tooling.  Literally, it'll either be today or early next week.  And our command line tooling, one of its main purposes is to simplify getting started with Aurelia.  So be on the lookout for that. You can read up on our blog, blog.durandal.io, about that.  We have blog content there every single week about releases, about features, and all kinds of things like that.  So realize that this is because we're almost in a beta, but not quite in a beta.  So getting started is a bit more complicated than, of course, it will be when we hit beta and when we hit the 1.0 release.  But if you want to get started, this is good, and this will give you really a production quality setup.  And all you do is delete the code out of there and start writing your own app.  So this is where we're going to start our demo with today.  I've already downloaded this, unzipped it, installed everything, and got it all set up.  So let me just jump out of this and let's start building an app.  So the place I want to start today is in the index HTML file.  So this is the place where you would probably look anytime you looked at a new app anyway.  So we're going to start there.  Notice in the head of the document, there's really nothing too bizarre.  I've got Bootstrap in there. I've got Font Awesome in there, and I've got some custom styles.  None of that's really important. That's all standard stuff.  What we want to look at is what's in the body of the document.  And this is important because almost every Aurelia app is going to have an index HTML that looks basically the same.  There's almost nothing in there. Its purpose is to Bootstrap or start up the framework.  Okay?  So first, we're going to include SystemJS.  SystemJS is the module loader, the ECMAScript 6 standards-based module loader that is distributed with JSPM.  So you get that package manager and module loader integration.  So we're going to include the module loader because even though it's a standard yet, it's not implemented on all the browsers.  So this is one of those polyfills, basically.  So we're going to include SystemJS to get the ES6 module loader.  Then we're going to include ConfigJS.  This is actually a file that's generated by JSPM.  This is how it figures out how to make all the different module systems work together.  When you install a package, it looks at the JavaScript code and specs it, figures out what it is and how it works,  and puts a little configuration in there automatically for you.  So you never have to touch that.  Whatever you ever work with, require JS, for example.  You know you have to write the map, the path, and the shim config for every library just about to get it to work right.  JSPM understands those things and generates it automatically for you, so you don't have to write that kind of thing.  That's what's in ConfigJS.  So your module loader and the configuration for the loader just include those scripts.  And then what you want to do is you actually want to use the ES6 standards module loader to load up Aurelia.  And so that's what system is. When you say system import, this is a standards-based API for dynamically importing a module in ECMAScript 6.  So we're importing the Aurelia bootstrapper, which is really Aurelia's module that starts up the framework.  It kick starts everything, configures everything, and gets your app running.  So how does it know what to do?  Well, simple conventions.  It's going to look at your HTML document.  It's going to find anywhere that you've put an Aurelia app attribute.  And it's going to assume that you want that HTML element to become the place in the DOM where your app is rendered.  And by convention, it's going to look for your app to be implemented in an AppJS JavaScript file,  and its view to be rendered in an AppHTML HTML file.  Now, everything we build in Aurelia pretty much has two parts.  The JavaScript part, which will have your behavior, usually exporting an ES6 class,  and the view part, which has a standards-based HTML template that contains the view that is the rendering of that JavaScript file.  So we isolate your behavior and your state from your rendering and your view.  Now that you know that, you know how, you know, 50% of building in Aurelia app.  That's the same pattern over and over again we're going to use. You're going to see it.  So to start building our app, we're going to create our AppJS and our AppHTML file.  So I'm going to create AppJS.  And the code in there is going to be a simple ECMAScript 6 class.  Notice you do not see the Aurelia framework anywhere.  This is just a simple class. Actually, it's an ES7 class. I'm using some ECMAScript 7 features here.  It's a class. It's got three properties, three simple properties, heading, first name, last name.  It has a computed property, a full name that concatenates the first name and last name.  And then it has a simple method on it called submit. That just shows an alert.  So if you know ECMAScript 6 or 7, there's nothing special here. It is a plain class.  Pure ES6 and 7.  But Aurelia, it renders JavaScript objects.  The simple pattern allows us to now create an AppHTML.  And we're going to put some HTML in there.  First thing to notice is that there's a template tag. Again, this is a standards-based template tag from the Web Component spec.  A cross-browser standards-based way of defining templates.  And inside of that, we're going to put some HTML. And that HTML is going to be bound to the instance of our class.  So that any property or any method in our class can be connected with the HTML.  And Aurelia's data binding engine will keep those two things in sync.  So if I open up this JavaScript side-by-side with the HTML, you're going to begin to see how the two pieces are connected.  And you're also going to notice in certain instances that for our templating language, for our data binding syntax,  we've actually tried to follow and borrow from ECMAScript 6.  So you may have noticed the ECMAScript 6 string interpolation right here with the dollar sign and the squiggly.  So this is a way of including variables interpolated into string bodies.  But we have borrowed that same exact syntax in HTML with the dollar sign and the two curlies.  And so you can use that to interpolate into the body of the HTML any value that is a property on the class.  And it will be one directionally bound so that any time it changes in the JavaScript object, it will automatically update the DOM.  Of course, it will be batched asynchronously so that it's done in a highly performant way.  So one directional data binding through the same syntax in HTML that already exists in ECMAScript 6.  That's called string interpolation binding.  You may also see down here value.bind.  And so now you see a second way to do data binding.  Any HTML attribute, you can append.bind to any HTML attribute to data bind that attribute to a property or to an expression.  In this case, it's just a simple property of first name, but it could be customer.address.city.  So it can be a simple expression.  Now you know how to data bind any HTML attribute.bind.  What does.bind do?  It does what we call a default data binding.  So this means usually it's one directional data flow from the JavaScript world into the HTML.  One direction.  There is an exception to that and that is input controls, text areas and selects.  These kinds of form controls.  By default, they will do two directional data binding.  Because usually when you're binding to an input control, you want to recapture the input that is typed in that control and push it back into the model.  So this is what we call another convention here around binding.  You just say.bind and we pick what is the most sensible way to data bind the thing you're binding.  It's usually one way data binding, but with forms controls, it's two way.  Now of course, you always have control over this.  So if I want to be explicit instead of saying.bind, I can say.2 way.  And I've now said this is explicit two way binding.  Anytime the model changes, it's reflected in the HTML.  Anytime it's changed inside the input control, it's pushed back into the model.  But I could also say one way.  If I only wanted the data to flow from the model to the HTML.  Or I could say one time, in which case no synchronization will occur.  Just the initial value will be taken from the model and placed in the input.  So you have complete control, but usually what you want to do is just say.bind.  Because the default behavior is the most sensible thing for 90% of the use cases.  So this is again a simple convention.  You've now learned about 80% of the data binding syntax for Aurelia.  You've learned string interpolation and you've learned how to bind any HTML attribute.  The next thing you want to learn is how to connect events.  Look up here at the form control.  Submit.trigger.  This says anytime the submit event fires, trigger the submit method on my class.  So that's going to cause submit to be executed.  Anytime the submit event of the form fires.  Now you may notice a pattern here of something.something.  And this is an easy visual cue for you in our templating language.  Anytime you see a. in an attribute, that's invoking something from Aurelia's binding engine.  A binding command.  In fact, that's fully extensible. You can even write your own binding commands.  But we provide you a bunch by default that makes sense for the common scenarios.  But that's just an easy visual cue.  So you can look at a view and see all the data bindings really quick by just looking for that. in there.  Okay?  So let's go ahead and run our simple app.  It's not too exciting, but let's go ahead and start the server.  And there it is.  Oh, there it is. That was the old version.  So you can see we have our view. It's rendered.  You can see how the values from the JavaScript object, John and Do, are in the inputs.  You can see that as I type in there, the full name is updated.  Because there was some string interpolation there.  I didn't show that to you, but if you look right here, data binding to full name.  So you can see that as I update in those fields, that stays update.  Updated and as I click the submit button, that method on the view model is attached.  Okay? And fired.  So you can see that is how you build a simple screen.  It's the same pattern you're going to use over and over again.  The same simple set of patterns to build your apps, no matter how complex or how simple they are.  So let's get a little bit more complicated.  You know, this is a single page, literally a single screen app.  And that's not very interesting.  So let's add a router in. Let's get some navigation. Let's get another page in there.  So to do that, I'm going to turn the existing app that we created into our first screen.  So I'm going to rename it Welcome HTML and Welcome JavaScript.  And then I'm going to create a new app file.  So I'm going to create app.js.  And again, I'm going to create a simple ECMAScript 6 class.  This class is a one special method on it called configure router.  So we're going to have a client-side router that synchronizes with the history state of the browser  and that maps history state to screens that we're going to load and display.  So all we have to do for that is implement a configure router method  and give it a set of patterns to map.  So we configure the router and then we say map these routes.  And for each route, we're going to give it a pattern or a collection of patterns.  And any time that pattern is matched in the URL, it's going to load a module  and it's going to render it and its view into the DOM.  And notice that now we're pointing at that welcome module that we've already created.  So we're going to take the screen that we already created without making any changes to it  and turn it into a screen that's embedded inside of a navigation app  where we can swap back and forth.  So following the same pattern we've got app.js, we need app.html.  We need to show how the Chrome or the layout of the app is going to render.  And this is a little bit more HTML, but it's not bad.  I'm going to collapse the nav part at first and just show you again.  It's just a template, just an HTML template.  But notice I've got a custom element in here, router view.  This is a custom HTML element that's provided by the framework.  And it automatically connects itself with the router that you've configured over here.  So that any time the router matches a pattern and it finds a module to load,  it then communicates with the router view to display the current screen.  So wherever you put this router view, that's literally the location in the DOM  where that screen will be displayed, right?  And so you can put any HTML you want around that.  So one of the things I added was a nav bar so that we can actually have, you know,  bootstrap tabs to click on to navigate from screen to screen.  So I created a nav bar.  Mostly it's just a bunch of bootstrap classes, but you can see some things you've already seen in here,  such as some interpolation to get the title property from the router.  And you can see some new data binding system syntax here.  Look at the LI, repeat dot four.  Remember I told you anytime you see the dot, this is really as data binding.  Also remember I told you we tried to borrow from ECMAScript 6 syntax wherever it made sense.  So if you know ES6, you may notice that we borrowed the syntax from the new four of loop in ES6.  So repeat dot four row of router navigation.  What does this do?  Well, notice how we marked our route with nav true.  You have the ability to select particular route configurations which you want to appear in a visible navigation structure.  And I really will take all those routes and create a navigation model for you so that you can actually use it to render a user interface.  So all this does basically is it says, find me all the navigable routes that I should generate a UI for.  For each one of those, create an LI. Repeat over that array, generating an LI for each.  And inside that LI is an ATag.  And look, there's a binding expression again.  href.bind.  So bind that to the href that's generated for that route.  And of course put the title of that route inside of the content of the ATag.  So you can see how the pieces of the data binding system are coming together here.  The string interpolation, the dot bind for basic attribute binding, and now we've got repeat dot four for repeaters.  You can also see something interesting in the class here.  We're able to use string interpolation in the content of any attribute to mix static and dynamic content inside of the body of an attribute.  So here, the router knows which route is currently active.  So based off of which route is active, I'm adding a class.  That way I can highlight the proper menu item when the particular associated route is displayed.  Okay?  So again, we just added a couple of new concepts, the router view and then the repeat binding.  You may also notice down here there's an if dot bind.  And this lets you conditionally include parts of the DOM based off of an expression.  So when the router is navigating, we're going to show a spinner.  And when the router is not navigating, that LI is actually going to be removed from the DOM entirely.  So we have all those capabilities.  And that's all there is to it.  If we flip back over here, you see it's already refreshed.  And now we've got that nav bar up at the top.  And then the original screen is being displayed below it.  So really, it's not too exciting again because we didn't create a second screen.  But now you can see how our original screen without any changes is now embedded,  composed inside of the other view based off of what the router says the current state is.  So let's add a second screen.  For the second screen, we're going to just create a simple flicker image view based off of photos from NDC Oslo.  So again, it's really simple, but it will show you a couple of additional things.  So let's create a new route.  We're going to have to set up a route for that, right?  So I'm going to create a route and we're going to match just on the letters NDC.  That will be our pattern, real simple pattern.  I should mention you can have parameterized routes.  You can have query strings, all those sorts of things.  But these route patterns are really simple.  We're going to map it to a new module we're going to create.  We're just going to call that NDC.  So that's the module we're going to load when this pattern is matched.  We're going to definitely display it in our nav bar and let's give it a title and call it just call it NDC.  Okay, so we've now configured a simple another route.  Pretty simple, straightforward.  So let's go create that screen.  How are we going to do it?  NDC.js, NDC.html.  Now this one's going to be a little bit more interesting because I'm going to start to show you some additional features of the framework.  So let's start with the JavaScript.  So here now you see I'm starting to take some more advantage of the ECMAScript 6 features.  I'm now using the module system.  So you can see I'm importing some external modules.  I'm importing something called inject from the Aurelia framework.  And then I'm importing the HTTP client from Aurelia HTTP client.  Now what is inject?  Well, as it turns out, all of Aurelia is built with the dependency injection framework.  So inject allows you to declare dependencies of your class, which the framework should instantiate for you and provide through your constructor.  So you'll notice that there's an ECMAScript 7 decorator on line 4 decorating the class with this injection metadata,  which basically says inject an instance of the HTTP client into my class.  And you can see the constructor on line 10 has a single argument that is called HTTP.  And so that's going to be provided by the framework.  So if you've ever used dependency injection on the client side or on the server side,  we have that core capability across every component in Aurelia.  And this is how you use it.  You just say what you want injected and we will provide those services through the constructor to you.  You can see the class itself has just a number of properties again, a heading, an array of images, a URL.  And then we have this activate method.  And what's interesting going back to the router is that the router is very careful to ensure a specific life cycle when it navigates from one page to another.  And you as a developer can tie into that and take control over navigation in your application.  In this case, we're looking into something called the activate hook, which allows you to execute code when the new screen is about to be displayed.  So what we're going to do here is we're going to make a JSONP request out to Flickr and get a collection of images for NDC Oslo.  And then when that asynchronously returns, we're going to grab the data and store it in our images array.  Notice that this method is returning the promise.  Well, Aurelia understands promise and asynchronous code throughout.  So if you return a promise from activate, that tells the router that you're doing some asynchronous work and that it should wait for that work to be completed before it displays the new screen.  That way, if you don't want it to, your screen won't display without the data loaded.  So you can go load that data asynchronously. The router will wait on you.  Or not. If you don't return the promise, it will just display it. But you have that control.  All right?  So this is, again, a pretty simple JavaScript class. There's not a whole lot of Aurelia here.  This is the first time you're actually seeing the Aurelia API at all.  Notice that before, you've just seen plain JavaScript, right?  And here we're just very minimally involving the framework, basically, for HTTP requests,  which you could use your own library. You don't have to use ours, but I'm using it for convenience.  And then for dependency injection.  Okay? Let me create the view.  ndc.html.  Again, pretty simple and straightforward. We've got a template. We've got some string interpolation.  Notice the div. We've got repeat.4.  So I'm going to generate a div for every image in that array. And I'm going to data bind the images source to that data.  So what image is displayed is based off of the data.  Same syntax. You've already learned all the syntax. I haven't added anything new here in the view.  All right? Notice now there are two links up in the header.  And when I jump over to the next one, there's our list of images.  You may have also noticed the spinner very quickly while it was loading.  You see it?  Right? It's fast, right? It's not always fast, but it's fast.  So you can see there's a bunch of images. There they are.  I want to show you something really powerful because I'm a bit frustrated with the way that my app HTML looks.  It's got all this stuff. It's got too much markup for me.  I'm going to extract it. I want to show you how really I can do composition of user interfaces.  I'm going to extract the nav bar into a nav HTML file.  So I'm going to create a new file, nav HTML.  I'm going to put a template in there because every view has a template tag if I can type.  Sample it.  And then I'm literally going to take that markup as is out of here.  And I'm going to paste it into this template tag.  Okay?  Now I'm going to dynamically compose that component that I extracted, that view that I abstracted, back into my original HTML.  And I'm going to use Aurelius composition capabilities through the composed element.  So I'm going to compose a view.  I'm going to compose a view right back in there.  So I've extracted that. I've refactored my view by extracting the nav piece into its own HTML file.  And then I've composed that right back into the original view where it was.  And of course it looks exactly the same.  If I show you down here, it's a bit small probably. Let me make it a bit larger.  You'll see that now there's that compose tag and inside of that is the nav.  Now that's a bit frustrating too because now my DOM structure is changed.  I didn't have that compose element in between the nav and stuff before.  So you can actually control that as well by saying that this composition is containerless.  And now you'll see that the nav is right there in line without the containing element.  Okay?  So this is composition of views.  But guess what? I can also compose entire screens with JavaScript behavior.  So I'm going to show you nested recursive composition of screens.  All right? I'm going to come into my welcome screen and I'm going to compose my welcome screen inside of my welcome screen infinitely.  Now this is a really bad idea.  But I can say view model.  I'm saying view model instead of view. View model equals welcome.  Now I'm not actually going to do it quite like this because this would go on and on forever, recomposing the whole thing.  So what I'm going to do is I'm going to put a nice little input type check box.  I'm going to show you element binding.  I'm going to give a name to this check box with the ref attribute.  So I'm going to call it ref is recursive.  All right?  And then I'm only going to compose myself if bind is recursive dot value because I'm reaching into the value of the input control  and of data binding the value of the input control to whether or not that compose is data bound into the view.  So when the check box is checked, the composition will happen.  And let us flip back over here.  Now you can see this little dinky.  Oh, there is a bug then.  Now it's infinitely composing.  If bind, did I spell it right?  Oh, sorry, is recursive dot checked.  That's a little oddity with the world of HTML.  Now I can check that and there it is.  Check that and there it is.  Check that and there it is.  It just keeps going.  So now I'm dynamically composing that screen recursively inside of itself.  I can even do something cooler.  I don't want to dynamically compose.  I want to statically compose it.  Because I should mention that all the properties are composed can themselves be data bind.  So you can actually data bind view model to a property and dynamically compose in based off of data different screens.  But what I'm going to do is I'm actually going to show you how the same view model that we've already been working with,  the same original screen we navigated to,  the same original screen we now dynamically composed is actually a custom HTML element.  Now I'm using a custom HTML element recursively.  You see now it's statically composing that custom HTML element.  I made no changes to my JavaScript code.  That welcome screen is still a plain ES6 class, but now it's a custom element in my HTML.  So this is some of the power of Aurelia with its dynamic composition,  with its simplistic simple conventions around building custom elements and screens.  Once you learn the basic couple of patterns of my JavaScript.js, my view.html,  and the simple templating language, you learn how to navigate the different screens.  You learn how to do dynamic composition.  You learn how to do custom elements.  Now of course there are more interesting things to learn as well,  but my point here is that this is not a huge learning curve you have to go through.  It's a very steady, smooth learning curve.  And you can reapply what you've learned in one phase to the next phase.  And so your knowledge expands very smoothly across the framework.  Well, I don't have time to show you animation.  Well, no, I don't have time to show you animation.  But suffice it to say that we support a pluggable animation system,  and we have support for animate CSS, velocity, green sock, and tiny animate today.  All you do is plug it in, put some classes in your HTML,  and then we can animate between different screens.  We can animate things that are repeated in, all kinds of interesting stuff.  But let's get back to our slides and let us round up our talk with that real quick.  So what is the status of this project?  Well, it's in a public preview, which basically means that it's quite far beyond an alpha,  but not quite a beta yet.  All right?  So it's very full-featured.  Even in this short amount of time, I showed you quite a few features,  and there's a lot of other things you can do, too.  But you saw custom HTML elements.  You saw dynamic composition.  You saw the router with navigation.  I mentioned animation.  You see the use of dependency injection.  So there's a lot of very advanced features already implemented.  There's only two or three that we have left to implement before we lock down.  But we have people building very large and very complicated apps right now  that are not dealing really with any missing features.  So it's extremely fully-featured at this point.  We have preliminary documentation.  If you go on the website, aurelia.io, you'll see a docs tab.  You can go there and you can read more.  You can read about all the data binding stuff.  You can read about how to create more advanced custom elements.  You can read about how to create custom attributes,  because we let you create attributes that you can then reuse across different elements  that attach new behavior to existing elements.  So you can do all these kinds of things.  You can read more about the router, about child routers.  You can do nested recursive routing as well,  the same way we did it with composition.  All these kinds of things is documented there.  We call it preliminary docs because it's not really our ideal docs.  It's really designed to answer the most common questions.  But we'll come back to our next steps in a minute on that.  As I mentioned, there are real apps in development,  very non-trivial apps,  while a good collection of companies.  And there's a very active community already, as I already mentioned.  So really good adoption, really good community participation.  What are our next steps?  Well, we recently announced support for IE9 and IE10.  So that was the next step for us that we checked off.  We started this down this path.  We said we're only going to support IE11 and above.  We realized that it didn't require too much work  to actually get it up and running all the way back to IE9.  So we can support the IE9 and IE10 as well.  So that's done.  We're about to release, like I mentioned, the next couple of days,  our new command-line tool.  One of the things is to help you get started faster,  but the main thing we're going to focus on with this release is bundling.  So you can actually take all your JavaScript and all our HTML,  bundle it together as a deployable app,  and that's better optimized for actually deployment scenarios.  So the tooling will do that for you.  So there's a blog post coming on that soon.  So that's done.  Stabilizing the API, almost done.  Everything I showed you today is stable.  The bulk of the major use cases that everybody is, you know, using,  that stuff is stable.  There are a few more edge case APIs which we're changing a little bit.  Most people don't even know those exist.  We haven't told them because we wanted to change them.  So there's some stuff like that happening around the fringes,  but the bulk of the API is fairly stable at this point.  Performance optimization is happening right now.  Now, hopefully you noticed there really wasn't any issue with performance,  but there's a lot we can do to make it even faster.  And especially as I mentioned, we're targeting mobile,  so we're going to squeeze every bit of performance we can out of the framework on mobile.  So as it turns out, we already know how to optimize it quite a bit.  The hardest part of optimization is not doing the optimization.  It's actually measuring the performance and keeping records of that  and tracking all that and putting all the infrastructure in place  to actually do that in the correct way, really,  that we can track and report those things.  So we've actually been building infrastructure for benchmarking  and tracking performance and doing all that testing.  So now that that's built, we're in the process of writing our benchmarks  and beginning serious performance optimization.  And we're going to blog a lot about that too,  so it's a great opportunity to kind of learn some of the interesting things  that go into optimizing a framework like this.  All the really weird things you wouldn't do in your normal code,  but that you have to do in a framework because of the way JavaScript virtual machines work.  So if you're interested in that or curious, definitely follow the blog,  blog.derandal.io, because we're going to be talking about the optimizations we're doing.  And we're also right now working on a rich interactive documentation experience.  Like I mentioned, we have preliminary docs.  We have a much broader vision for what we think will be a very nice experience for you as developers,  either getting started or wanting to go through a tutorial  or needing to use reference or watch videos or all these different scenarios.  So we're working on a very rich interactive documentation experience,  and that's being designed right now.  Also, what's being developed right now is plugins.  I mentioned that we have four animation plugins because the animation system is pluggable.  We also have plugins for modal dialogues.  We have plugins for validation, data validation, plugins for internationalization.  And these plugins work together.  So validation and internationalization work together,  and that also works with routing so you can have internationalized routes and all this kind of stuff.  So the number of plugins, some of them are official,  and a number of them are just being created by the community now.  Like I mentioned, really great community participation.  So they're out there creating reusable plugins as well.  And all this is leading up to our official beta,  which is sort of like a release candidate, to be honest,  because it'll be a solid, stable, fully featured beta with real documentation  and a full plugin system and all this kind of thing.  And so we're hoping that it's going to happen in about two months from now.  Give or take.  And so these literally are the last things that need to happen before that beta.  And it's mostly about really the optimization piece and the documentation piece  and the final stabilization of the API.  So that's really where we're at.  Once we hit beta, we'll officially kind of say,  now you definitely can go to production with this.  We have people already in production with it.  They're brave and have a little bit of additional experience usually around deploying  and bundling and these kind of things that we haven't finished yet.  But we're telling people to wait to the beta to actually go to production  because when we hit beta, we'll certify that this is really ready to go.  This is production quality.  We're just letting it sit a little bit before we officially call it V1.0 release  to make sure that any last minute bugs and things that crop up  we can take care of before we put that stamp, that final stamp on it.  So that's happening in the next couple months.  And yeah, so that is Aurelia.  Hopefully that made sense to you.  Hopefully you saw the clarity of the code,  the focus on writing simple clean code,  the focus on standards-based code.  And hopefully that you understand that you actually learned like 80% of the framework already  because you just follow these simple patterns and conventions.  You learned almost all the data binding syntax.  You learned how to create custom elements, how to do routing,  all these sorts of things already.  So you just got a little bit more incremental learning to do as needed when you build apps.  So hopefully I will see you out there in our community building apps.  You can jump in the Gitter channel.  Like I said, there's about almost 1,500 developers in there  asking questions and helping each other.  So you can get assistance there.  We'd love for you to contribute to the project.  We have a lot of community members writing plugins,  contributing bug fixes and features,  and just playing an active role in the community.  So we invite you into that.  We invite you to build apps.  Please, if you're building things, let me know.  I love to hear your stories.  I want to hear your challenges.  I want to hear all about that.  As I mentioned, it's open source, but it's backed by business.  And so we really care about you as our customers,  and we want to make sure that you're able to do what you need to do,  and we want to serve you in that way.  So thank you very much for being here this morning.  Please check out Aurelia,  and I look forward to talking with you more soon.  Thank you.  APPLAUSE  Also, there's some stickers here.  I don't have very many left,  but I'm going to toss them down here on this step.  If the front row gets dibs, I guess.  There's really only a few left, sorry.  APPLAUSE  APPLAUSE
Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_0_767.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_768_5483.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_5484_7067.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_7068_7211.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_7212_14939.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_14940_19643.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_19644_29063.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_29064_29183.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_29184_36731.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_36732_36791.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_36792_49631.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_49632_50555.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_50556_50735.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_50736_51275.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_51276_51323.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_51324_51431.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_51432_51503.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_51504_51599.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_51600_51707.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_51708_52067.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_52068_52259.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_52260_52931.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_52932_54671.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_54672_54755.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_54756_55931.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_55932_56915.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_56916_57311.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_57312_59747.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_59748_59795.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_59796_59867.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_59868_60419.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_60420_60575.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_60576_62243.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_62244_66839.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_66840_67403.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_67404_67487.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_67488_67619.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_67620_67763.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_67764_68027.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_68028_68099.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_68100_68183.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_68184_68663.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_68664_68723.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_68724_69047.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_69048_69119.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_69120_69203.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_69204_70079.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_70080_70127.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_70128_70187.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_70188_70247.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_70248_70295.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_70296_70355.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_70356_70655.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_70656_70727.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_70728_70883.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_70884_71387.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_71388_72971.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_72972_73427.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_73428_73475.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_73476_73523.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_73524_73571.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_73572_73883.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_73884_73991.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_73992_74231.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_74232_74963.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_74964_75167.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_75168_75275.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_75276_75323.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_75324_77327.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_77328_77399.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_77400_77447.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_77448_77507.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_77508_77579.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_77580_80087.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_80088_89447.png Aurelia__Next_Generation_Web_Apps_-_Rob_Eisenberg_89448_91797.png