 Thank you, Adam. I actually wonder how many people here actually know what Roosevelt Island is. It's not nearly as popular as the Upper East Side. Really? Wow, that was way more hands. Geography nuts. This is crazy. So, good morning. I'm going to be talking to you about amber components and potentially singing, but I don't know how many of you have attempted to karaoke with me. Probably a lot of you, depending on if you lived in New York. So I'm gonna try to move this So before I get started, I am John Paul. I work at a company called Penton. If you all lived in New York, I would try to hire all of you. I might do it anyway. I run a meet-up in New York called NYC HTML5. If you lived in New York, I would make you all speak there. Be careful. I do a lot of this forcing of people to do things. I love JavaScript a lot. I have indiscretions and dalliances and other cool languages, but I always come back to JavaScript. I love being able to build things that my family can actually see in a browser and play around with. I, well, I was going to say, I just tweeted my slides. So, there we go. That's what I was, you know, it was originally delayed. I said, hold on, hold on, give me a second. It was to write that tweet. It was to compose that beautiful tweet that says, here are my slides. That's all it says, but that's what I was doing back there and I obviously messed that up. So, I want to talk to you about the evolution of my own path through the JavaScript library scene. I'm going to give you an arbitrary spectrum here. You can disagree or agree that this is a valid spectrum and there are many, many more of these in the world. This is just my own history from, you know, I don't know, I don't know whatever the species is of orangutan. Understandably, this is not how evolution works. So, give me the scientific pass up to Homo Brake Dancia or something like that. I started off years ago with a particular JavaScript library that I really, really enjoyed and I still do but I can't really tell a lot of people this without being a little awkward about it. I loved prototype. It taught me a few things. It taught me how to make sure that you use position absolute when you use slides so, you know, it matches up when you care about resolution. But I loved prototype. It gave me so much with respect to actually being able to understand how to do things in the DOM because at the time, not particularly a very well-taught programmer did not know all he should do or couldn't do prototype bashing over all of the built-in JavaScript objects to extend them. Wow, that's so cool. I can do so much. I was able to interact with the DOM, write animations. I still probably know the Scriptaculus. How many of you have ever used Scriptaculus? Okay, cool. I wonder what that percentage will go on in the next five or ten years. Scriptaculus is prototype JS's animation library. I still have that memorized more so than I know the jQuery animate, which is the easiest thing on the face of the earth. So I love prototype. Prototype was great. Eventually, something came along called jQuery. jQuery became ubiquitous. jQuery gave us all a very easy way to talk about the same kinds of APIs, the same kinds of interactions with the DOM. We all knew what $.aJAX was after a while. I'm actually sort of ashamed to admit this, but I at one time refused to rewrite my application in jQuery because I thought, no, no, no, prototype, it has it all. Why do you want to change this to something new no one's ever heard of before? Little did I know I was on the wrong bandwagon in 2007 and a half or 2008. I don't remember the exact year. Eventually, everything did get written into jQuery. And looking back, what happened to me was prototype was a way to communicate. jQuery was just a much better and more understood and more popular way to communicate about what you need to do in the DOM. But eventually, all these great things that I was able to do with jQuery that I could have figured out how to do in a cross browser way, or I could have used prototype to make me do the jQuery carousels out there and the grids and the galleries and all of these other things. jQuery gave me a lot. Initially, on my particular spectrum, on my particular evolution through JavaScript came along what we're all here and what we all probably understand a little bit because we're sitting in these chairs, backbone. So backbone for me gave me the ability to look at all of the pretty buggy attempts at organization in jQuery world that I made on my own because I've tried to make something like backbone collections. I've tried to make something like backbone models. I've tried to make something like modules of JavaScript files and all of these things on my own with lots of script tags that I eventually named to be things that try to make sense in my head. All of this was very difficult, very buggy, but I was able to pull it off to some extent. Backbone came in and wiped out that entire class of problems for me. It gave me organization where on my own I could probably do it but I could probably do it with a lot of bugs. So I was successful at that time. I learned backbone. I really actually enjoyed working with backbone, still use it in some places, but then years or so, maybe a year and a half later, it's hard because thinking about this, it seems like this whole thing is on the order of decades but with the speed of how fast the JavaScript community is going, this can be on the order of six months but it feels like we've been through long-term battles with these kinds of things. So backbone came along, solved whole class of problems with jQuery, gave me the ability to organize my thoughts in a way that was communicable to all my other team members, to all the people who are sitting here, but again, something else came along, the JavaScript landscape, that made me say, again, I've done all of these things with bugs because I tried to do it right. I want someone else to take care of those problems. Came along Angular. And at the time, again, I really liked Angular. Angular solved another different whole class of problems for me. It gave me the ability to map sub-views on a page at the same time, although their particular solution to this called ngView was not particularly easy. It gave me a much more robust system of managing routes and route handlers and history that backbone does, although it is pretty problematic. Eventually you introduce your own bugs because you're doing things you don't necessarily want to be doing. So Angular, again, came along, solved the whole class of problems, gave me primitives for things that backbone doesn't have at all, for example, two-way binding. Two-way binding is something you could do on your own with backbone on your own, with backbone and knockout, with backbone and everything else. But again, all of those integrations that I've had to do, I've done successfully, although, again, with bugs. I'm obviously showing a bent here in my particular opinion about how software that I enjoy developing happens to work. I like the opinionated. I like being told that crazy thing you did because you like to over-engineer things, John Paul. It was good. It was okay. You did it with bugs. Here, just give me... This is the solution for you. We'll fix all of these bugs for you. And we will give you primitives to do all of the complicated things that you used to have to do on your own that you felt pretty damn good for being able to do. But really, that shouldn't be your problem. So again, on my evolutionary chain, my current homo-break-dance-ia, pardon the name that I can come up with for this particular picture, came along Ember. So Ember, for me, again, did exactly the same thing as Angular for backbone and backbone for jQuery. It took away a huge swath of problems that I had with Angular applications and said, no, no, no, no, you don't have to write that anymore. Here, I will give you a primitive for it. And I don't expect that this is necessarily the last step along this particular evolution. I don't know where we will end up one day. But right now, Ember has solved for me many of these problems because it gives me primitives for really, really complicated things. It's given me, most importantly, primitives for being able to understand how a particular route, a particular URL that comes through in the browser, needs to somehow make up a page with lots of different sub-views, all of which data needs to be managed in one place because the amount of times, both in Angular and in backbone, I have tried to make large applications where you look at a page and you need 15 different models, all of this is managed by primitives in Ember. And that really, really helps me. One day, maybe this will be React, maybe this will be something else, maybe this will be some fancy vegetable like broccoli or cauliflower that everyone thinks are really cool right now. So I don't know what it will be, but right now, for me, I love Ember. Ember makes my brain happy to be able to actually be writing code in this. So I want to show you a typical example. I love how this is the biggest, I think, slides I've ever been in my life. This is like nine times my height. This is great. So I have an example for you. This is the typical example of Ember and Angular and Knockout and lots and lots of different things, and this is what it shows you. Am I zooming in? Yes, okay. I have a text box. I have some text displayed. I'm now going to type into this text box. Whoa! I brought you all mana from heaven right there. Whoa, two-way buy. This is everyone's demo, and it's everywhere. And realistically, it's very cool. I will admit it is very cool, but it is the least of the interesting things that you can do with any framework on Earth. But look at the updates. That's so cool. So it is pretty cool. Look at how much HTML this takes and how much a JavaScript is interesting. So Ember uses Handlebars. It's a templating library that spits out HTML eventually. And for all of this demo, I didn't actually need to write a single line of JavaScript. That'll be a trend I'd like you to think about as we go through this talk. All I had to do was write these particular special things called Handlebars things. And with these two pieces of Handlebars that look sort of like HTML, sort of not, and don't you love that beautiful BR? Man, I have to admit, I used the BR and position absolute in this talk. That's horrible. Why do you deal with me? I'm sorry. So this is the typical example, but this is not the interesting one. So here is... Yes. So this is... And in case you do have Wi-Fi, by the way, you can follow along these slides because I tweeted them. The interactive examples do work. So this is a picture... There's a great blog post by Thoughtbot that describes all of the primitives of Ember to you within the context of Rails. So this is just a particular image from that blog post. If you view the source of this, you can click on it. What this is describing for you is the primitives that Ember gives you that other frameworks either do or give you in a different way or don't give you at all. So in this case, there is a browser, which of course all of these frameworks happen to have because there's no choice about it. The browser visits a URL. That URL in Ember jargon produces something using their routing system called a route. A route happens to know because of the API it gives you and the code you write how to load a model or set of models for a particular route to say, when you go to slash user slash one, I need the profile info and the email preferences and the whatever else happens to be on that page. That model knows what controller it needs to load for that page and sets the data in the right places. And that controller then sets state on a template. So this is the, and the template is actually what's displayed to you within the browser for a user to actually see. Many of these primitives map somewhat to something within the backbone world. So the route, there is actually a router within backbone. It does some very different things. The router and the controller are sort of the same thing depending on how pedantically you want to think about what MVC is. The model backbone itself has a model system and collection system. But the one key thing that's very different from this picture, than anything that you can draw with backbone by itself, although there are many frameworks on top of backbone that we will hear about during this conference, that change that is the template layer. So the template layer in Ember is unbelievably powerful for what it is. Because it does the one thing that it's pretty difficult to pull off by mixing and matching outside of backbone. You can take your own, you can write your own template layer and everything like that. But what it is here completely built separately is does not nearly match the power of what Ember templates allow you to do within the Ember system. And one of those very powerful things to get to probably the closest to a big data-like conversation, because this is the best buzzword I can use for my particular industry, is web components. So web components is a group of specifications that are going to be started. Many browsers have already implemented this. You can take a look at HTML5 rocks as well as many. You can Google around for web components. There's a lot of very interesting things out there. What web components will allow us to do, and in some cases already do, is create your own reusable widgets. They are ways to, outside of Ember or backbone or anything, they are ways to encapsulate HTML, CSS, and JavaScript that are completely given to you by the browsers itself. It's a web standard specification that eventually we will all have the ability to use in all of the different browsers. That's not something that we necessarily have right now, but we're getting there, and Ember allows us to get pretty close. Web components consist of four different sub specifications. One of them is custom elements. One of them is templates, which is key to this. One of them is HTML imports, and one is Shadow DOM. Tomorrow there is a talk about web components. I really encourage you to single track conference so you really have no choice, but you will learn a lot more tomorrow when you actually go through this, especially as to how it works with backbone, which I'm very interested in because I do not know. Web components are made up of these four pieces. Custom elements and templates are things you can probably map into your head as to what they mean, even if you've never heard of this stuff before. HTML imports and Shadow DOM are a little bit more complicated, a little bit more interesting, depending on how much of this you know, but what Ember allows you to do is take two of these, the more important two, in my opinion, and it lets them roll your own. So you can roll your own using Ember right now, and the reason this slide is here is half because I'm going to be letting you all out to lunch, so I hope you're starting the palette. I hope that this slide is coming, because it's all there. But you get to using Ember. You can roll your own web components, at least pretty close. What Ember components give you, that Ember components also give you, are custom elements and templates. Using Ember components, which is one of the systems within the template piece that I showed earlier, you can define your own, what looks like handlebars templates, that happen to have a lot of that encapsulation of actual functionality within them, and you can write little pieces of HTML that you want to be usable in other places, in your application. So Ember components are handlebars, how many of you have used handlebars or mustache or anything like that? Okay, that's pretty much everyone. Handlebars are partials with a lot of extra power. What's interesting here is that handlebars' partials, by themselves, don't actually include any JavaScript, which is great, and we'll get to that a little later. So they are reusable pieces of, in this particular case, handlebars, not HTML, like web components will be, but handlebars and HTML are pretty analogous. It is completely reusable. Each of these particular pieces of template only know what's passed into them, like a handlebars partial is, that many of you have probably used. Ember components have a very specific and well-defined interface. So compared to other mechanisms to do very similar things in, for example, Angular, the Ember component system is very, very restricted and says you're only allowed to use these particular properties that you have access to, and I'll show you that in a second. So what is a partial? A partial, I think, most of you raised your hand for this, particularly so worried. A partial is in every templating language known to man, ERB, JSP, PHP, the language itself, has some ability to say, I am way too lazy to copy and paste. And I don't want to do this copy and pasting thing, because control V, it's just too complicated. Let me give me some way to have a file somewhere else and basically do the copy and pasting for me. This is an example sitting in the Ember docs where you can take a partial, you're using this particular syntax here, you can copy paste whatever is in this other template. The Ember convention is to name templates with underscore, you don't have to actually worry about that, and it will be copied and pasted here. This is the most simple case of a partial, it just lets you copy paste one piece of template into another. So this is an example of something called a component. A component here happens to be within Ember, just a handlebars template that happens to have the name component slash in the name. What this does, when I currently, I'm showing some code that iterates through some blog posts, it actually invokes that very similar thing to handlebars partial called an Ember component. And here I have some HTML that displays my lower mipsum and the word blog post. So here, writing absolutely no JavaScript, I have something called an Ember component that doesn't seem particularly special yet, that using these two templates sitting in HTML, I can generate multiple pieces of the same HTML. So this is just like that copy pasting use case, because we are lazy. But handlebars partials don't have a lot of the power when it comes to what can actually happen when you invoke them. And what that means is a handlebars partial, sorry, an Ember component has the ability to within it pass specific parameters, just like how a web component will be able to do at that time. It will be able to say, here is my own custom image tag, here is the source for it. So go download those bytes of data or something like that. Here, this particular handlebars component called blog post can have a title. That title can be updated just as magically and Boston is cold. So all of this just works. I have the ability to within this what's called a component template, update my own HTML, have this particular yield keyword, gives the power to add things inside of your handlebars component. And all of this I can keep updated across all of the different blog posts that I might have just by using this one piece of HTML and invoking it using this syntax. All of this I have with absolutely no JavaScript written. The existence of this particular script tag sitting there somewhere in the Ember ecosystem triggers to Ember saying, we have this thing that's called a component. It means that he wants to reuse it across multiple places. I will set up this special scope for it and Ember gives you the ability to actually call it in different places. All of this happens and all of this updating happens with absolutely no JavaScript code at all. So I've not really shown you that many interesting things so far. You can figure out how to do this. You can figure out how to make the way to copy and paste templates in Backbone or Angular anywhere else. It's not particularly that complicated. But there was a time in which I felt that's pretty much all this is good for. But there's one particular case that I was completely enamored with that completely changed my opinion of how I can use Ember to help my life. Also, this is obligatory animated GIF. I have to have one. This is what got me hooked. I don't know how many of you are in this category, but pretty much every job I have ever had at some point I have had to do this. What I'm going to call this is something called dependent select fields. Copyright pending. So be careful if you use this. I have lawyers. It is a way to express when I change the value of one select box you have different values in the other select box. And I meant to go look up the provinces. I'm sorry. I'm closer to Canada now than New York, so I feel bad for this. But I don't know anymore. So every single... I've had to make this thing over the course of my career, at least 100 times. Users and roles or industry and job function. I always have to make this exact same thing. And I've done it in jQuery. I've done it in Backbone. Very similar to jQuery. I've done this in Angular. And every time I've had to redo this, and it's very, very similar because it's exactly one select box that has particular options and values, and it's a very, very well-defined thing. But it doesn't happen to be something that's as popular to take out of the boxes as a jQuery plugin, or like Bootstrap doesn't have something like this sitting there. So what Ember allows you to do is create something that is completely reusable that I've here called dependent select fields, trademark, where I can specify using this data structure that I have defined here called country options. And once I've specified that, I can use this particular interface, this component, that's what this is, and this does have a few lines of JavaScript with it as well, but it is mostly the template that is shown below. Using this particular piece of reusable public API, I can have 150 different dependent select fields in my application. It doesn't actually matter. I can use this wherever I want to. I don't have to change anything. I can style this however I want to. Customizations are not necessary on a per instance basis. And I just wrote this once and was able to use this everywhere. This is as close as I've ever felt to the goals of what web components will be that you'll learn a lot more about tomorrow. This is, for me, the most exciting thing about this. I was able to write something just like a function in terms of reusability in JavaScript. We're all looking to extract wherever we can. Don't repeat yourself. This is the perfect don't repeat yourself moment. And this particular piece of all of what Ember components are got me really interested in seeing where else I can find these things. Where can I decompose my current crazy pieces of HTML and CSS and my position absolutes and all these other bad things into well-defined pieces that I can put in multiple places in my applications? This is just one example of many. This happens to be one you can't use because of legal issues, but there are going to be a few more. Another one of these is called Ember tabs. I did not make this. Ryan Florence happened to make this. I made a bit.ly URL out of it though because that's the cool thing to do when you see something cool. Ember allows you to make something that's very similar to Bootstrap tabs here with, again, a very well-defined public interface. You could do this with something like Bootstrap. With Bootstrap, you would have to remember that you need to use divs here and divs there and you need to remember to use these classes at these times for if it is active or not active and all of this. You can use Ember. You can create a DSL that's very similar to that that is much more expressive because it doesn't depend on what classes you have or anything about your CSS. You can do anything that you want in there. It's a much nicer way of expressing what Bootstrap tries to do or what jQuery plugins try to do without all of the cruft of having to understand every piece of what's in your actual resultant HTML. So here's another one of these where I get to bring up the ooh-ah piece again, but all of this in terms of HTML is right here. Very similar to the blog post example. I have one piece of handlebars template called a component, one piece of handlebars template where I use that component called ColorBox. So now I'm going to do my third or fourth horrible thing that you should never actually do in production code, and I'm going to change the presentation based on JavaScript. So here I'm removing a comment, and now I have the ability to, in about three lines, three total lines, maybe. The spacing here makes this hard to count so I don't know how pedantic to be, but I can very easily just change all of this to green or yellow or do I know not primary colors? That's fuchsia. I cannot spell fuchsia. That's not right. Okay, well, there is a color called fuchsia, and I promise you all it would work. I promise you. Okay. Magenta. That's fine. It's fine. You believe me. Just believe me. Okay. Thank you. Okay. So this is just, I'm wary of this because I didn't actually set a timer in the beginning, but I think I'm okay. So I've shown you a few examples. Some of them are really boring. Some of them are so cool, like that color box thing. You're going to tell all your friends. I have, so this was maybe about a year ago when I thought this was all really interesting and totally going to change my life. I made a component list. Eric Berry, who's a great, great guy in the Ember community, he also made a component list. And I was hoping like one day there'll be more and more component lists. So here's some component lists, but so how many of you have ever used JSP tag libraries? Okay. I saw someone with a very happy face when they said that, but most do not have happy faces when they think about that. So I was at one time a Java person. You can take for that what you will. And I enjoyed actually in some senses using something in the Java world called tag libraries, which is a way to, using their dependency management system just download the ability to add new tags. And a very similar way to what web components will be except based completely on Java and Java serverless and things like that. So about somewhere around a year ago I actually said at the Ember conference that I hope one day that there will be sort of this equivalent for the Ember community. Because I can go to one of these lists and you can go to one of these lists and you can go through and you can say you love color box and you can copy and paste this thing into your application. And you can go then, you can copy and paste all of this into your application. And that's great. And that works. You get to use my code and it is, don't worry, this will be liberally licensed, not like the name. And you'll be able to use that code and it will be great. But then eventually I'll update it and I'll fix something. And how are you going to do this? You're going to copy and paste it back into your application? This is sort of what we're used to in some senses because at least in terms of script tags with as much dependency management as the Rails Asset Pipeline or something like that will give you, we're used to things like this. But I was really looking for that JSP tag library ideal which allows you to just say like, install this. Because I really, really love things that are completely out of the box. And for me, not only is this my obligatory catgif of the presentation, but it really makes me feel like I live in this ecosystem which again brings me back to what I was talking about earlier. I like systems that give you everything A to Z, tell me exactly what to do. And now, about a year after I originally thought about that and didn't actually do anything about it by the way, so I had to take no credit for this whatsoever. There exists something called Ember CLI. So Ember CLI happens to be the Rails command line tool equivalent for what is in, what happens within the beginning to the end from creation of a project all the way through production of an Ember application. So there are some things like this in Backbone world. There are some things like this in Rails world. This one is the canonical one for Ember that allows you to do many, many things like generate a template just by the command line. It'll do code generation for you. It will package up all of your code and using the new ECMAScript 6 module system but it will compile all of that to one bundle that you can actually deploy to production. It does a lot of things which you might or might not like as you know I do but it has one particular feature that's really great which is the ability to distribute using NPM Ember components. So there's actually a whole website here that you can go through and look and see it's called Ember add-ons. Using the Ember CLI system that happens to be the way you're developing an Ember application you can just install some of these things. So not only can we get away with a lot of these examples without any JavaScript at all now we're even more out of the box and saying you can get away with some of these things by just typing a command at your command line and it just appears. So if you wanted my dependent select fields and you paid me the right fees for it you could one day have this yourself. So an example of this and some things that I've done again on my own with bugs I get to say I get to take off the shelf from other people that have made similar things. This is an example called Ember YouTube. So YouTube has an iframe API it allows you to using an iframe and particular parameters on that iframe you can say I wanted with the play button I want to do I want to allow this and not allow that and copy paste the URL with the time in it YouTube has lots of different options. All of these things I don't want to actually learn. So what can I do if I want this in my Ember application I could go learn that YouTube API and I could actually type the YouTube API into a template somewhere in my files or I could let an Ember component take care of a lot of that for me and give me a very small well-defined interface this is about six things that aren't debugging and I can do that now using npm. So with this if you're using Ember CLI which is this tool that does a lot for you you can npm install Ember YouTube and suddenly wherever you use in your application it knows what this component is called Ember YouTube just like how I use dependent select fields earlier or color box or blog post from earlier examples your application just knows you don't have to go wire that up in a script tag you don't have to go find anywhere else where this should be going you npm install it you run your application and if you have this code there it'll spit out the iframe this is one of the amazing ideals of all of this similarly and I know this is going to extremely impact all of our lives on a daily basis because I'm sure you've all implemented infinite scroll a dozen times at least I hope so maybe that's going away you can just npm install infinite scroll it gives you some view that you can put somewhere that has a particular well-defined interface that says you have to have a has more property you have to have a model that's an array that's a list of things and you have to implement this in this particular way but if you do infinite scroll is out of the box never have to deal with how far have you scrolled from the document viewport top again that's something that annoys you it annoys the hell out of me because I've done it a thousand times so we have sort of we have gone from I have at least from the days of prototype gone all the way through from every possible thing is roll my own to wow I've rolled a lot of really bad things to I'm going to roll a little bit less on my own now oh man I did it again I rolled really bad things and this is going to keep happening this might happen again and I hope this keeps happening because one day we always we're always striving to get to the ideal tools and whether or not we get there this is very shoot for the stars and hit the clouds kind of thing I'm feeling really good about all of this so Ember components have some great features and all of them allow me to do my job much easier on a daily daily basis so they so I know this animated GIF thing is sort of my thing right now but this creepy heart GIF really shows to all of you how I feel about all of this this is the creepiest heart GIF I could ever find on the internet again freely licensed publicly so the so Ember components give me all of these things often times with little or no JavaScript at all just because of how well this API was put together to address all of my use cases I really want all of you so whether or not you know Ember very well or not Ember components is probably one of the smallest and easiest bites to chew with respect to learning it because you don't even have to know the JavaScript API at all to be able to start playing around with it I want all of you to be thinking about maybe go try a demo with this see what Ember is like there are lots of actually integrations out there with backbone and Ember some of them are more difficult to wrap your head around than others but this kind of development whether or not you're using Ember but thinking about how all of the bugs you might have might not be bugs you need to have anymore is a very very useful thing to think about as an engineer on a daily basis and for me every time I achieve one more rung on that ladder I get really excited about it so I can't wait till next year when I come back to this or other conferences and see how much more we have progressed as a community we're already having web components web components are already implemented to some extent and some browsers we continually get better we continually make our lives easier and we continually make our users experiences better and I love all of that we're just all along for the ride so thank you so much Adam Backboneconf appreciate it Boku thanks a lot