I'm Eric Brin, this is Chris Selden, we're members of the core team, and we're here

to talk about HTML bars, and I'm just curious, how many of you have heard of HTML bars before? All right. Raise your hand if you have not heard about HTML bars yet. All right. You guys need to get out from under the rock you're living under, because we've

been practicing a style of development that I like to call EDD, which is Ebrin driven development, and you see the first step is to find something awesome to build. The second step is to hype, hype, hype. The third step is to announce an idealistic release date, ideally at a nice big event

such as EmberCon. Step four is to proceed to force Chris to neglect his responsibilities as a husband and father to help you ship it. And of course, step five is to thank his wife Patty very much. So let's give a round of applause for Patty, please.

So let's talk a little bit for the two or three of you in the room that don't know what HTML bars is, let's recap what it is. It's a new templating library built on top of Handlebars.

So the difference is that it understands your markup, whereas Handlebars was just a really sophisticated string interpolation mechanism, right? And I think it'll be interesting to see what comes out of ES6 string templates, because we're finally going to have real string interpolation in the browser in JavaScript,

which is amazing, and a whole bunch of other cool features as well. But HTML bars can be really smart about how it does its job. Oh, shoot. So it understands your markup, it can be smart about how it does its job. And what do we mean by that?

So we'll get into it a little later. But basically, let's talk about what excites people about HTML bars, people like you guys in the crowd. Syntax, right? It gives us our ideal syntax. Right now, today, we have our ideal syntax, right? We should just be able to use curlies inside of attributes, inside of elements.

You can do this with plain Handlebars today. Unfortunately in Ember, because of our data binding need, we have to use helpers to achieve this. So we have bind adder, right? But with HTML bars, we get the syntax that we wanted.

And the reason for that is because Handlebars doesn't understand your markup, it can only just turn mustaches into string output, whereas HTML bars knows exactly where mustaches are being used, whether they're inside of the element itself, whether they're inside of an attribute, or whether they're inside the content of an element. And HTML bars also builds DOM fragments instead of strings.

And so this lets us hold reference to those things, where you're putting those mustaches, so that we can update them later, right? That's data binding. And so what does this mean? Well, it means no more script tags, right?

So here's an example before and after, right? We've got all these script tags. We thought it was a pretty clever solution at the time. We started with a span wrapping based approach, and that just fell on its face after shipping. I don't know when we figured that out.

It was probably one of the first or second alphas when we were SproutCore 2 at the time. And so we figured out scripts were valid everywhere, so great, we can use this, because at that time we thought string templating was the way to go. So what's the other big feature that people care about?

The dreaded performance of long lists, large lists. So in HTML bars, we're able to solve this problem cleverly, or help solve this problem, by being able to rapidly clone DOM. So when you've got an each helper, you're defining a set of markup that's going to

be repeated over and over and over again, right? So we actually are able to, with HTML bars, build that DOM once, and by build that DOM I mean call document.createElement, div, you know, blah blah blah blah blah. Build that up, and we actually don't fill in the parts, the dynamic parts of that template.

And so what we do is we cache that fragment of HTML that's inside of your each helper, for example, or any template block. This works everywhere. And we can now clone it, which is deeply clone it, and this is basically the fastest way you can build DOM in the browser today. So we don't have to continually keep calling document.createElement for the whole tree.

We just do that once, and then we clone it for every subsequent run. And then we go in and we fill in the dynamic parts afterwards, we call that hydration. And so that's what everybody's excited about, about HTML bars, pretty much. That's the TLDR. But what excites us about HTML bars?

It's our chance to fix some of the fundamental performance problems in Ember. So Chris and I, we've been talking, the core team, everyone's talking about HTML bars. But actually, HTML bars has kind of become a blanket term for what actually is a large

rewriting of the Ember view layer. The Ember view layer is what underlies components as well. So let's talk about some of those things. So what's going on here is, so this is less HTML bars, more view layer. It's one of the things that has always bothered me about, is the binding update

order has no understanding of hierarchy or priority. And what happens in this example is once it's rendered, what you really want to have happen is for

