Transcript from the "Ember 2" Lesson
>> Mike North: I'd like to close out by helping you guys understand what we mean when we say Ember 2, where are things right now, how do we get here, and give you guys a little insight and sneak peak into what's coming soon. So there are no new features in Ember 2.0.
[00:00:24] The idea is that late in the 1.x cycle, major enhancements were added, major alternate paths to doing things. An example is the computed property syntax where we can pass an object with a get and set function. Instead of just a function and look at arity in order to figure out are we in getter or setter mode?
[00:00:54] So that was introduced in like 1.12, and as new stuff was introduced, stuff that we were trying to get rid of was deprecated and all that happened between the last 1.x release, 1.13 and 2.0 is all of the deprecated code was removed. And this is important to realize in terms of understanding Ember's commitment to productivity and to developer economics.
[00:01:25] So the idea was that if you had a one 113 app running, and you had no deprecation warnings, you were going to be able to painlessly upgrade to 2.0. And for the most part, that was successful, and certainly, you know It was a commitment made from the community that contributes to Ember, to each other and to the other people who consume it.
[00:01:52] So I think that that contrasts with some other, you know, other things that really don't have a strong, a as strong an idea of making sure that you can keep pace with things and making sure that you don't have to throw things out. And it's been a big part of why people are confident to kind of stick with Ember.
[00:02:18] So here's what was introduced in the last couple 1.x releases. We had HTMLbars in 1.10 which was a switch towards admitting document fragments instead of admitting strings from handle bars. 1.11 introduced attribute bindings, so before that we had to use a handle bars helper called bind adder. It was quite messy and kind of was, the introduction of attribute bindings brought us closer in parity with, you know, writing handlebars like we write HTML where we are just doing key equals value and it sort of makes a lot more sense.
[00:03:02] 1.12, we got some great computed property improvements 1.13 was big. That's when the new rendering engine, the reactive rendering engine landed that's. That was a huge performance improvement for views where re-renders were common where you had a lot of different components on the screen. And then again 2.0, just yank out the stuff that's deprecated and we're left with what we're left with.
[00:03:30] And there's a big commitment to aligning with SemVer. And if you guys don't know what SemVer is it's the triple digit versioning system where you have major, minor, and trivial version. And the idea is that anything that currently works in 2.0 will not break. Any public API that works in 2.0 will not break until 3.0.
[00:03:57] And so if you're sticking to the public stuff as outlined in the documentation, that's a solid foundation to build on until we start doing massive changes again which will be quite a while from now. So coming soon and like there's no way to say whether this is going to be 2.4 or 3.1 or what.
[00:04:25] But these are things that are in the works. RFCs with a lot of steam behind them. Things that already have a lot of work being channeled to them. So this is this concept of angle bracket components. And it's really an effort to bring ember components even further in alignment with what we're used to seeing in HTML.
[00:04:51] And you see here this is an example of what an angle bracket component could look like. We've lost the handlebars. We're gonna lose the concept of this wrapping dom element because sometimes you don't want that in a component. Sometimes you want a component that's a couple of things stacked on top of each other.
[00:05:08] And forcing people to nest and nest and nest sometimes undesirable. We're dropping the concept of controllers once we can have routable components, and once the queryParam situation is figured out. So the next thing is fastboot. This is ember's server-side rendering future set. The current state of fastboot is that it works as an ember add-on.
[00:06:08] So the way things work right now is the server will render this and then once the client downloads the code and you know interprets it and runs it, it will then blow that away and render its own stuff. The hope is that in the future what the server renders will be something that is suitable for the client to actually connect to and to kind of pick up from there.
[00:06:33] And that will be powerful because that even further reduces the time it takes to get up and running. And furthermore it increases the ability for the the server, during its initial render to pass more information to the UI. About like, this is the currently logged in user, and really passing some application state to kind of, help pick up a little bit faster.
[00:07:00] And this is a big improvement because with single page apps in general, one of the major pain points is this initial page load and Fastboot directly addresses this pain point. So, I think we talked a little bit about Andens earlier in the course. The concept is very similar to, concept of the same name and realms.
[00:07:26] And the idea is to have modular pieces of an application which will have their own routing, their own models, adapter, serializers. Really a full fledged application that you can mount in some way in your router and have that encapsulated engine be responsible for all behavior in that subsection of your app.
[00:07:49] There's talk about potentially loading this code asynchronously. So you only paid the overhead of downloading the code for the blog and in the event that you actually go into a route, pivot into a route that is in the blog. And so this will increase further that initial startup time because we're no longer necessarily going to need to ship the entire app.
[00:08:20] And have you download everything in one big massive file. And also is gonna be great for large teams and this is for you know big tech companies. The idea of shipping individual engines or having separate CD pipelines for sub-sections of an application. The working model scales up a little bit better than having 50, or 80, or 100 people kind of dealing with the same router, and with the same store, and having to do their customizations, and stepping on each other a little bit.
[00:09:02] And that, that is sort of inevitable when you have, you know, little bottlenecks, they're usually like single objects that people need to touch over and over again with a very large number of contributors.