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.
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?
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.
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"
> 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!
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.
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
15 comments
[ 3.0 ms ] story [ 49.6 ms ] thread[0] https://dbmonster.firebaseapp.com/
[1] http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/
[2] https://www.youtube.com/watch?v=z5e7kWSHWTg
Original demo of Ember, Angular and React: Source: https://github.com/ryanflorence/reactconf-2015-HYPE/tree/mas...
Video comparison: http://youtu.be/z5e7kWSHWTg?t=2m38s
Original Ember: http://jsbin.com/cusuyipodu/1/
React: http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/
Angular: http://jsbin.com/valulujusa/1/
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.
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.
"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"
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!
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