
Ember's Glimmer Engine - hswolff
https://github.com/emberjs/ember.js/pull/10501
======
vjeux
React 0.14 is going to have similar optimizations. Check those three posts if
you are interested in the details :)

Reuse Constant Value Types like ReactElement:
[https://github.com/facebook/react/issues/3226](https://github.com/facebook/react/issues/3226)

Tagging ReactElements:
[https://github.com/facebook/react/issues/3227](https://github.com/facebook/react/issues/3227)

Inline ReactElements:
[https://github.com/facebook/react/issues/3228](https://github.com/facebook/react/issues/3228)

~~~
ralmidani
React's unfair and one-sided patent grant aside (personally, I will never
build a real app with React unless that situation changes), it is not a
complete MVC framework, and to my knowledge there is nothing that fills in the
gaps to make something close to Ember feature-wise. So while React may end up
faster, Ember will hopefully be quick enough that its programming model wins
out.

Edit: grammar.

~~~
rxcfc
It's also worth noting that we're getting to the point where fastest doesn't
really matter. Both Ember and React will be fast enough. Performance shouldn't
be a deciding factor.

~~~
steveklabnik
One of the motivations for this change was that a real-world application was
too slow. As the original presentation says, choosing a technology and then
finding out that it's limiting you is really rough when it happens to you.

Performance _does_ enable certain kinds of applications, and it does
absolutely matter, even on the desktop.

~~~
ralmidani
Performance matters, but if Ember can have 50-60% of the speed of a
performance-optimized React app without the associated cognitive overhead, I
suspect many will see the trade-off as worth it.

~~~
rxcfc
Agreed. And I suspect Ember can get closer than that, if not even outdo React
in some cases.

------
praxxis
The performance of Glimmer is amazing, but lets not forget this gem:
"backwards compatible with Ember 1.x apps."

Here's to a future where our apps get faster without us having to change a
thing.

~~~
steveax
Indeed. I continue to be impressed at how painless keeping current with ember
in our application has been.

~~~
trek
That's awesome to hear! It takes an unbelievable amount of energy and
sometimes frustrates us with how slow and deliberate we need to be with
features.

~~~
Cakez0r
Thank you for taking the time. Ember's API stability made it the only viable
choice for our web apps at work.

------
dracolytch
I always have a problem with these kinds of frameworks. Every time I try to
use one, and want to do something more in-depth for fancy than a lot of the
functionality out-of-the-box, then I end up having to hunt down the way to
extend X feature, and it often takes me more effort to do that then just
writing in the root language would be.

That is to say: The abstraction isn't as expressive as the root language, and
when I need something more expressive, then it's more troublesome than writing
than the root language.

The rendering engine here does seem to perform admirably, and I have to
congratulate them on that. Maybe I've just been burned a few too many times
from this kind of language.

~~~
untog
Every framework has a learning curve. In this instance it seems to have a
significant performance benefit. That's your trade-off.

~~~
aero142
I didn't take his comment to be about a learning curve. I think the complaint
is that the abstraction on top is not as expressive as the thing it abstracts.
This means that when you break the abstraction you have the complexity of the
thing you abstracted away on top of the abstraction layer itself, which means
you might have been better off without the abstraction in the first place.

------
mixonic
Glimmer is a revolutionary improvement in Ember's rendering performance. I'm
incredibly excited by the progress and promise being realized in Tom and
Yehuda's PR.

For more context, here are a few quick slides from the EmberConf keynote:

[http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf](http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf)

They, and the PR, tell the whole story about what is happening in the
dbmonster demo. We expect this work to land in Ember 1.13 stable!

~~~
msane
I needed improvements in Ember's rendering performance a year ago, back when
performance improvements were already behind schedule.

A situation which still remains in production Ember today:
[http://youtu.be/z5e7kWSHWTg?t=2m42s](http://youtu.be/z5e7kWSHWTg?t=2m42s)

It's too little too late for me. I wouldn't want to touch anything Ember or
anything from the authors.

~~~
mixonic
I also needed improvements. So I shipped the code to make them happen! Very
proud of our progress.

I hope the stability and reliability of Ember's process, and its continuing
improvement, will tempt you back.

~~~
msane
Yes, you're right. It's my fault for not pitching in. I should have worked my
way in to the core team and fixed it myself, rather than selecting one of the
other performant frameworks available.

> the stability and reliability of Ember's process

I'm aware you're one of the people who finally got it done, kudos. But the
chances of going back to Ember are nonexistent. This was my experience with
Ember:

[http://discuss.emberjs.com/t/when-will-htmlbars-be-
ready/315...](http://discuss.emberjs.com/t/when-will-htmlbars-be-
ready/3155/58)

* 08/2013: Unusable performance when displaying listviews with over 20 items, without infiscroll (unofficial and poorly supported, or roll-your own). Promises that it will be resolved in next months.

* 08/2014: Still getting the runaround about when those "improvements" will arrive.

Only one of a dozen things which made working with Ember horrific. Apologies
for being bitter, but it is what it is.

------
jashkenas
For the curious, here's a port of the Dbmonster demo to a simple Underscore
template — the kind of base-level rendering strategy you might _start with_ in
a Backbone app. (And vintage 2009 technology.)

[http://jashkenas.github.io/dbmonster/](http://jashkenas.github.io/dbmonster/)

 _Edit:_

To head off grumbling at the pass — It would also be easy to do a slightly
less-simple version that keeps the flickering impossible-to-read popups open
(putting redundant tooltip DOM into each table cell isn't how you'd actually
write this), and the server names selectable ... but those particular
"features" don't really seem relevant to this particular UI.

~~~
ebryn
Unfortunately your example isn't a full reproduction as both the Ember/React
examples reuse existing DOM which is important for selection state and the
popover functionality.

------
makmanalp
Here is a pretty neat demo with tons of live updates from a firebase cluster:
[https://dbmonster.firebaseapp.com/](https://dbmonster.firebaseapp.com/)

~~~
amccloud
Demo of embers original performance with dbmon along with angular and react
[https://www.youtube.com/watch?v=z5e7kWSHWTg](https://www.youtube.com/watch?v=z5e7kWSHWTg)

~~~
baddox
Are there demos and/or source code for the Angular and React implementations
used in that presentation? I'd like to compare React to this new Ember
implementation, because the latter, while better than the Ember demo in that
presentation, is still noticeably sluggish on my machine.

~~~
STRiDEX
Would take with salt. The angular version doesn't use track by
[https://docs.angularjs.org/api/ng/directive/ngRepeat#trackin...](https://docs.angularjs.org/api/ng/directive/ngRepeat#tracking-
and-duplicates)

These demos are like listening to MongoDB talk about how great MongoDB
performs. Always better to look for yourself or check a trusted third party.

Here's an angular dbmon that is at least using track by. I didn't write it.
[http://run.plnkr.co/plunks/Uu7w8p7jiPEJp5lLHWbB/](http://run.plnkr.co/plunks/Uu7w8p7jiPEJp5lLHWbB/)

------
hswolff
Gotta say, the incremental improvement pattern Ember is adhering to is
absolutely the bee's knees. Kudos Ember team, so awesome to see!

------
davexunit
>building virtual DOM nodes for static areas of your markup that will never
change for every change requires many more allocations and increases GC
pressure.

I'm not familiar with Ember, but why not just store the constant value in a
variable to solve this problem? For example, in MithrilJS, you write templates
in plain JavaScript, so I just stash large, static parts of the tree in
variables and only rebuild vdom nodes for dynamic content. Simple.

~~~
colinramsay
You appear to have been downvoted; while I don't know whether your potential
solution is right or wrong your downvoters should have been polite enough to
explain their reasoning.

~~~
mixonic
I am confused what is being suggested.

> virtual DOM nodes for static areas of your markup

refers to React's virtual DOM implementation, not Ember's.

> I'm not familiar with Ember, but why not just store the constant value in a
> variable to solve this problem?

Ember is a complex framework. Suggesting a "solution" to challenges with an
acknowledged lack of context, and adding "Simple", shows fairly poor attitude.

> I just stash large, static parts of the tree in variables and only rebuild
> vdom nodes for dynamic content

This sounds pretty much like what is already described in the PR.

Again, still confused, and still don't know what is being suggested.

------
steveklabnik
Quote from wycats during the talk:

    
    
       > Because our template language is declarative, we can do this at compile time.
    

"This" being determining which portions of the DOM will never change, and so
only needing to analyze the portions that might.

~~~
nathansobo
Is the talk online?

~~~
rxcfc
Not yet. It just happened and will need to be post-processed. I'm pretty sure
all EmberConf talks will eventually end up online.

------
bsimpson
It's pretty cool that a year ago, React was far and away the best choice for
new JS development for reasons that seemed to be architectural (no dependence
on the DOM/server-renderable, isomorphic, intentionally minimal DOM
modification), and in the intervening time, the Ember guys have taken the good
ideas from React and brought them to Ember. Congratulations! It's great to see
the best ideas lifting all boats.

------
some1else
Looks like Glimmer's wits regarding the distinction of static and dynamic
parts of the template should be applicable to JST, HAML and the rest as well.
The dynamic parts are clearly marked with template tags, and local (changed)
variables would be easy to scan for within the dynamic parts of the code. This
would probably mean that the template engine should decompose the template
into smaller bits, and provide metadata by which the view can map DOM
fragments to template fragments (DocumentFragment, DOMNode, DOMAttribute,
TextNode) and related Model attributes. Attrubte-level change events could
then either directly expire the relevant fragments, or the View
onChange/render function would skip repainting the unchanged parts and use
appropriate (previously decomposed) fragments of the template function to
render changes.

------
untog
Interesting it's using Handlebars - I wonder how it compares to the diffing
done in Ractive, which also uses a similar syntax
([http://www.ractivejs.org/](http://www.ractivejs.org/)).

~~~
rxcfc
To be clear, while we're using Handlebars syntax, the underlying runtime is
not the standard handlebars.js, but a custom version for Ember.

------
ohfunkyeah
I see a lot of talk and comparison to React but nothing about Meteor's Blaze
engine and its HTMLJS virtual DOM diffing approach which seems even more
comparable

------
Rapzid
Will these virtual DOM/diff'ing optimizations be built into the browsers at
some point? Seems like they should/would.

~~~
ivanb
Yes. They should. Currently DOM works in an imperative, immediate way. Kind of
like a Basic program or OpenGL immediate mode. After a write to a property you
are guaranteed to get the same value back after you read the property. The
dependent properties are also guaranteed to be updated immediately.
Surprisingly, this imperative way of programming is actually not efficient at
all because subsequent writes and reads may cause reflow.

To prevent this the programming model should be changed. There are two ways
that I can imagine.

\- Introduce "DOM batching mode". In this mode remove the immediate mode
guarantees. If you specify an element width you are no longer guaranteed to
read it back until the layout occurs. So store your intermediate element width
somewhere if you want to use it. Of course you don't need to specify batching
mode for all the DOM tree. Just the majority of it that doesn't require custom
layout.

\- IIUC the majority of times that you need to perform multiple reads and
writes of the DOM properties is due to special layout requirements. In some
cases CSS layout may not be enough. There should be an API that allows to
specify custom layout strategy for a parent DOM element. JavaScript should be
fast enough. The additional benefit is that we would no longer need to wait
for e.g. Flexbox adoption. Just roll your own.

It is obvious that we are trying to turn HTML into a GUI framework. So let's
do it properly.

The problems we are facing with DOM have already been solved by multiple game
engines and GUI frameworks.

~~~
ubertaco
> Introduce "DOM batching mode". In this mode remove the immediate mode
> guarantees. If you specify an element width you are no longer guaranteed to
> read it back until the layout occurs. So store your intermediate element
> width somewhere if you want to use it. Of course you don't need to specify
> batching mode for all the DOM tree. Just the majority of it that doesn't
> require custom layout.

Some sort of DOM-like buffer[1] that you could render into and then
"flush"/insert, maybe?

[1] [https://developer.mozilla.org/en-
US/docs/Web/API/DocumentFra...](https://developer.mozilla.org/en-
US/docs/Web/API/DocumentFragment)

------
itsbits
I am not as smart as lot of guys here..but What exactly is Glimmer's
additional optimisations other than Virtual DOM?...

What exactly does this mean "the programming model is equivalent to render
every time, but we take advantage of the declarative nature of Ember's APIs to
reduce work."??

~~~
flexterra
Ember's templates allows the framework to determine which portions of the DOM
will never change, and so only needing to analyze the portions that might.

    
    
      <div class="container"> <-- this won't change
        <h1>Hello World</h1> <-- this won't change
        <div>{{name}} <-- this might change </div>
      </div>

~~~
itsbits
Wow..Thanks a lot..Now I understand the sentence..

But I think now this may force us to use more handlebars. Manipulations in
didInsertElement may get affected as well. Like updating classes which I
sometimes prefer doing in hooks like click, didInsertElement.

~~~
iamstef
Additionally, rather then having a "virtualDOM" we build a tree of the dynamic
data. This is more or less diff'ed similarly to how the virtualDOM is diff'ed.

But where it get interesting is when it comes to actual DOM interaction. To
create DOM, we use document fragments + cloneNodes, but for granular updates
we utilize property/attribute/textContent updates. When used correctly, this
combination turns out to be very fast.

As a bonus, we are typically able to utilize the browsers built-in XSS and
sanitization (or just lack of parsing) rather then having to implement this
slowly in JavaScript ourselves.

Ultimately, I am extremely happy with how the various front-end frameworks
keep pushing the envelope. Getting faster, easier to use, and more secure.
Ultimately regardless of the framework the ecosystem moving forward benefits
the end users the most.

~~~
itsbits
Thanks Stef. This explains a lot. Its great that Ember responded with best way
after many started comparing with the performance lag of Ember. I was lil'
skeptical when you declared this in December, but now I am looking fwd for the
release.

------
drderidder
I feel like the techniques React uses to deal with state and performance are
likely to be addressed in a simpler way by solutions that work better with the
existing stack. I'm not an Ember user but I like the way they've approached
this, without re-inventing the DOM wheel.

------
theflop
So what happens with all those JQuery plugins that manipulate the DOM directly
in didInsertElement? I'm guessing Glimmer doesn't have a clue how to optimize
that use case. So a lot of components need to be rewritten from scratch in
Ember-style?

~~~
awj
Well, if you need the performance increase, the yes. Otherwise your options
are to (maybe) tweak your current implementation so it continues to work or
rewrite the functionality to be compatible with the view layer. This is the
same trade-off you make with React since it's basically the same technology.

------
pothibo
Is that DBMonster app becoming the new todo app for all JS framework to
implement?

~~~
hayksaakian
i think the todo app is a good demonstration of the specific code necessary to
accomplish a standardized task.

DBMonster is more like a standard performance benchmarker.

------
anarchy8
Can we have a side-by-side comparison of the same demo using normal Ember?

~~~
wycats
It's slow. Real slow. The original demo really stressed Ember's pathological
cases, so it was a great thing to keep in mind as we developed Glimmer.

~~~
cnp
I saw the original at a Meetup a while back and it was crash-the-browser slow.
This is far improved.

------
lightblade
> On my machine, the dbmon app in Ember+Glimmer gets 10 renders per second,
> React gets 14. Not bad, way better than 0.1 per second!

[https://twitter.com/ryanflorence/status/572991666090467330](https://twitter.com/ryanflorence/status/572991666090467330)

------
cfontes
Never used ember but that deserves a pretty complete write up about what was
done and how.

Nice work.

~~~
steveklabnik
Here's a TL;DR:

A handlebars template might look like this:

    
    
        <div class="foo">
          {{#if enabled}}
            <p>I'm enabled!</p>
          {{#end}}
        </div>
    

The usual DOM-diffing algorithm compares every single thing: "has this div
changed? Has the class changed? Has the <p> changed?"

This uses the knowledge of Handlebars to make the diffing algorithm smarter:
you don't need to check if the <div> or its class has changed, it never will.
You don't need to check if the <p>'s contents have changed, it never will.
This means less to diff, which means more speed.

This is the advantage of using a declarative syntax for templating: this
analysis can be done entirely at compile time.

~~~
searls
Thanks for the concise description. Love to see Team Ember take advantage of
the information users are already feeding the existing public API.

------
virmundi
So how does this compare with Ionic/Angular on mobile? I recently made an app
with Ionic, but the 1.0 migration caused gestures to no longer work. Can
Glimmer run well on mobile?

~~~
nwienert
I'll go ahead and plug myself here only because it's very relevant, but if you
want to play with a full-stack for building mobile apps using virtual DOM,
check out [http://reapp.io](http://reapp.io)

------
itsbits
What kind of DOM model Ember is using like React.DOM?...I don't think
handlebars create DOM Objects?...great to see How Ember accepted the change
and implemented that...

~~~
zeppelin
Handlebars doesn't, but HTMLBars does indeed [generate][1] DOM objects from
Handlebars AST - it's basically another compile step. Check out section 2 and
3.

[1]([https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE...](https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE.md))

~~~
itsbits
I see that HTMLBars is building more of Document fragments rather a single DOM
tree. Would be interesting to check if all these document fragments are
independent to each other like 1000's of HTMLBar views inserted directly into
the Ember Application as siblings rather as a tree. There will be lot of
memory involved than when you use a single DOM tree. isn't it?

------
itsbits
Interesting..it has been 10 days Yehuda made that comment and now we come to
know about it...or there was discussion before on same which i might have
missed?

------
ohfunkyeah
I see a lot of talk and comparison to React but nothing about Meteor's Blaze
engine and HTMLJS which seems even more comparable

------
randomguy7788
ng2 will have similar optimizations i believe. interesting times in the 2.0
framework wars! lol i kidddd

~~~
spyc3r
Angular 2.0 has similar optimizations but sacrifices backwards compatibility.
Glimmer is still backwards compatible with Ember 1.x.

------
cellis
But will it work with Emblem? Also how does this affect FastBoot?

~~~
rxcfc
Emblem compiles to Handlebars so it will gain all of the benefits of Glimmer.
FastBoot is only concerned with the initial render which is done on the
server. Glimmer is concerned with updates so it will not directly affect
FastBoot but will work with it.

------
EugeneOZ
So mutable structures can be powerful too, when handled right :)

------
mmgutz
Will this be built into handlebars or just ember?

~~~
ChrisGaudreau
Just Ember. I'm pretty sure Ember doesn't even have a dependency on Handlebars
anymore. (possibly only off stable)

~~~
rxcfc
Ember still uses the Handlebars syntax, but we don't use the standard
Handlebars runtime anymore.

------
iamleppert
Yawn. Dust has had all this (and much more) for a long time.
[http://akdubya.github.io/dustjs/](http://akdubya.github.io/dustjs/)

~~~
rxcfc
This is only meaningful if Dust has all the other features that Ember
templating has.

