9 ms·

Here is a pretty neat demo with tons of live updates from a firebase cluster: https://dbmonster.firebaseapp.com/ https://dbmonster.firebaseapp.com/

jpdlla 12y ago
Demo's source code: https://github.com/wycats/dbmonster/ https://github.com/wycats/dbmonster/
fortytw2 12y ago
This is simply incredible. That's some insane rendering performance coming out of this.
- ckluis 12y ago
  Indeed, that is pulling some serious update info at an insane speed.
amccloud 12y ago
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 12y ago
  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.
  - lh 12y ago
    https://github.com/ryanflorence/reactconf-2015-HYPE/tree/master/demos/01-dbmon https://github.com/ryanflorence/reactconf-2015-HYPE/tree/mas...
  - STRiDEX 12y ago
    Would take with salt. The angular version doesn't use track by https://docs.angularjs.org/api/ng/directive/ngRepeat#tracking-and-duplicates https://docs.angularjs.org/api/ng/directive/ngRepeat#trackin... 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/
- ZaneD 12y ago
  Here is the original Ember version: http://jsbin.com/pafoledixe/2/ http://jsbin.com/pafoledixe/2/ Be careful, it is very slow and may crash your browser.
IanDrake 12y ago
React Version: http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/ http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/
- Numberwang 12y ago
  do you have a source for this?
  - fooey 12y ago
    http://plnkr.co/edit/Wwgjjpl9NHMO5Nd1TUyN http://plnkr.co/edit/Wwgjjpl9NHMO5Nd1TUyN
pikzen 12y ago
This demo is taking up an entire core of an i5 2500k. To update a table. It barely updates once every two seconds on a three years old phone. My terminal is faster than that and doesn't even use 1%. A native application is faster than that and barely uses 1%. I know this is a nice advance for client side rendering, but can we stop pretending it's in a good state ? (Although if you're updating this many times per second your application, you might be having a problem already.)
- rxcfc 12y ago
  In regards to taking up an entire core, it's updating as fast as it possibly can, it's basically a stress test. In practice, updating this quickly isn't useful, you would want to throttle it for production use. It's reasonably quick on an iPhone 6 (though obviously slower than on a desktop). In actual use you'd obviously design things a bit differently. Again, this is a performance test, not a real application.
  - slacka 12y ago
    Back in college I used to see 486 Bloomberg terminals updating more complex tables in real time with no perceivable lag. It's a sad reflection on bloated HTML5 technology that it can only deliver this level of performance with CPUs that are literally thousands of times faster.
    - ralmidani 12y ago
      Do Bloomberg terminals use an off-the-shelf framework (vs. custom, proprietary code) and run on the open Web (vs. a private network)? What is easier for someone with no degree and little experience, programming a Bloomberg terminal or building an Ember app?
      - Cthulhu_ 12y ago
        Using custom code or running on the Web are both not valid arguments for poor performance; in the given example, rendering in something else than a table (like, say, a custom canvas view) would already improve performance by miles. Running in a terminal (stream via ssh) would also be fasterer.

jpdlla 12y ago

Demo's source code: https://github.com/wycats/dbmonster/ https://github.com/wycats/dbmonster/

fortytw2 12y ago

This is simply incredible. That's some insane rendering performance coming out of this.

ckluis 12y ago
Indeed, that is pulling some serious update info at an insane speed.

amccloud 12y ago

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 12y ago
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.
- lh 12y ago
  https://github.com/ryanflorence/reactconf-2015-HYPE/tree/master/demos/01-dbmon https://github.com/ryanflorence/reactconf-2015-HYPE/tree/mas...
- STRiDEX 12y ago
  Would take with salt. The angular version doesn't use track by https://docs.angularjs.org/api/ng/directive/ngRepeat#tracking-and-duplicates https://docs.angularjs.org/api/ng/directive/ngRepeat#trackin... 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/
ZaneD 12y ago
Here is the original Ember version: http://jsbin.com/pafoledixe/2/ http://jsbin.com/pafoledixe/2/ Be careful, it is very slow and may crash your browser.

IanDrake 12y ago

React Version: http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/ http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/

Numberwang 12y ago
do you have a source for this?
- fooey 12y ago
  http://plnkr.co/edit/Wwgjjpl9NHMO5Nd1TUyN http://plnkr.co/edit/Wwgjjpl9NHMO5Nd1TUyN

pikzen 12y ago

This demo is taking up an entire core of an i5 2500k. To update a table. It barely updates once every two seconds on a three years old phone. My terminal is faster than that and doesn't even use 1%. A native application is faster than that and barely uses 1%. I know this is a nice advance for client side rendering, but can we stop pretending it's in a good state ? (Although if you're updating this many times per second your application, you might be having a problem already.)

rxcfc 12y ago
In regards to taking up an entire core, it's updating as fast as it possibly can, it's basically a stress test. In practice, updating this quickly isn't useful, you would want to throttle it for production use. It's reasonably quick on an iPhone 6 (though obviously slower than on a desktop). In actual use you'd obviously design things a bit differently. Again, this is a performance test, not a real application.
- slacka 12y ago
  Back in college I used to see 486 Bloomberg terminals updating more complex tables in real time with no perceivable lag. It's a sad reflection on bloated HTML5 technology that it can only deliver this level of performance with CPUs that are literally thousands of times faster.
  - ralmidani 12y ago
    Do Bloomberg terminals use an off-the-shelf framework (vs. custom, proprietary code) and run on the open Web (vs. a private network)? What is easier for someone with no degree and little experience, programming a Bloomberg terminal or building an Ember app?
    - Cthulhu_ 12y ago
      Using custom code or running on the Web are both not valid arguments for poor performance; in the given example, rendering in something else than a table (like, say, a custom canvas view) would already improve performance by miles. Running in a terminal (stream via ssh) would also be fasterer.