photo to be notified before photo thumb URL. Because you're gonna destroy what's inside of that if it turns false. Currently this is a issue problem because in Ember we notify pass before keys.

And so this will update the source before removing the whole view. And that gets even worse when it's a large view inside an if. This is something that we are in the process of fixing

in our rewrite of the view layer to integrate HTML bars. So the TLDR of how this works is basically instead of immediately going and when photo changes in this example, instead of just going and

updating everything that is observing photo, we actually just do kind of what computer properties do. We go and we tell everybody, hey, we know this thing's going to change. And then we basically know what the highest priority, the parent most view is that cares about photo.

And then we just say, okay, everything in that subtree doesn't need to be touched until we update photo. And so photo turns falsy, then we just know we're gonna destroy the DOM. But if photo just stays truthy, then we know that we're gonna just go and update the individual binding here in the Ember source.

So this is like a nefarious problem, right? You update photo to null, and then you actually see probably an image, an HTTP request for like a null URL or something. Those worst examples, but yes, it sometimes can even cause errors and then you have to- Yeah, so this is a nefarious problem that I think

hopefully most of you have not noticed in building an Ember application. But this is one of the really exciting things. And this is not unlike what the browsers do. This is actually a very common pattern in UI frameworks. So we're taking that. We're stealing those ideas, and we're giving it to all of you inside of Ember, inside of our view layer.

So the next thing is recursion. I don't know, let's just go to the next. Ember right now is- So this is a flame chart for those of you who have not played with the Chrome dev tools.

This is basically representing the stack of currently executing code. And this was during a render, basically. So right now, we've focused a lot on removing recursion, the current build. This is pretty much largely done.

And I worked really hard to try and get a build out today. I didn't do a lot of prep for this talk. Because I was trying to hack and hack and see if I could get alpha. It's really close. Most of the tests are passing.

But this part is done. And not only is the view rendering not recursive, when you add something to a container, and another item gets added to a collection, all of its child views,

none of that will be recursive. Even the templates, we unroll all the looping during compile time. So if you pre-compile your templates and ship it, it'll just call all the helpers in the right order, no loops.

And- That's important for performance, because JavaScript doesn't optimize recursion currently. It'll even also help you to find performance problems, because it'll be very clear where-

So the nice thing is that this is the before shot. We don't have an after shot for you. But the after shot is going to basically be just small stacks, and you're going to actually see individual views getting rendered, basically, right? So that's going to be awesome for performance debugging. Ideally, you won't have to worry too much about performance, right?

Magic bullet. But when you do, you'll be able to use the tools that we have today to do it. Another thing that was important for us is, I mean, we want you to use templating, and we want you to use bindings, and

we just want it to be fast, and currently what happens in Ember, if you change the underlying context of the view, the whole view re-renders. Its element is destroyed. Now, we've set up all these bindings in observers, but we basically throw it out and redo it.

And this view layer, we're working so that it works to, everything is bound through the context. And if you update the context, all the bindings will stay in place, and

it won't tear anything down. Yeah, so the TLDR is you change, you do view.context. Anyways, so yeah, for example, with re-rendering, like right now, the idea is you have a view object, you call set context or set controller, there's an observer, and that observer calls this.rerender, right?

And so, right, so we've done all that work to have everything in the template nicely bound, and now, instead of those templates, that view having to re-render itself, now the bindings will be able to just update all the content right through. So you might have noticed this, I'm trying to think of what's a good example.

So we do some hacks right now with dynamic segments, right? Like we keep the view hierarchy around when you're switching from one route to another route, but with just swapping out the model, right? So actually, Edward Faulkner submitted that pull request to do that,

which was a nice performance. So that works, though, because you're going through a proxy, so when you have a proxy, because of the- There's a stable object, yeah. The context of the template is the controller, so when you switch the model out of the controller, the view stays and the bindings update.

So when you touch the context directly, it re-renders. But another point to this slide is that people re-render also as a performance thing. The templating is slow, some each is slow. It's more like you implement your own render, right?

