
Ember's “Glimmer” vs. A Simple Underscore Template - jashkenas
http://jashkenas.github.io/dbmonster/
======
jashkenas
This is just ten minutes worth of good clean fun. Glimmer looks like a very
cool piece of work — and it's a concept that I know @wycats & co have been
working towards for a long time.

But it's worth remembering that sometimes the simple approach can also be
effective ... and you don't necessarily need to load over half a megabyte of
JavaScript just to make a little view run like the wind.

~~~
ceedan
What about once that little view needs to grow up into a real application? How
far down the Backbone road do you go before you give in to that whisper in
your ear urging you to stop reinventing the framework wheel (by writing your
own, or by gluing together Backbone plugins) and just rewrite your app on top
of a more fully-featured framework?

~~~
ottertown
You don't have to go that far down the Backbone road to get performance that
rivals other frameworks is the point.

All this comes down to is how do you update the DOM when data changes. React
nicely packages up that functionality for you, but in a huge dependency and in
a fairly opinionated framework.

For a lot of developers, the flexibility of Backbone is worth the incurred
cost of having to manually create listeners / render actions for data updates.

~~~
ceedan
The goal of writing software isn't performance, though. It's a feature.

"For a lot of developers, the flexibility of Backbone is worth the incurred
cost..."

Ugh. I could not disagree more. The "flexibility" that Backbone provides in
allowing you to write manual DOM updates after an initial render is easily
it's biggest down-side. This Backbone pattern to rendering data treats every
data and state change as a 1-off situation after the initial render. Painful.
"Flexibility"

~~~
ubertaco
> The goal of writing software isn't performance, though. It's a feature.

Agreed. No customer/user will ever come to you and say "I want you to build
something, and I don't care what it does at all. I just want it to be fast."
Performance isn't the _raison d 'etre_ for a product/app, functionality is.
Now, they might say "I want it to do X, but it has to be fast," and in those
cases having something fast that sucks is still worse than having something
20% slower that doesn't suck.

>The "flexibility" that Backbone provides in allowing you to write manual DOM
updates after an initial render is easily it's biggest down-side. This
Backbone pattern to rendering data treats every data and state change as a
1-off situation after the initial render. Painful. "Flexibility"

Exactly. Speaking from my employer's experience (we went Backbone -> Angular),
Backbone is flexible in the same way that having four tires instead of a car
is flexible: you can do anything you want with those four tires! It just takes
a _lot_ of really arduous work duplicating the same things that other people
have _already_ built _and refined_ before you have something useful. But hey,
four tires weigh less than a car does!

------
iffycan
Am I looking at a benchmark? It doesn't seem to ever finish.

~~~
Encosia
It's a simple implementation of an Ember/Glimmer demo[0], which is a
reimplementation of this React demo[1] from this React Conf talk[2].

[0] [https://dbmonster.firebaseapp.com/](https://dbmonster.firebaseapp.com/)

[1]
[http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/](http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/)

[2]
[https://www.youtube.com/watch?v=z5e7kWSHWTg](https://www.youtube.com/watch?v=z5e7kWSHWTg)

~~~
ZaneD
Here are a few more examples collected from the Ember Glimmer thread.

Original demo of Ember, Angular and React: Source:
[https://github.com/ryanflorence/reactconf-2015-HYPE/tree/mas...](https://github.com/ryanflorence/reactconf-2015-HYPE/tree/master/demos/01-dbmon)

Video comparison:
[http://youtu.be/z5e7kWSHWTg?t=2m38s](http://youtu.be/z5e7kWSHWTg?t=2m38s)

Original Ember:
[http://jsbin.com/cusuyipodu/1/](http://jsbin.com/cusuyipodu/1/)

React:
[http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/](http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/)

Angular: [http://jsbin.com/valulujusa/1/](http://jsbin.com/valulujusa/1/)

------
itsbits
Here are the images of timelines Backbone
[http://imgur.com/yeffaUc](http://imgur.com/yeffaUc) Ember
[http://imgur.com/RmObUuO](http://imgur.com/RmObUuO)

Some observations.. lot of scripting in Ember implementation

Lot of recalculate in Backbone implementation

Backbone reaches complete heap size memory very fast than Ember(Interesting
when you think Ember actually has lot of objects created) There is some kind
of destroy happening(Even when this is just a snapshot of millisecs) in Ember
which you observe by dips.

Althgh Backbone looks good, Memory usage wise think Ember is better

------
funkiee
Ran both through the Timeline in Chrome. It seems like there is a lot of time
spent on scripting for Ember's version. In the underscore version you're
consistently hitting render, but at least it's much closer to 30fps than Ember
is in this scenario.

------
morenoh149
this should've trended higher! very cool.

------
mkoryak
This page the green wall of symbols from the matrix. Nothing useful here, move
on.

