Ember's Glimmer Engine • Hacker News Board

Re: Ember's Glimmer Engine

#91

Post by mixonic » Wed, Mar 04, 2015, 1:37 AM UTC

msane wrote: post #89

mixonic wrote: post #4

Glimmer is a revolutionary improvement in Ember's rendering performance. I'm incredibly excited by the progress and promise being realized in Tom and Yehuda's PR. For more context, here are a few quick slides from the EmberConf keynote: http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf They, and the PR, tell the whole story about what is happening in the dbmonster demo. We expect this work to land in Ember…

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.

Re: Ember's Glimmer Engine

#92

Post by rxcfc » Wed, Mar 04, 2015, 1:44 AM UTC

cellis wrote: post #84

But will it work with Emblem? Also how does this affect FastBoot?

Emblem compiles to Handlebars so it will gain all of the benefits of Glimmer. FastBoot is only concerned with the initial render which is done on the server. Glimmer is concerned with updates so it will not directly affect FastBoot but will work with it.

Re: Ember's Glimmer Engine

#93

Post by nathansobo » Wed, Mar 04, 2015, 1:49 AM UTC

steveklabnik wrote: post #16

Quote from wycats during the talk: > Because our template language is declarative, we can do this at compile time. "This" being determining which portions of the DOM will never change, and so only needing to analyze the portions that might.

Is the talk online?

Re: Ember's Glimmer Engine

#94

Post by spyc3r » Wed, Mar 04, 2015, 1:49 AM UTC

randomguy7788 wrote: post #90

ng2 will have similar optimizations i believe. interesting times in the 2.0 framework wars! lol i kidddd

Angular 2.0 has similar optimizations but sacrifices backwards compatibility. Glimmer is still backwards compatible with Ember 1.x.

Re: Ember's Glimmer Engine

#95

Post by rxcfc » Wed, Mar 04, 2015, 1:58 AM UTC

nathansobo wrote: post #93

steveklabnik wrote: post #16

Quote from wycats during the talk: > Because our template language is declarative, we can do this at compile time. "This" being determining which portions of the DOM will never change, and so only needing to analyze the portions that might.

Is the talk online?

Not yet. It just happened and will need to be post-processed. I'm pretty sure all EmberConf talks will eventually end up online.

Re: Ember's Glimmer Engine

#96

Post by peterhunt » Wed, Mar 04, 2015, 2:01 AM UTC

ralmidani wrote: post #87

peterhunt wrote: post #85

Earlier quoted context omitted.

This is a common misinterpretation of this clause. There's been a lot of discussion at length here: https://news.ycombinator.com/item?id=8985722

I read that discussion. The patent grant is very asymmetrical. Why should an entity using React be vulnerable to being sued by Facebook for unrelated patents and be unable to challenge those patents?

IANAL and I have nothing else to add to the discussion here other than adding the context that Facebook hates patent trolls and doesn't really compete on technology, so even if your interpretation is correct (which I don't believe it is) it'd be purely defensive anyway.

Re: Ember's Glimmer Engine

#97

Post by Rapzid » Wed, Mar 04, 2015, 2:02 AM UTC

Will these virtual DOM/diff'ing optimizations be built into the browsers at some point? Seems like they should/would.

Re: Ember's Glimmer Engine

#98

Post by seanmcdirmid » Wed, Mar 04, 2015, 2:04 AM UTC

Rapzid wrote: post #97

Will these virtual DOM/diff'ing optimizations be built into the browsers at some point? Seems like they should/would.

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?

Re: Ember's Glimmer Engine

#99

Post by woah » Wed, Mar 04, 2015, 2:14 AM UTC

seanmcdirmid wrote: post #98

Rapzid wrote: post #97

Will these virtual DOM/diff'ing optimizations be built into the browsers at some point? Seems like they should/would.

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.

Re: Ember's Glimmer Engine

#100

Post by slacka » Wed, Mar 04, 2015, 2:14 AM UTC

rxcfc wrote: post #57

pikzen wrote: post #54

Earlier quoted context omitted.

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 seco…

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.