I have basically two things I could talk about. I could talk about big picture web stuff, and I could talk about Ember, but I have an hour, so I figure I could talk about both of those things. And in particular, what I wanna do is I wanna give you sort of my thinking about the big picture, and obviously, since Ember is what I do as a practitioner, Embers is what I build, you can sort of get a sense for how I think about the web and programming from some of how I'm gonna be talking about Ember. And Ember in particular is a relatively new phenomenon. People have been building web frameworks for years, for a decade or two decades. So I sort of wanna talk today about Ember in the context of today's web framework, so that's things like Angular and React, Backbone, Aurelia, all the frameworks you'll be hearing about later today. But before I can talk about what Ember and what these frameworks are doing today, I want to rewind a little bit. Actually, not that far, but it seems like a long time now. Actually, one of the things that I noticed when I started thinking about 2011, which is the same time that I started working on what would become Ember, is that if you think back to 2011, it's just four years ago, but the concept of a transpiler was really unusual, people didn't think about it. So if you watch people give talks about ES5, so ES5 had come out in 2009, and 2011 was when the second version of ES5 came out, and people were giving talks about it, and even in 2011, which is pretty recent, when people would talk about the new syntax, you would get the idea from them that, well, you can never get new syntax into browsers, because we're gonna have to support IE6 forever, so how are you gonna get new syntax? Libraries, those are easier, you could polyfill a library, you could polyfill for each, but how do you get syntax into the browser? People didn't have a clear sense of how you would do that, and in today, in 2015, the answer is obvious, the answer is transpilers, and transpilers have really done a lot to change the shape of what it means to add new syntax, add new features to the browser, but they're actually a really, really new phenomenon. So if you go back to 2011, sort of the dominant frameworks at the time were things like Sproutcore, Cappuccino, EXTJS, Censha had just come out, and all these frameworks were trying to do one thing, which was they were trying to say, we need to abstract the web. They took the idea that the web is fundamentally broken as an abstraction, the DOM is broken, you've heard these things over and over again, and so what we need to do to build a good web framework is we need to abstract away the web, and I was working on Rails at the time, so I sort of did some jQuery work, but I had spent the last couple of years before this working on Rails, and I really had come to like the web technologies, I'd really come to like HTML, and I'd really come to like CSS as crazy as that might sound. In large part, just because those are the things that are the lingua franca of the web, those are the things that anybody you're gonna work with knows how to work with, and they're things that really evolved to be a really good fit for what the web was actually doing, so I sort of finished working on Rails 3, took a look at the front end story, and I said, I don't really like the fact that all these frameworks are trying to abstract away the web, I really want a solution that more embraces the things that are good about the web, and so the very first thing that I did when I finished working on Rails is I built the templating engine called Handlebars. How many people have used Handlebars? Yeah, a lot of people, awesome, that's great. So originally, I wasn't very ambitious about Handlebars, my main goal was just to build a templating engine that would be fast, and a templating engine that was not like mustache, very, very constrained, but not like a lot of the other templating engines that existed at the time, basically Wild West, you could just type whatever JavaScript you wanted in there, because I had in my mind the idea that what I wanted to do was to support some kind of data binding system, and I didn't know what I was gonna do yet, but I wanted to support it, so I sort of built a templating engine with that in mind, and sort of my philosophy at the time was that HTML and CSS are okay. That doesn't mean that HTML and CSS are the best technologies that anybody has ever built, it doesn't mean that you should go around professing your love for HTML and CSS, but it means that HTML and CSS are what we have, and over and over again, you hear what we really need to do is we need to take the web, and we need to start over and build just the good parts of the web without the bad parts, and I want to say I don't think that's the right approach, and the reason I don't think that's the right approach is that I think evolution, both the human kind and the technical kind that we build, I think is a much better solution for advancing the things that we want to advance, and typically when you start talking about this, when you start saying, well, I think we can evolve our way from where we are today into a better place, you hear a bunch of objections. Probably the most common objection is you hear people say things like, well, HTML was designed as a document transport, and HTTP was designed as a way of sending documents, and it wasn't originally designed for applications, so because it wasn't originally designed for applications, we need to start over and build something that was originally designed for those things, and I don't agree with that. The reason I don't agree with that is I think, if you look at, this is our ancestor, our first ancestor, it's a single-celled organism, and certainly this single-celled organism was not designed for programming, but I don't think anybody would suggest that we should go back and start and build a new human from scratch because the original design was not optimized for the thing that we're doing with it. Sometimes you have to take the good with the bad, right? Sometimes evolution gets us a lot of things that we like, a lot of things that are good, and together with evolution, we get the appendix, and we get tonsils and a bunch of other things that maybe we don't need, but it's really expensive to go back and start over. So I wanna start by talking about the good, what's good about the web. So first of all, the web is ubiquitous, it's everywhere, and it's not a small project to build another thing that's everywhere. So everywhere doesn't just mean it's on my computer, it means it's on mobile devices, it's on embedded devices, it's in my Wii, it's in my PlayStation, it's everywhere, literally everywhere. It's viral, it's really easy to take whatever you're looking at, if you're looking at a piece of content, it's really easy to take it and share it, and that doesn't just mean share it on AOL in 1999 or Facebook today, it means any place where you could put a piece of text, I can take the thing that I'm looking at and give it to you, and that's something that has been true from the beginning, from Tim Berners-Lee's original idea for the web, it's been true from then until now, and I would imagine that it would be true for a very long time. And that's really a powerful thing, it means that it's really hard for someone to take control and say you have to do all you're sharing through me, because it's so easy to take a piece of content and share it with anybody that lets you paste in text, which is basically everybody. It's also not a system that's owned, right? So many, many platforms that people try to replace the web with are owned in some way or another. You have to get permission to publish, and that doesn't always mean you have to knock on somebody's door or pay somebody to publish, although sometimes it means that. Sometimes it just means that there's a censorship system in place, it may be a really benign censorship system, like it has to be family-friendly or something like that, right? But in many, many platforms, you don't have the freedom to just publish largely whatever you want, the system is owned by somebody. It's also cross-platform, and when I say cross-platform, I don't mean like the way Flex was cross-platform, where you could take one thing and run it anywhere. I mean a very specific thing, which is that the web is cross-platform, but it has access to the native look and feel. So when you use a select box on the web, you actually get a thing that looks correct on iOS 6 and iOS 7. It looks correct on Android Gingerbread, and it looks correct on Android Lollipop. It looks correct on my desktop. It looks correct on Windows. It looks correct on Windows 10, right? And that's something that is very, very difficult to build. You can look at Flex, for example, Flex's select boxes. Flex's select box wasn't a bad select box. It was a pleasant enough select box, but the fact that it feels so different from the underlying platform makes you not want to use it, and it makes it difficult to say, you know, forget about HTML. I'm gonna draw my own select box with Canvas. The problem is that now you're drawing something that looks the same on all platforms, despite the fact that every platform has their own look and feel. Even things that are simple, like how scrolling works, if you're on an Android device, you probably experience this. If you're on an Android device and you go to a website that's emulating iOS scrolling, it feels really bad, right? And that's a really simple thing, like how do you emulate scrolling on a Canvas? So there's all these details, and cross-platform is correct. And this last one I know is gonna be controversial, but the web is the only platform that exists where people regularly run untrusted, unaudited, unknown code on any device that they happen to have. And you might say that that's a bad idea, but the reality is that any other platform in the world doesn't even come close to beginning to allow you to do this. And the web, for all of its positives and negatives on the security front, at least supports this use case. And it's a really important one that you can click on a link and not have to fear someone's gonna hack your computer. Okay, so what about the bad?  You can't display video. You can't compete with native performance. Wait, none of this is true. This is the stuff we said we were never gonna be able to fix in 2007, right? This is all the stuff that we said that the last time someone was cynical and pessimistic about the web, that's what they told you, right? But in reality, all these things, all the things on the previous slide we've dealt with, and we've dealt with them in a very evolutionary way. Admittedly, we did this in a largely additive way, but just because we added something doesn't mean that what's left over is not good. And in fact, one of the best ways of dealing with systems that are additive-only, and there's plenty of these, like x86 is an additive-only system, Unix is an additive-only system, C is an additive-only system, there's a lot of things that we build on that are really hard to take things away from. One of the really great things about, one of the best ways of dealing with additive-only systems is to create the good parts. To say, if you're writing JavaScript or if you're writing for the web today, you shouldn't use all the system, you should use part of the system. And in fact, the web has embraced this idea of the good parts with things like CSP, the content security policy, where you as a user could say, I do not want eval, for example, I do not want third-party scripts. You can say all these things, and maybe we don't have a big enough, we don't have a small enough subset yet for security, but we do have a mechanism of letting people opt into a smaller subset of saner JavaScript and saner web. So it's not really the case that we're stuck. So what I would say is that really the bad, whatever list of bad you're gonna write out in 2015, doesn't really matter because evolution is a really powerful force. And if you look at the last 10 years, if you look at how people felt 10 years ago, they felt like IE6 is gonna be around forever. We can't add more features to the platform because how do you get all the browsers to adopt them? Or we can never remove features, except Chrome removes features somehow. You look at the last 10 years and somehow all the things that people always say are intractable about the web, end up being perfectly tractable. And so what I would say is it's okay to be a web developer, it's okay to write code for the web that we have, it's okay to push for improving the web, and evolution is a very powerful force. It got us from the single-celled organism to a human programmer in admittedly many millions of years, but evolution is very powerful, especially when we're shaping it, and it's something that I think we've done a really good job at. If you look at the past 10 years, we've done amazing things, and I think we'll continue to do so. So that's sort of my feeling about the web. With that out of the way, I sort of wanna talk about applications. So I wanna talk about what it means to write a web application today. And a web application is actually a little bit of a different thing from sort of a native application. So native applications don't have any native way of sharing, so if I have an application, I'm looking at the New York Times on my phone, and I wanna share it with you, the usually the way people do it is they give you a URL to a website, because it's really hard to share native applications. And sort of the navigation model is usually very custom. It doesn't, there's no links, there's no going from page to page and things like that. And so the web model, whether it's a web application that was served on the server that you're navigating around with links, or whether it's one that's built on the client, I think is more than just a few widgets, more than just a couple of widgets. So I'm gonna take a look at the Heroku dashboard, which is an Ember app, to give you a sense of sort of how I think about it. What I think is an application. So what you can see here is that there's three big chunks of this application. There's the big outer area, which allows me to select between the tilde app and my personal apps. Then inside of that there's, once I've clicked on tilde, my own apps, I get another thing which lets me look at apps, access, resources, settings. And then inside of there, once I've clicked on apps, I get a list of my applications. So you can sort of think about how this is working, how an app works as being sort of a set of nested pages. So it's not one big page, that's the application. You have the application page and then nested inside of that as an organization and nested inside of that as the apps. You might even think about this, although you should not implement it this way, as a series of nested iframes. So every piece inside of that is another iframe that you might be navigating around. And sort of the interesting thing about the way these applications tend to work is if I go and I click on, if I go and click on something else like settings over here, what ends up happening is that some of the application stays the same. So the outer shell stays the same and the bar on top stays the same, but just the bottom part changes, the bottom part navigates away. And again, you could sort of imagine that there's iframes here. You've clicked on settings and what happened is you navigated the inner iframe to a new page. So now we have a different set of things. We have the application, we sell the organization, but now we have settings instead. So let me go back here. And then if I click on a completely different thing, you'll see that the application on the outer side is still the same. It still looks the same way as it looks before. But now that I've clicked on an individual app, I clicked up from the list on an individual app, we've changed a few things. We've changed the outer app and we've changed the inner resources. So the reason I'm showing you this is not necessarily to get you to be really familiar with the Heroku application, but to show you that an app has multiple pages, right? So a lot of people when they're looking at web frameworks, when they're looking at things like Ember and Angular and React and Aurelia, a lot of people are not building what I would consider necessarily an app. I would say that they might be building a single page. I don't mean single page app. I mean, they might be building a widget, right? So they might be building a really rich thing like the New York Times, for example, takes, builds interactive graphics. They have a whole team. The whole team's job is just to build interactive graphics. But every one of those interactive graphics, they may be really complicated and rich. They're not an application. There's no navigation. There's no URLs. There's just an interactivity. And that interactivity is great, but it's not really an application. So the first criteria for an application is that an application has multiple pages that you're navigating around. Interestingly, I think while it is the case that a lot of things are not applications, a lot of things that you might not think of as applications become applications quickly. A lot of things that you might not think of as having multiple pages end up with multiple pages very quickly. Also interestingly, pretty much in all applications that I've ever seen, these pages are somewhat nested. So you usually end up having a layout that represents sort of your entire application. And then inside of that, you might have the top-level navigation. And inside of that, you might have another level of navigation. And in the Heroku case, there's even navigation inside the next level. So there's all manner of navigation. And I think, and the user's navigating between these things. And I think this is, it's really interesting because the way traditionally people would make these kinds of applications is they would render all their content on the server. And the really awesome thing about rendering all the content on the server is that every time you click on a link and go to a new page, everything, all your state is blown away. So you could just basically do whatever you want. You could write whatever jQuery code you want. And as soon as you navigate to a new page, all your state is blown away and you get a whole new fresh state. And I say awesome because it means that you could do a lot of, you could do a lot of unscalable stuff. You could do a lot of sort of spaghetti code. And what you did on one page might not affect another page. And that's actually really great. That means that you could build up a really big complicated application and you may be able to avoid it becoming too complicated. And I think this is sort of a core principle of applications is that you wanna make sure that once you realize you have maybe 50 pages in your application or Skylight is a simple application and it has maybe like 15 pages. It's really important that each of these pages is conceptually separate from each other. And I like to say that once you realize that you have pages, you realize that there's a simple matter of bootstrapping which is not so simple at all. Figure out how to get the data that you need into each page. So it's really easy when you're taste testing a new framework, any framework in the world, it's really easy if you have one page to get the data into the one page.  And then if every single time you go to a new page, you blow away all the state and start over like in the server model, it's no problem. You just do exactly the same thing. You effectively use page loading as your signal to go get data and install the component. But when you stop wanting to pay the cost of going back to the server and downloading a whole bunch of new HTML and new JavaScript and executing it again, when you start wanting to use a framework to navigate which is what Ember tries to encourage, you need a different signal. The signal of the page load only happens one time. And so what you now need is some kind of mechanism, some kind of framework for dealing with, okay, I have now entered page X. Okay, now I've moved to page Y. So please tear down all the things from page X and do the stuff from page Y. And you would ideally like that to be as pleasant and as isolated and as sort of carefree as the code that you would have written on the server side. So what is Ember? What is the goal of Ember? From a high level, what Ember tries to do is Ember tries to give you a model of modeling these pages in a way that's isolated from each other. So we, of course, have a component model and I'll go into that in a little bit. But the thing that we do that I think we've spent the most time on by far is how you model the pages and the navigation and the user flows between these pages because it's really easy again if you're not thinking about multiple pages to get yourself into a pickle where you're trying to stuff everything that you ever have to do into the loaded signal or maybe you put all the logic into the code that actually you clicked on a link and maybe you put the logic for tearing down and setting up in that link. But what if you go to that same page? What if you go to page B from another location? All of a sudden, all that tear down code that you wrote stops working and all of a sudden you start leaking memory. So what Ember tries to do here is Ember tries to give you a model for thinking about the individual pages that you have in a way that's fairly isolated from each other. So we sort of give you a way to think about it. And I like to say that the trick to big applications, applications written at scale is isolation. And what I mean by isolation is that if I have an application like this and I go and I make a mess in apps, I do some messy code, I have a bad day or I hired an intern or any number of things bad can happen. Junior developer happens to be assigned to work on that page. Someone goes and makes a mess here. What I really would like is for that mess to not affect some other page or the nav bar on top or this other page and application. So what I like to say is that good isolation lets you write the kind of code that doesn't scale. So people know how to write jQuery and people know how to write CSS code. And the problem with writing jQuery and writing CSS is not that manipulating the DOM is necessarily fundamentally a broken paradigm. Some people like to say that. And in Ember, you tend to write a lot less jQuery than you would have written. But sometimes you need jQuery, sometimes you need D3, right? What good isolation lets you do is it lets you say, I can't figure out how to do this in the correct way. I don't have, my brain is not on today. I just want to bang out some code right now. And you could bang out that code with good isolation in a way that doesn't break the rest of the application. I think personally as a person who has good days and bad days, I find it rather exhausting to be writing code in paradigms that say you have to be perfect all the time. If you mess up anywhere, a good example of this would be BEM in CSS. So BEM is like a way of writing CSS such that nothing from here can ever break anything from there. But it means that you have to always do everything perfectly. You have to always do the job exactly right. And you can't use the techniques that you might have used when you were starting out as a web developer. And I think that sort of thing is just asking for you to fail ultimately. It's asking for you to get to a point with your application where enough people had enough bad days or enough people wrote code that wasn't the right thing that leaked into other areas and suddenly your entire application doesn't really make sense anymore. So what we like to do is we like to say that what you want to do is now that you've taken all these screens from the server and moved them to the client, what you want to do is you want to treat every single screen like its own separate app. Again, sort of like an iframe. And I want to be clear, I'm sort of talking about this from the point of view of Ember. Many other frameworks have some tool in the works, something that was inspired by Ember's router that allows you to use these same ideas in another framework. The thing that Ember has going for it on this stuff is that it's baked in, it's part of the main way that everyone does stuff. So if you go to Stack Overflow and say I want to know how to do some problem, everybody can assume that you're building an application with these ideas, which is really helpful. So again, so you want to treat every screen like its own apps, like its own iframe. And what I mean by that, what ends up happening is that Ember gives you a way to do structured bootstrapping. So in the same way that when you use jQuery, you can say when the page loads, I want to do this stuff. And that feels very structured when you have a single page, right? It gives you a way of describing how to do stuff at the right point in time. But it starts really falling apart when you have a lot of pages. Ember gives you sort of that same idea, the same setup and tear down hooks for these smaller pages. And so the way that that ends up working is that there are lifecycle hooks in the router. So every single page gets its own object called a route. And that route allows you to manage the lifecycle. What happens when you enter for the first time? What happens when you exit, et cetera? And one of the really nice things that came out of this, like really, really early on, is if you go to Heroku, the Heroku dashboard, and you just load the page, you'll see that there's a loading spinner. And pretty much everybody ever needs a loading spinner. A funny example of this is there's a private beta of an Ember app that I've been using recently called Canvas. It's really cool. It's by the Heroku guys actually who started their own company and they're using Ember again, which is great. I'm happy with that. And I was using it and I noticed that they had an error, which was a bug, but when that error happened, I just got a white screen and I pinged them and I said, hey, why don't you have an error page? Why don't you have a loading page? And I didn't have to tell them, why don't you figure out how to listen for the promise and when the promise gets rejected, why don't you go and update the DOM and blah, blah, blah. I was able to tell them why don't you, please put error.hbs in your directory and now you'll have an error page. And maybe that's not the perfect solution for every single application when your application gets big and successful, but just being able to say, at the beginning of a project when you're still in, banging out, bang it out mode, I wanna have a loading page, I wanna have an error page. This comes out of the idea of having the fact that you're actually building pages that have state that have a point where you're loading things asynchronously and when you're done loading asynchronously, this ends up being really powerful and fundamentally what this means in Ember again is that we assume that you're building an application and it's very easy to forget this because I think a lot of people compare Ember to other frameworks and if you compare Ember to another framework for the purpose of building a widget or a small component, I think you're gonna be pretty disappointed in Ember, but if you compare Ember to other frameworks for the purpose of building an application, I think you'll find that we get a lot of mileage out of the shared assumption that we're building an application with navigation and pages. So let me give you sort of a sense of what it means, what it looks like to load some content into a page. So again, this is gonna look pretty similar to what you might do with jQuery. So first of all, when you load a page, for the first time, there's a loading, you go into the loading state internally and what the loading state does is it goes and it puts a loading screen on the page like I showed before. If you make a file called loading.hbs, we'll put that on the screen and that's good. And the next thing that we do is we, there's a hook that we call into that says, hey, give me the model for this page. So every single page gets to have a main model that is powering it. And if that model is an error, so if you make an XHR and the XHR returned to 404 or something like that and it's an error, then Ember will put the error screen on the page. So you make an error.hbs and like I said, now the error screen is on the page and frankly any error screen is better than a white screen, right? Anything, it could say something has gone wrong. Please report an error and that's better than just seeing nothing, a white screen. So this is already pretty nice. You just have a single hook where you say, please go get this JSON and then we automatically transition into the loading screen. We transition into the error screen if some error happens. And then finally, when you're done, we say, okay, we now have loaded the models and we go and render a component.  So that's sort of the high-level idea but if you've ever, if you haven't used Ember but you've only heard of it or if you've only started using it a little bit, you might think, well, that's a very prescriptive way of doing things. That's a very opinionated way of doing things. What if what I want instead is to do something a little bit different? And this is something that I think historically Rails hasn't been that great at. Rails has gotten better over time but this is something that as a person who joined Rails originally to make this story better, it's something that I cared about from the beginning of Ember. So for example, let's say you don't actually want a loading screen or an error screen. What if you want to do something more custom? Well, no problem. The loading screen and the error screen are just the default implementations of the loading callback and the error callback. So you can implement a loading callback and error callback. You could report back to the server. You could do some direct DOM manipulation if that's what you want. Really whatever you want. And what about fetching models? So the default way of fetching models in Ember, if you're building a totally new app and you control the client and the server, you would use Ember data and JSON API. If you do that, that would be the easiest way. So if you ever use Rails with active record, it's sort of the same story. If you are willing to follow all the rules that we tell you, you're gonna have a great experience. But what if you can't? So for various reasons, sometimes Ember data isn't, or JSON API isn't exactly the right solution. So first of all, Ember data allows you to use other things. There's even adapters for things like Firebase and Paris and Couch TV, Mongo. But if you can't even use Ember data at all, because you're doing something really custom, Skylight actually has some examples of this, then the model hook is really, is just super generic. You can just get whatever JSON you want in there. So again, there's some really great solutions if you want to be opinionated and get something out quickly and you control the whole stack. But if you need to fall back, there's always layers of the onion. This is something that we care a lot about. So we know that we care a lot about making Ember really good and opinionated for cases where you just wanna forget about everything and get the job done. But we also know that in the real world, for all kinds of reasons, the exact thing that we decided isn't exactly the right thing. And so there's always a layer of the onion directly below the top layer and usually another layer below that you can dig into to still get something done without sort of punching a hole through the whole system.  It's usually a pretty structured hole. So what about components? So components have sort of gone through a historical story. So Ember 1.0 was the first release of Ember that ever had a component Ember. Before that we had a thing called views, which we inherited from Sproutcore. So Ember 1.0 I shipped a very small file called Component.js and it basically created a nice conventional story, subclass of views that did the right thing. And over the year after that, we learned a lot from Angular actually and we improved components to be both more conventional, more powerful and that was pretty great. And then sort of the year after that, so Ember 1.0 is closing in on two years. Sort of the second year has been an exploration of React. And so I think I'll talk more about this soon, but the basic thing that React has taught us in the component part, and it's important to note here that the component part is just like a little piece of the whole bootstrapping cycle in Ember. But in the component part of the system, what we sort of discovered is that unidirectional data flow, what we call an Ember data down and actions up instead of sort of bindings flying everywhere, that is a much easier way of thinking about things than the two way binding story that everyone used to do before. And so basically Ember has adopted just for our part, just for the V of MVC, right? So again, there's the V of MVC and then there's the rest of the system. But just for the V of MVC, we've sort of adopted that. Again, I'll go into that a little more. Before I say that, I just wanna say that I think it's really easy when you're getting started and you get this awesome component primitive. So when you're starting to learn any web framework, one of the first things that you learn is how to use components. And it's really tempting to say, oh well, I have a component and now I can make a parent component, now I have a bunch of children, now I make a parent component, all of that just keeps working. So surely the correct solution for building applications is that I just keep going up to the top and at some point I have my app component. But the problem with doing that is that all the stuff that I showed before about how you can manage life cycles, about how you wanna isolate pages from each other, how you wanna have a good structure for what pages even are, all that goes away if you try to model a whole thing as just a giant tree of components. Because some of those components are special, some of those components are the top of a page. And like I said before, the trick to scale I think, the trick to building an application with dozens of pages is to have the pages be really isolated from each other and to have a framework that helps you do that. So again, that's just sort of an aside just to say, I think components are awesome, I'm gonna spend the next few minutes talking about components, but I think it's important to not get too caught up into thinking that you just keep going and then you get to the app at the top, that there's more going on once you get to the page level.   So you can look at the function, you could see what the inputs are, you could see what it does, maybe they have side effects and usually if the function is sufficiently small, you can sort of understand what the side effects are. So by taking a really big program and breaking it up at the functions, you can understand more easily what each thing is doing and that's sort of the idea behind components. The idea behind components is that you take something that's bigger or repeated and you break it up into little pieces that you could reuse over and over again. So here's an example of a Twitter bootstrap button and they tell you what you need to type is, you know, button class equals and then a bunch of repetition type equals submit and you put the button in there. But what we really wanna type is this, we wanna type bootstrap button, close bootstrap button and that's it, that's what we wanna type. And Ember lets you type that and the implementation of this is very simple. So this is, you would make a file called bs-button.hbs and it would look like this. So all the repeated parts are the same and yield just means whatever was inside gets replaced. So whatever was between the opening and closing part gets smashed into that yield area. So that's a really simple example, but what if we have more kinds? What if we have Twitter bootstrap lets you have primary buttons and info buttons but you can see that there's a lot of the same stuff here. So you don't want to have to make a new bootstrap, a new component for every single one of these things because so much of it is the same. What we would like to be able to type is something like bs-button type equals primary and then if we leave off the type we want it to have a default which was the same default that we had before. And again, the implementation in Ember is pretty simple. You would make a bs-button.hbs and we would extend it a little bit. So we would still have the button and then we would say, okay, if we have a type attribute coming in, use it, otherwise use default and then we yield like we yielded before. So the basic idea of a component Ember is that you take something that was either repeated or part of a bigger program that you want to make smaller.  In the first example, the input was just whatever the content was. In the second example, the input also included a type and then you figure out how to represent that and then when you render the whole thing you get the right behavior.  And I'm not gonna deny I've used React and I've looked at a lot of React examples and I'm not gonna deny that there's a lot of benefits to that approach but I wanna talk about for a second the benefits that I see to the Ember approach of actually using templates. So here is a template and one of the things that I like about this template is that you can look at it and even if you don't really know handlebars that well or even if you don't really spend the time to really look at what's happening here you can get a basic sense of what the structure of this template is doing. And if we zoom in a little bit you can see that there's an each end we're looping over categories then we make a product category row and then we loop over the products that are inside of that and then we put a product row in there. And you can sort of look at this and get a sense of the structure without having to run any code in your head. I think for me it's really important that when you're looking at templates sometimes it's your designer but sometimes for me it's me with my designer hat on I'm looking at it and I don't really wanna be like running code in my head I just wanna look at it and get a sense for what it is that the structure is doing. There's one thing worth noting here so the big benefit that you're told of doing it the other way is that you don't is that you can sort of intersperse the code directly into the markup and then you can sort of compute values that you need on the fly. So in this case you can see that there's a little bit of a suspicious thing going on here which is that we're looping over categories but where are those categories coming from? If you were writing this code in React you would be computing them on the fly. So in Ember the way that this works is that there's a hook called did receive adders and what did receive adders does is it gets called any time the attributes change. So however the attributes change you get this hook gets called and what we do here is we just basically compute the categories that we need and we set them on ourselves. If you're familiar with React that set there is basically analogous to set state. So we're setting the categories on ourselves and then we have access to them in our template and I actually kind of think that it's nice that this data crunching part the part that says okay what are the categories anyway is in one place and then the structure is in another place. I think there's definitely benefits to both approaches but I think it's too quick to throw out the benefits of being able to look at a template and getting the structure. Just for comparison here's the imperative style and this is there again there are benefits here. You don't need a separate function to compute the categories but for me I look at this and it's not easy for me without running all this code in my head to figure out what the output looks like. If you look at the structure on the right side what you'll see is that it embeds some rows and in order to figure out what those rows are you need to actually go and run the code on the left side and figure out what's going on. And again there's benefits, there's costs and benefits, there are real wins to having things be just JavaScript quote unquote but I think there's costs as well and I think it would be good as an ecosystem for us to really think about these costs and benefits instead of taking it for granted that templates are sort of the old way. If I go back here you'll see that I think empirically is easier to understand the structure of than this guy. Okay, so that said I wanna talk about people often talk about React and they say well what React is good at is React has virtual DOM and I think basically everybody who's paying attention has said including the React guys like that's not really the thing, there's other important things and so for me there are really four things that are really good about what React does, things that React does in the V layer. So number one and these are all things that nobody did before so these are things that React genuinely innovated on, came up with as a new idea that nobody else was doing before. So first of all in a React component hierarchy there's always one component that conceptually owns the data and what that means is that there's not, it's not like there's a bunch of components that are all mutating some value and it sort of exists in the sky and it goes and updates everywhere, there's one component that owns the data so you can always think about where those changes are occurring. There's also one way data flow by default so of course you have to mutate things sometimes but the way that data normally flows is by sending data down and then you call callbacks that were passed up so in Ember we call that data down, actions up. The third point is really an important one which is sometimes it's really nice to be able to just say I don't really know exactly how this thing changed but the input changed somehow so I just want you to re-render the whole thing. That's actually quite often a nice thing to be able to do and it's something that you were able to do on the server side. It's something that basically all client-side frameworks were able to do but they were very slow at it so not just a little slow if you were to try to do that in Ember historically it would have been pathologically slow, it would have been painfully embarrassingly slow and React basically came up with a way of letting you say whenever something changes I want to refresh it and I'm gonna be smart at updating all these things quickly and then finally React provides a bunch of lifecycle hooks like the did receive adders hook that I showed in the previous slide and the important thing about these hooks is that they run no matter how the underlying data change so whether the data change because your flux store changed it or whether the data change because you change it manually your component hierarchy or whether the data change because someone above you changed the attributes these lifecycle hooks always fire and that's actually really important because it lets you not think a lot about how granularly things are propagating and just think more about well something happened to this component and now I can go and do whatever reaction I need to do which often is just running some JavaScript. So these are all awesome things and when we looked at them as a core team a few years or last year we were all really blown away by how elegant a lot of this was. So when we went to make glimmer components we wanted to adopt a lot of these ideas and so this is a duplicate of the previous slide glimmer components do all these things. Components own their own data there's one way data flow by default we support re-rendering in a way that's fast. It's a little bit of a different strategy but it ends up with the same result and your lifecycle hooks happen no matter how things change. Now because we, so that's a really great set of things about the view layer but because we assume that you're building a whole application we're able to make those changes to the view layer but leave the surrounding area all the nice things about how data gets loaded, how it gets into pages how pages get isolated, how navigation works we basically leave that stuff around your application and all that stuff continues to work and what's kind of cool about this is if you have heard about components in other frameworks components are often touted as a story of isolation so if you make a component it's isolated from other components and that's great and what Ember tries to do is Ember tries to say so there's components that are isolated from each other but then there's also pages that are isolated from each other so there's multiple layers of isolation so even if you accidentally somehow leak something in your component by doing something really crazy you have to do something even crazier to cause it to break another page so for example if I go and I work on my settings page if I do something to change an email and I break something there it's not gonna change totally different pages there's many layers of protection against going out and doing really crazy stuff and I think that's actually really great so sort of my last topic for today is this is sort of a controversial point but I think it's obviously true if you think about it that basically every web application that's at any scale if it's not like a tiny thing that is a widget like the New York Times widgets you end up doing some amount of processing so historically it was things like minification and concatenation but now it's things like transpilation, it's things like building manifests so that you can do cache busting it's things like automatically squishing your images down so that they don't end up being unnecessarily large if they can be losslessly compressed there's a whole bunch of stuff that you would like to do as part of the process of building an application and so a really good application is is basically compiled, a compiled output and one of the things that we did pretty early on with Ember is we created a tool called Ember CLI that basically takes, is the tool it's sort of like Xcode or the Android tools for basically taking your Ember application and converting it into something that you can use and it also does development so I made a little screencast here it's a couple of minutes I hope it's watchable from this distance I'll sort of narrate as I go but showing how this works so first of all we start off by you always build a new application by saying Ember new and the nice thing about this is that you get a scaffold that's basically built you're gonna see NPM and things run much faster than they should run that's because I cut them out or thought I did anyway that probably took like minutes in reality so we're installing some packages we're creating a new application this is basically handling a lot of the stuff it's giving you all the dependencies that you would normally need so we're installing packages here we're installing Bower right so we don't like Bower that much but a lot of stuff is still there and until we can transition so then after we've installed things I'm gonna go into the directory JSChannel and I'm gonna run Ember S and Ember S is basically a server if you use like Rails or Django or something like that it's just a server that runs in the background and you can see as soon as I boot I already have an application that says welcome to Ember JS and what I'm gonna do is I'm gonna open another tab here and I'm gonna go into the application and I'm gonna go into the template and I'm gonna make a little tweak to it and I'm gonna add a div class equals container here and I'm gonna change welcome to Ember JS to welcome to JSChannel and this automatically provides a library load server in the background so when I switch back you can see it is already updated automatically for you and now what I'm gonna do is I'm gonna generate a new route and that route is gonna be called index and index is just sort of the main page that you go to when you go to a new Ember application so I'm gonna go into JSChannel I'm gonna generate the index route and then I'm gonna go back here I'm gonna open the index route and I'm gonna change it to say hi, Amit there's probably several Amits in the room so you can guess which one I might be talking about so I'm gonna say hi Amit and I'm gonna save and again if I open this it has library loaded for me and it says hi Amit so that's great but what I really wanna do is get some data from the server I don't have a server here so I'm just gonna use set timeout to provide the data so I'm gonna return a new promise a new ember.rcp.promise if you don't know about promises it's pretty simple one thing you'll notice here is that I'm using ESX syntax and that's sort of built in when you build a new Ember app you get a translation for ESX syntax automatically and what I'm doing is I'm setting a timeout and I'm resolving the promise that I created with a new JSON object call it with name of Amit and this would be equivalent to if you would return a dollar that get JSON or something like that and I'm gonna change this so instead of saying hi Amit it now pulls the data off of the model so this is what I was talking about before where you can get an automatic flow that says when I entered index here is the model that I wanted to download but what you'll notice is that now it took a second to show the data but we don't want that we wanna show a loading page so what I'm gonna do is I'm gonna create a new page you'll see I called it loading.hbs and just by calling it loading.hbs we now have a loading page that shows up automatically without having to do anything else now I don't really like to look at this what I would like to do is I'd like to load I would like to add bootstrap so I'm gonna go to emberadons.com and look for bootstrap and you can see here that there's an addon called emberbootstrap but I'm gonna go to emberobserver which is a site that categorizes and scores a bunch of addons and I'm gonna go look at that emberbootstrap just to make sure it looks good so when I go to bootstrap there's a category I go look at it and I say okay it has a score of seven I go into that and you can see that someone has done things like check to make sure it's accessible and whatever score of seven seems fine so what I'm gonna do is I'm gonna go ember install ember-bootstrap hit enter it's gonna add it's gonna add it's gonna automatically cause it to get imported make it available the CSS available and everything like that and now if I restart the server and reload the page what's gonna happen is now it's gonna be using bootstrap which is great now what I wanna do just to show you that it's the real bootstrap it's the real deal is just add a couple of classes to the CSS so it's an alert of success and loading I'm gonna say it's an alert of info and if I load it what you'll see is that it says loading it says info so that's all great and really the point of that was not to necessarily give you a demo of how to build an ember app that wasn't really an ember app but actually there's a last thing which is that I'm gonna run ember build and ember build actually creates the thing that you could upload to S3 or something like that and I can go into the disk directory run a simple server now it's on port 8000 and it's exactly the same it's been built for production it has minified it has done all the things and that's pretty great so so you can see it's basically the exact same app as the one that was in the development server so that's pretty awesome and again the idea here is not necessarily to show you how to build an ember app that was a really boring ember app but more just to show you that there's a lot of things going on in the process of building a modern web application and having tools that sort of do it for you is really nice and this is something that we spent a lot of time on again because we're operating under the assumption that everyone building an ember app is building an application and not something where they're dropping it in where we have to basically sort of serve the common denominator every possible thing that anyone could be doing now one of the things I'm really proud of so we're now getting ready to ship ember 2.0 like in the next couple of weeks and one of the things I'm really proud of is our transition plan if you look at the road to ember 2.0 RFC which is so we have an RFC process where we basically ask for community feedback on effectively any interesting thing that happens in ember and so we announced this RFC in December 2014 so that was quite some time ago now and it got 253 comments which is a lot of comments and a lot of really good feedback that changed the plan actually because people our initial plan was perhaps too aggressive and then over time we published a lot of blog posts my favorite in the series is the transition to ember 2.0 in detail this we published in May and it basically goes through sort of now that we're really close what is the exact set of things that you're gonna have to do to transition your ember application so this is all just to say we care a lot about semantic version we care a lot about not breaking your applications and even though we shipped a totally new rendering engine the Glimmer rendering engine which is really much faster than the old one and it's totally new internals we were really careful to make sure that existing apps would continue to work we landed the Glimmer engine in 1.13 and it's compatible with existing applications using the public API so that was really exciting and I think people were happy with that now the JavaScript community loves Silver Bullets I think, I don't know if this joke will go over well with this audience but there's enough Silver Bullets in the JavaScript community to kill an army of vampires I could get like three laughs but the JavaScript community loves hunting for Silver Bullets so pretty much any new framework that comes out is pitched as a Silver Bullet it solves all your problems it eliminates all kinds of issues as you're gonna make things 10 times faster and for me, the only real and this is not even a Silver Bullet the only real improvement that I've really ever seen that really makes a big difference is convention over configuration the idea that you're gonna be using you're gonna be working in someone else's opinions and the reason for that is that when you use a convention over configuration system it lets you solve problems you didn't even know existed and if you can only solve the set of problems that you know exist that means you have to learn about them it means you have to learn about things like CSRF and XSS and if you have to do that then you can only learn maybe half a dozen, a dozen things if you're really, really smart maybe like 50 things but there's hundreds of things that you have to know and really the only way that you can successfully be productive in an environment where you need to know hundreds of things is to work inside of an ecosystem where people are solving a lot of the problems that you don't even know exist yet this is also sometimes known as abstractions and it's something that works really well in many other ecosystems but for some reason the JavaScript community doesn't like them very much that's okay I think people should like abstractions more I think the cross-pollination in the JavaScript ecosystem has been great I think Backbone, Angular, React, Ember, Aurelia have all really learned a lot from each other and if you look at the past five years if you look at what a web framework looked like in 2011 when it was all abstract the web or like Backbone which was 800 lines of code and you look at what web frameworks look like today it's pretty clear that we're all learning from each other and I think that's really awesome I'll also just reiterate I think web technologies are awesome I think there's a lot of good things that the web is good at the web is successful at and it's really too easy it's too cynical it's too I guess JavaScript it's too hacker news to say the web sucks everything about the web sucks we should just start over it's too easy to say that it's so much better I think to say we have a system that lets us be in everyone's pocket in everyone's device we have a system that lets us run code that nobody has to go audit or trust we have a system that lets us build share URLs across any text box anywhere these things are all awesome and I think it's way too easy to throw them away and it's something that we should be proud of and I think if you look at the past 10 years if you look at like I showed you the set of things that we were never gonna fix in 2007 I think there's a lot of hope for a better web and I think the hope for a better web is not gonna come from starting over from building everything on top of Canvas or WebGL I think the hope for a better web is that we're gonna keep evolving we're gonna keep pushing as practitioners as standards people as platform vendors to make the web the web that we want and so I'm really excited about that so thank you very much for that much time for questions yeah so thanks a lot Yoda we may take a couple of questions Yoda is going to be around so you can ask your questions later as well plus I'm on a panel today right so you can ask questions then also yeah hi Yoda I'm Narendra we at Crowdfire we use Ember CLI Ember JS and thanks to you that we serve 11 million of our users successfully so my question for today comes with a discussion which we usually have at our office is that can we have a server-side rendering with Ember something like partial rendering from the server and or something like a hybrid app so can we do that with Ember Ember JS or Ember CLI yeah so the question is about server-side rendering and what's interesting about server-side rendering this is something that React figured out but I think Ember can do really well just because of the assumptions that we make what React sort of figured out is that when you solve the problem of re-rendering really fast what that has to mean is that you've got to use a lot of DOM that already existed before and so server-side rendering is solving a similar problem you have a bunch of DOM that the server gave you and what you have to do is re-render the JavaScript on top of it and only make changes that need to be made ideally there are no changes that need to be made and so when we built Glimmer the Glimmer Engine we were careful to make it compatible with this idea we built an SEO version of Fastboot so Fastboot is the name of the thing that does this in Ember right now there's an add-on called Ember Fastboot that does that today it doesn't allow you to make a hybrid application but it allows you to render some HTML that will show up for Google or Bing or whatever whoever doesn't run JavaScript and the plan over the next probably several months we actually have active work ongoing is to do some rehydration work rehydration just means make it possible to take HTML that was created using Fastboot and rehydrated on the client side and there's some sticky things there but what ends up being good about how Ember works is that because we have this notion of pages already and the nesting of pages and the lifecycle of pages it's really easy for us to without you having to do extra work on the outer shell it's really easy for us to say okay we're gonna just run the code on the server we're just not gonna run the insert element which is the hook that runs arbitrary DOM and then on the client we'll basically pick up where we left off and even add-ons right so add-ons sort of are living in the same life cycle they know that there's the notion of pages and when they boot and there's initializers so there's always infrastructure already in place for application initialization page initialization and that really that makes it possible for us to do this in a pretty seamless way so I would say stay tuned probably within the next few months we'll have an alpha of rehydration hybrid app very cool any more questions? not the back hi so actually you mentioned many times that different pages of your app need to be isolated from each other but there are also many cases where the state needs to be shared between different pages so how do you propose we handle something like that? yeah so the isolation is really important but it's just a default right so I think if you were forced into total isolation and there were no escape valves for any kind of sharing you may as well just use an iframe at that point that is an iframe so ember has there's a couple of ways that you could share models are a common way and models are just some data that you got from the server so an example this would be like the current user right so the current user shows up in a lot of places in my application it shows up in the toolbar but it also shows up if you go into the account the list of applications in skylight for example shows up in the settings but it also shows up in the drop-down the current application shows up in the page that you're in so this is all shared stuff and the model system is a structured way of saying I've downloaded some data and now I've entered a new page you don't just magically get access to everything you have to ask for it again when you enter the page but it will be smart about not downloading things that were already downloaded and things like that so that's one vector and I think that that ends up being powerful and useful and the other one is a thing called services and services are more about things that are evented so for example if you're writing a chat application you probably don't want to model your chat application as a single model with like a latest message property that changes and you're observing it that would be terrible what you want is an event that says there's a new message you want to show it and that makes sense as a service but again you don't just get access to all the services globally you have to ask for a service and you get the service when you ask for it so the idea is that you get isolation and you can punch through the isolation you can ask for some sharing but you have to do that on purpose and what that ends up meaning is that it's really easy for someone who's coming in and maybe someone's making a change to a service they can easily go and say here are all the pages that use that service and how they might be affected by it cool, we don't have much time to take further questions so Yehuda is going to be around or you can send questions to us we will get them answered through Yehuda