So you then render stuff unbound, watch one thing. Re-render the whole thing. We're hoping that you won't do that anymore. It'll just be fast. So the hope is actually, and if we succeed in our mission, the idea is any of those custom render methods you might have in your views

are actually going to be slower now than using HTML bars to do your templating, because HTML bars is doing the smart caching and cloning of the DOM for you. So really, if you're doing custom render methods, like I think our good friends at this course are doing in some places that are really hot code paths,

they're going to see actually using templates are going to be better than the hand-rolled code you would do yourself in a render method. So that's really cool. So it's also just DOM, right? So why don't you riff on this? One thing is, we have a whole wheel insert element.

Probably nobody uses because you don't actually have the element that you're going to insert. Consistently, at least, right? You will now. This is actually a huge deal.

So why don't you give the animation example, I think. So I mean, if you have a plug-in, you're doing animation, and you want to set it up before the DOM, the element is actually in the DOM, because you don't want it to be visible. So you want to set it off the screen before it actually

comes into DOM. So is this better? Yes. There we go. Sorry about that. So yeah, animation. Yeah, and say you're doing custom rendering, like

discourse, if you do happen to do that, which is OK, the leaf view that doesn't have any children, it is just going to be you're interacting with DOM. There's no more pushing strings, which is one thing

that we forgot to put in the slides is, this is secure by default. You have to do extra work to. Secure in the sense of XSS and, you know. Almost everybody's little gist or snippet of custom rendering has stuff where they push a string.

Yeah, so what we mean by save by default is that you're actually, your views are just going to be, well, you're dealing with a DOM node. There's no more render buffer, if anybody's ever touched the render buffer code before.

So inside of your render method, you don't have a render buffer. You actually get the element that belongs to your view. And so when you're doing manipulations to that element or adding children, you're doing things like inner text. And if somebody's injecting HTML into your application via

a form input or something, you're going to be using the browser's built-in security in those regards. Now, if you create a text node, the browser's going to escape it, and that's what HTML bars does now. When you're doing string templating, you're building a bit of HTML and putting it in.

And we try very hard to be careful about it right now, but when people submit new features, it's really hard to review everything. And we've let quite a handful, small amount. I think we're pretty good. We're very quick to respond when somebody finds a security

thing, but that should. So did we give a good animation? Did you give a good animation example? We got interrupted. So basically, the idea, I'll just reiterate. In will-insert-element, let's say you've got something that's going to get rendered out, and you want to, let's say, move it off screen. will-insert-element is the great place to do that now because you have the element reference.

You can just say, put it off screen. And then in did-insert-element, you can move it on screen, and your CSS transitions will do the work for you. So that's going to be a really nice little primitive for animations. Obviously, I loved Edward's talk. I think we need to do more to enable that in animation supporting core, but just this basic thing is going to help

a lot of people out. And then, of course, there's some destruction stuff we need to do as well. But there's another thing we didn't have in the slides that I do on it. We have nine minutes. This is related to animations and the thing about binding

through the context. All of our bindings are contextualized off the view, and the view is managing these streams. We don't have time to get into streams. So basically, the main thing is we're going to be able to gate data coming into the view layer.

So if in an animation, we should be able to basically turn off the binding, let you animate, and similarly, if you're transitioning in, we should be able to hold the streams and not let them hit the templating until you

animate in, and then you can update it. So that's going to be really awesome. Basically, we've got one place now where we can add a switch, and now you're animating. So your templates aren't going to get their data binding updates.

When you're done animating, turn it back on, and boom, they'll only get the last values. We won't replay everything. So this is really cool stuff. And some of this just comes because it's just dumb.

And so what was I going to say about simplicity? That was simplicity. I think, oh, so basically the idea is with this rewrite of the view layer, we've actually rewritten it as a micro library. And so the idea is that it's super easy for you guys to

step through the render path. So it should take away a lot of the complexity and what some might call magic of what Ember's doing to get your templates out into the DOM. And so my hope is that it will be a lot easier for

people to step into a render function inside Ember View, step through it, and be able to reason about what's happening. I think that's really important for people who get stuck in weird situations and need to figure out what's going on. So I think we're always looking for better and simpler primitives in Ember.

