Hacker News Reader

Comment by _bxg1 | Hacker News Reader

What I don't get is why there isn't a native, declarative DOM templating API yet. It would be so much faster and would mostly eliminate the need for React and the like. Instead of a "virtual dom", a native "dom buffer".

View on HN

I have high hopes for Flutter/Hummingbird in that regard. When their renderer is implemented using web APIs, this is basically what we'll be getting.

this is just replacing framework a with framework b. It's not a "native, declarative DOM templating API yet"

Well, yes and no. They are implementing a rendering engine that supports things the web famously doesn't support, which includes fundamentals like UITableView from iOS. They are doing this by leveraging new APIs to access what browser layout engines do under the hood. So in that way, it generates native browser elements, and their API is declarative. So it's at least one abstraction layer below React and friends.

....no and no. The call was for a declarative interface to the DOM, like React, built into the browser. Flutter, being not built into the browser, is not that.

There are a million things that do this already - including Qt, which already works in WebGL. The point is to leverage the rest of the web's existing features while also getting declarative templates, not to create another Flash.

Flutter/Hummingbird will be writing DOM elements, so it's not just an opaque WebGL texture.

In terms of "dom buffer" there's a proposal in the works for the buffer "other half" to `window.requestAnimationFrame()` to queue DOM reads (where RAF is the place to queue DOM writes). So far I've heard it has the unimaginative and odd use of grammar name `window.requestAnimationFrameAfter()`.

Still would be too low level to easily work with though without a framework like React.

Reply on news.ycombinator.com