3 ms·

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 t

by _bxg1 8y ago

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

augustl 8y ago
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.
- madeofpalk 8y ago
  this is just replacing framework a with framework b. It's not a "native, declarative DOM templating API yet"
  - augustl 8y ago
    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.
    - madeofpalk 8y ago
      ....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.
    - _bxg1 8y ago
      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.
      - augustl 8y ago
        Flutter/Hummingbird will be writing DOM elements, so it's not just an opaque WebGL texture.
WorldMaker 8y ago
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.

by _bxg1 8y ago

augustl 8y ago

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.

madeofpalk 8y ago
this is just replacing framework a with framework b. It's not a "native, declarative DOM templating API yet"
- augustl 8y ago
  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.
  - madeofpalk 8y ago
    ....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.
  - _bxg1 8y ago
    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.
    - augustl 8y ago
      Flutter/Hummingbird will be writing DOM elements, so it's not just an opaque WebGL texture.

WorldMaker 8y ago

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.