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

121–130 of 136 posts

Re: Ember's Glimmer Engine

#121

Post by ivanb »

Rapzid wrote: post #97

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

Yes. They should. Currently DOM works in an imperative, immediate way. Kind of like a Basic program or OpenGL immediate mode. After a write to a property you are guaranteed to get the same value back after you read the property. The dependent properties are also guaranteed to be updated immediately. Surprisingly, this imperative way of programming is actually not efficient at all because subsequent writes and reads may cause reflow.

To prevent this the programming model should be changed. There are two ways that I can imagine.

- Introduce "DOM batching mode". In this mode remove the immediate mode guarantees. If you specify an element width you are no longer guaranteed to read it back until the layout occurs. So store your intermediate element width somewhere if you want to use it. Of course you don't need to specify batching mode for all the DOM tree. Just the majority of it that doesn't require custom layout.

- IIUC the majority of times that you need to perform multiple reads and writes of the DOM properties is due to special layout requirements. In some cases CSS layout may not be enough. There should be an API that allows to specify custom layout strategy for a parent DOM element. JavaScript should be fast enough. The additional benefit is that we would no longer need to wait for e.g. Flexbox adoption. Just roll your own.

It is obvious that we are trying to turn HTML into a GUI framework. So let's do it properly.

The problems we are facing with DOM have already been solved by multiple game engines and GUI frameworks.

Re: Ember's Glimmer Engine

#122

Post by throwaway41597 »

peterhunt wrote: post #85
ralmidani wrote: post #73

Earlier quoted context omitted.

It's unfair and one-sided because you cannot sue Facebook for infringing an unrelated patent, but if Facebook sues you for an unrelated patent, you will lose your rights if you try to assert (defensively) that their patent is invalid. In other words, you can never sue or even defend yourself against a Facebook lawsuit. For a more balanced approach to patents, see the GPL, Mozilla Public License, or Apache 2.0 License…

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

A discussion started by an actual lawyer about the same license used for an other project is here: https://news.ycombinator.com/item?id=8901357

He doesn't agree with your interpretation. The license is very clear in that everything a company would typically do to /defend/ against a patent suit brought by Facebook will terminate its patent rights on React.

Let me quote the second paragraph (added line formating for readability), the (b) part is the broadest I think:

    The license granted hereunder will terminate, automatically and without notice,
    for anyone that makes any claim (including by filing any lawsuit, assertion or
    other action) alleging

    (a) direct, indirect, or contributory infringement or
    inducement to infringe any patent: (i) by Facebook or any of its subsidiaries or
    affiliates, whether or not such claim is related to the Software, (ii) by any
    party if such claim arises in whole or in part from any software, product or
    service of Facebook or any of its subsidiaries or affiliates, whether or not
    such claim is related to the Software, or (iii) by any party relating to the
    Software;

    or (b) that any right in any patent claim of Facebook is invalid or
    unenforceable.
So why word it like users cannot defend against Facebook while Facebook doesn't intend to be a claimant?

Re: Ember's Glimmer Engine

#123

Post by Cthulhu_ »

ralmidani wrote: post #107
slacka wrote: post #100

Earlier quoted context omitted.

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?

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.

Re: Ember's Glimmer Engine

#124

Post by itsbits »

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...

Re: Ember's Glimmer Engine

#125

Post by itsbits »

I am not as smart as lot of guys here..but What exactly is Glimmer's additional optimisations other than Virtual DOM?...

What exactly does this mean "the programming model is equivalent to render every time, but we take advantage of the declarative nature of Ember's APIs to reduce work."??

Re: Ember's Glimmer Engine

#126

Post by flexterra »

itsbits wrote: post #125

I am not as smart as lot of guys here..but What exactly is Glimmer's additional optimisations other than Virtual DOM?... What exactly does this mean "the programming model is equivalent to render every time, but we take advantage of the declarative nature of Ember's APIs to reduce work."??

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}}

Re: Ember's Glimmer Engine

#127

Post by ubertaco »

ivanb wrote: post #121
Rapzid wrote: post #97

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

Yes. They should. Currently DOM works in an imperative, immediate way. Kind of like a Basic program or OpenGL immediate mode. After a write to a property you are guaranteed to get the same value back after you read the property. The dependent properties are also guaranteed to be updated immediately. Surprisingly, this imperative way of programming is actually not efficient at all because subsequent writes and reads m…

> Introduce "DOM batching mode". In this mode remove the immediate mode guarantees. If you specify an element width you are no longer guaranteed to read it back until the layout occurs. So store your intermediate element width somewhere if you want to use it. Of course you don't need to specify batching mode for all the DOM tree. Just the majority of it that doesn't require custom layout.

Some sort of DOM-like buffer[1] that you could render into and then "flush"/insert, maybe?

[1] https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...

Re: Ember's Glimmer Engine

#128

Post by itsbits »

flexterra wrote: post #126
itsbits wrote: post #125

I am not as smart as lot of guys here..but What exactly is Glimmer's additional optimisations other than Virtual DOM?... What exactly does this mean "the programming model is equivalent to render every time, but we take advantage of the declarative nature of Ember's APIs to reduce work."??

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.

Re: Ember's Glimmer Engine

#129

Post by ralmidani »

Cthulhu_ wrote: post #123
ralmidani wrote: post #107

Earlier quoted context omitted.

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?

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.

I'm not making excuses, but comparing a custom solution like Bloomberg terminals to a versatile platform like the Web is not a fair comparison.

Despite the inherent performance disadvantages, people are stepping up and working on pushing Web applications to run faster. The efforts of the Ember team and others should be commended rather than ridiculed.

Re: Ember's Glimmer Engine

#130

Post by drogus »

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.

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.

Post reply on HN