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.
Ember's Glimmer Engine
101–110 of 136 posts
Re: Ember's Glimmer Engine
#102Earlier quoted context omitted.
it seems like if you're concerned with performance, react vs ember is not the conversation you're having. your concern would be whether to use a framework at all
Performance is a relative term. One could just as well argue that if you're really concerned with performance you should just write machine code.
i suppose i presumed a difference of 2x either way (worse/better) to justify picking one over the other -- given that frameworkless is ultimately the most optimize-able.
do you need something to be "at least X(ms) fast" or "faster than what company Y is doing" or "as fast as possible, no exceptions"
Re: Ember's Glimmer Engine
#103Is that DBMonster app becoming the new todo app for all JS framework to implement?
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.
Re: Ember's Glimmer Engine
#104Earlier quoted context omitted.
You'd think that with a proper background rendering thread, they could get away with a retained scene graph maintained via dirty bits. But obviously, I'm missing something: what is it about the DOM that makes changes so expensive that they have to be batched via a virtual one?
It has to calculate layout, while the virtual DOM does not.
Can't it batch layout calculations like is typically done in a retained scene graph? You don't do the layout calculations on each change as they occur!
Is it an artifact of the DOM API? In WPF, they have to maintain two sizes because of this: a set size (if specified) and a layout computed size that is filled when layout computations are done in batch. This adds some complexity (e.g. ActualWidth is not always equal of width, and so on), but the perf is pretty good.
Re: Ember's Glimmer Engine
#105Earlier quoted context omitted.
It has to calculate layout, while the virtual DOM does not.
Can't it batch layout calculations like is typically done in a retained scene graph? You don't do the layout calculations on each change as they occur! Is it an artifact of the DOM API? In WPF, they have to maintain two sizes because of this: a set size (if specified) and a layout computed size that is filled when layout computations are done in batch. This adds some complexity (e.g. ActualWidth is not always equal o…
There is a SO post on this:
http://stackoverflow.com/questions/21109361/why-is-reacts-co...
Some points:
> Dirty checking is slower than observables because you must poll the data at a regular interval and check all of the values in the data structure recursively.
You don't have to poll your dirty bits! When you dirty something, you put it into a dirty list/set. You only re-render if your dirty list/set is not empty, clean deeper elements before shallow elements, and its quite optimal.
> A virtual DOM is nice because it lets us write our code as if we were re-rendering the entire scene.
Totally: they are basically turning a retained model into a not-so-slow immediate model, which is a nice programming abstraction, but it is not a performance win over an efficient retained model.
> DOM operations are very expensive because modifying the DOM will also apply and calculate CSS styles, layouts. The saved time from unnecessary DOM modification can be longer than the time spent diffing the virtual DOM.
So layout calculations in normal DOM aren't incremental, but are made incremental in virtual DOM? Assuming this isn't related to batching, it sounds like the concrete DOM is just a bad implementation? Or does the virtual DOM avoid doing layout calculations at all and somehow magically fixes the layout when things change?
Re: Ember's Glimmer Engine
#106Earlier quoted context omitted.
Demo of embers original performance with dbmon along with angular and react https://www.youtube.com/watch?v=z5e7kWSHWTg
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.
Would take with salt. The angular version doesn't use track by 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/
Re: Ember's Glimmer Engine
#107Earlier quoted context omitted.
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.
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.
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?
Re: Ember's Glimmer Engine
#108Earlier quoted context omitted.
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 It's too little too late for me. I wouldn't want to touch anything Ember or anything from the authors.
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.
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...
* 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.
Re: Ember's Glimmer Engine
#109Earlier quoted context omitted.
React Version: http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/
do you have a source for this?
Re: Ember's Glimmer Engine
#110The 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.
Yeah, I am not huge fan of Ember but this is genuinely nice to have and I noticed it.