And you can rest assured there's always going to be an internal desire on the core team, always find simple solutions to these complex problems so that not only will they be fast, because in JavaScript it turns out doing less work and doing easier things tends to be faster than doing more complex stuff, right? And it'll also be good for debuggability as well.

So another awesome thing is that we're baking in support for server-side rendering of these templates as well. So right now the plan is basically focused on the SEO

use case less than what has been referred to as fastboot use case. And the idea is you'll be able to do this inside of node. You don't need a headless webkit or anything like that. Ideally, there's a little bit of hand-waving. We haven't actually done the implementation work, but we've done the architectural design to make

sure that this is possible. And some of the actual implementation work is sitting out in the pull request that I need to review. But basically the idea is this doesn't rely on any fake DOM implementation either, like JSDOM. Basically we will have a fake DOM implementation. So HTML bars doesn't actually use document.createElement

explicitly. It calls to a helper that does create element for us. And so the idea is you can just swap out that helper layer. And now when you're running your Ember app inside of node, that thing can just go build a tree of DOM elements. And then you can call some two string or two HTML method

on the root view in that hierarchy, and you'll get the HTML from your view layer. And so there's some gotchas and some constraints around this. Like if you don't want to use something like JSDOM, you can't do things like execute the didn't insert element callbacks that might be triggering JQuery

functionality on your server. But this is pretty much the 80% to 90% use case for solving SEO. And so the idea is you boot up node. You can load up your Ember application source code. You can say go to this URL. So we'll navigate the application.

And you can say basically serialize the current state of the rendered output and shovel that off to Googlebot or embed it into your page. So that'll be really cool. We're all excited about that. And I don't know if this is last but not least,

but there will be an optional JQuery dependency as well. So we traditionally use JQuery. Well, so right now, we really use JQuery primarily for event delegation. And we do use it still, I think, in a few places for browser bug avoidance.

And this mostly traditionally came from the problems of you've got an each, and there's a TR inside of it. And you can't just append a TR anywhere. You can't just build a fragment from a TR. It needs to be inside of a table tag or a T body.

And JQuery had all that logic in it, which kept us from having to worry about the inconsistencies in browser bugs across different browsers. And so that was the main reason. And it was really heavily a side effect of using string templating. And so now, with HTML bars,

we don't need JQuery to do that stuff. So basically, the only thing we needed it for anymore was event delegation. And it turns out, event delegation isn't too hard to do. So we just built it in to the view layer micro library.

So that means if you're on mobile, perhaps we have just shed, what is it, 30K of MNG dependency? So it should be good, why not? If you're using JQuery today, there's nothing stopping you from using it still in your application. There's also really, a lot of people don't know, but you can actually do custom JQuery builds

and only take the pieces of JQuery that you care about. You know, if you're conscious about file size or need to be conscious about file size. So those are really the things that I think Chris and I and the core team are excited about, HTML bars. And I think I just want to reiterate that, you know,

what differentiated Ember from its heritage from SproutCore was our focus and our bet on templating, being the right tool for building complex web applications today. And I think that, you know, our goal is for HTML bars

to set the new gold standard for templating libraries in the browser. And I think we're gonna, you know, with a little bit of luck and some elbow grease, we're going to, I think, achieve that goal. And it's going to be really a night and day

performance improvement, I think, from today's Ember, which is already screaming fast due to a lot of the work that Chris and I and Steph have done. And I'm really excited to, in the very near future, ship you guys an alpha or beta build of Ember

with HTML bars, and ideally, you drop it in your app and you see something on a scale of two to three X performance improvement without having to do anything. So that's the goal. We're really close.

We're sorry, I'm sorry, I over-hyped. I oversold and under-delivered, noob mistake. But no, we're really close and really, really excited to give it to you guys, so thanks very much.

Oh wait, oh wait. This could not be the ending talk of the day without one more thing. So I just want to posit something to everyone here. What would the world look like today, the web development world, if we could build web components now with the technology that we already have?

Think Ember component, but without an Ember dependency. Coming soon? We'll see. Thanks.