Hey everybody, Dr. O here.  We have the clavicle and the scapula. Here's the clavicle. Not much to look at here. We have the sternal end, which is where the clavicle attaches to your sternum. And the acromial end, which is going to be part of the acromioclavicular joint that connects your clavicle and your scapula. Finally here, a few more things to note. We have, looking at the anterior surface, we see the coracoid process. That's going to be an important attachment point for your pectoralis minor muscles. That's the coracoid process. Then behind it, you have the acromion, also known as the acromio process. And that's going to be where that acromioclavicular joint is going to be between your clavicle and your scapula. If anyone's ever, if you ever see an AC joint sprain, you can see a little bump on someone's shoulder where if that ligament hasn't healed correctly. That's the coracoid process and the acromio process or the acromion. Then on the side, on the edge, we see the glenoid cavity. I call this the glenoid fossa. That's the socket of the ball and socket joint that makes up your gleno-humeral joint or your shoulder. Then we have, as far as on the backside, you see the spine. The spine is that narrow ridge of bone. Reason that's important is because right above it, we have the supraspinatus muscle. And right below it, we have the infraspinatus muscle. Those are two of your rotator cuff muscles. So the spine separates the supraspinatus and infraspinatus muscles, which we'll learn in the next unit. So that's going to be your clavicle and scapula. Not a lot to know there. I hope this helps. Have a wonderful day. Be blessed.