5 ms·

Ember's “Glimmer” vs. A Simple Underscore Template

25 points by jashkenas 12y ago

iffycan 12y ago
Am I looking at a benchmark? It doesn't seem to ever finish.
- Encosia 12y ago
  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 12y ago
    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/master/demos/01-dbmon https://github.com/ryanflorence/reactconf-2015-HYPE/tree/mas... 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/
jashkenas 12y ago
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 12y ago
  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?
  - Gigablah 12y ago
    You'd do it the other way round if performance really is top priority (like what the Atom guys did).
    - ceedan 12y ago
      Not performance, maintainability.
  - ottertown 12y ago
    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 12y ago
      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"
      - 12y ago
ossreality 12y ago
Yeah sorry, but I literally laughed out loud at the people in the Glimmer thread that were amazed that such an incredibly simple app was running well.
mkoryak 12y ago
This page the green wall of symbols from the matrix. Nothing useful here, move on.
morenoh149 12y ago
this should've trended higher! very cool.
funkiee 12y ago
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.
itsbits 12y ago
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

25 points by jashkenas 12y ago

iffycan 12y ago

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

Encosia 12y ago
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 12y ago
  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/master/demos/01-dbmon https://github.com/ryanflorence/reactconf-2015-HYPE/tree/mas... 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/

jashkenas 12y ago

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 12y ago
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?
- Gigablah 12y ago
  You'd do it the other way round if performance really is top priority (like what the Atom guys did).
  - ceedan 12y ago
    Not performance, maintainability.
- ottertown 12y ago
  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 12y ago
    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"
    - 12y ago

ossreality 12y ago

Yeah sorry, but I literally laughed out loud at the people in the Glimmer thread that were amazed that such an incredibly simple app was running well.

mkoryak 12y ago

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

morenoh149 12y ago

this should've trended higher! very cool.

funkiee 12y ago

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.

itsbits 12y ago

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