Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ember's Glimmer Engine

github.com

Post reply on HN
Print view View original

131–136 of 136 posts

Re: Ember's Glimmer Engine

#131

Post by iamstef »

itsbits wrote: post #128
flexterra wrote: post #126

Earlier quoted context omitted.

Ember's templates allows the framework to determine which portions of the DOM will never change, and so only needing to analyze the portions that might. Hello World {{name}}

Wow..Thanks a lot..Now I understand the sentence.. But I think now this may force us to use more handlebars. Manipulations in didInsertElement may get affected as well. Like updating classes which I sometimes prefer doing in hooks like click, didInsertElement.

Additionally, rather then having a "virtualDOM" we build a tree of the dynamic data. This is more or less diff'ed similarly to how the virtualDOM is diff'ed.

But where it get interesting is when it comes to actual DOM interaction. To create DOM, we use document fragments + cloneNodes, but for granular updates we utilize property/attribute/textContent updates. When used correctly, this combination turns out to be very fast.

As a bonus, we are typically able to utilize the browsers built-in XSS and sanitization (or just lack of parsing) rather then having to implement this slowly in JavaScript ourselves.

Ultimately, I am extremely happy with how the various front-end frameworks keep pushing the envelope. Getting faster, easier to use, and more secure. Ultimately regardless of the framework the ecosystem moving forward benefits the end users the most.

Re: Ember's Glimmer Engine

#132

Post by zeppelin »

itsbits wrote: post #124

What kind of DOM model Ember is using like React.DOM?...I don't think handlebars create DOM Objects?...great to see How Ember accepted the change and implemented that...

Handlebars doesn't, but HTMLBars does indeed [generate][1] DOM objects from Handlebars AST - it's basically another compile step. Check out section 2 and 3.

[1](https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE...)

Re: Ember's Glimmer Engine

#134

Post by itsbits »

iamstef wrote: post #131
itsbits wrote: post #128

Earlier quoted context omitted.

Wow..Thanks a lot..Now I understand the sentence.. But I think now this may force us to use more handlebars. Manipulations in didInsertElement may get affected as well. Like updating classes which I sometimes prefer doing in hooks like click, didInsertElement.

Additionally, rather then having a "virtualDOM" we build a tree of the dynamic data. This is more or less diff'ed similarly to how the virtualDOM is diff'ed. But where it get interesting is when it comes to actual DOM interaction. To create DOM, we use document fragments + cloneNodes, but for granular updates we utilize property/attribute/textContent updates. When used correctly, this combination turns out to be very…

Thanks Stef. This explains a lot. Its great that Ember responded with best way after many started comparing with the performance lag of Ember. I was lil' skeptical when you declared this in December, but now I am looking fwd for the release.

Re: Ember's Glimmer Engine

#135

Post by itsbits »

zeppelin wrote: post #132
itsbits wrote: post #124

What kind of DOM model Ember is using like React.DOM?...I don't think handlebars create DOM Objects?...great to see How Ember accepted the change and implemented that...

Handlebars doesn't, but HTMLBars does indeed [generate][1] DOM objects from Handlebars AST - it's basically another compile step. Check out section 2 and 3. [1]( https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE... )

I see that HTMLBars is building more of Document fragments rather a single DOM tree. Would be interesting to check if all these document fragments are independent to each other like 1000's of HTMLBar views inserted directly into the Ember Application as siblings rather as a tree. There will be lot of memory involved than when you use a single DOM tree. isn't it?

Re: Ember's Glimmer Engine

#136

Post by itsbits »

jashkenas wrote: post #60

For the curious, here's a port of the Dbmonster demo to a simple Underscore template — the kind of base-level rendering strategy you might start with in a Backbone app. (And vintage 2009 technology.) http://jashkenas.github.io/dbmonster/ Edit: To head off grumbling at the pass — It would also be easy to do a slightly less-simple version that keeps the flickering impossible-to-read popups open (putting redundant toolt…

you might want to look into this timelines

https://news.ycombinator.com/item?id=9149475

Post reply on HN