[flexterra]

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.

  <div class="container"> <-- this won't change
    <h1>Hello World</h1> <-- this won't change
    <div>{{name}} <-- this might change </div>
  </div>

[itsbits]

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.

[iamstef]

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.

[itsbits]

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.

[drogus]

This is irrelevant to the changes from the PR. Manual DOM updates are not managed by HTMLBars anyway, regardless of the rendering algorithm.

That said, I think that binding classes (like `class={{foo}}`) and updating it through HTMLBars is a safer way to do it, comparing to direct DOM manipulation.