41–50 of 62 posts
Bump allocation sounds a lot like heap allocation. Is a "bump" a small heap?
>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?
So the statement you have quoted is slightly confused (although a very common confusion). People think of the DOM as being essentially an AST of the document tree. The "Virtual DOM" is seen as kind of scratch pad for that tree: update the "virtual DOM" and the AST is automatically brought into sync. At that point the "DOM" (as Document Object Model) loses any meaning because it is no longer that object model (with it's completely insane API) that we all love to hate.
Why are these AST diffs being done in userland libraries when it could be done by the browser itself. Because you already have a DOM. Why would you possibly want another programmatic interface? ;-) Though tongue in cheek, this is really historically the answer. The API you've got is the API you've got.
Providing an ability to get the document as an AST and to update it by furnishing a new AST would be wonderful. But you've got to get it by the standards committee.
Edit: I should point out that browsers used to support XSLT which allows you to transform the document declaratively based on the AST. Not sure if any browser still supports it though...
Earlier quoted context omitted.
There is enough differentiation in virtual DOM designs[1] that I don't think implementing a lowest common denominator that is flexible enough to support competing strategies would be useful. Being a browser API it would need to be a rather timeless, low level design. Essentially, we already have that – the imperative DOM API. With WASM the performance gap between libraries and native browser code will be reduced even…
> Essentially, we already have that – the imperative DOM API. With WASM the performance gap between libraries and native browser code will be reduced even further. Why waste time implementing and “reducing it even further” and not just implement it in the browser? > Just some examples that come to mind First bullet point is relevant for internals mostly, little bearing on actual API. Second bullet point is nearly ide…
Because the browser should not offer inflexible implementations of complex, highly opinionated and currently overhyped paradigms, because those standardized APIs will stay with us for much longer than they will be useful, wasting everyone's time.
We're only talking about virtual dom here because it's a popular concept with good library implementations. We don't need to reimplement it in all major browsers because we already have it working well.
Even aside from that, it is easier to build one library than implement the same spec in all major browsers. Moreover, library designs compete with each other, and can be improved faster than APIs baked into a browser which will have to be maintained in a backwards compatible manner for more than a decade.
> First bullet point is relevant for internals mostly, little bearing on actual API.
The concepts of Components, State, Context, Thunks, Fibers, Plugins, etc. are very important differentiators between various virtual DOM APIs. Either the presence or absence, let alone the specific design of those concepts strongly affects the API surface and what users can do with it and how. Don't mistake React's API for some kind of standard.
Once the hype inevitably moves on from virtual DOM to whatever the next declarative UI paradigm will be (e.g. FRP with precision DOM updates) this whole standardization and reimplementation exercise will be rendered a giant waste of time.
>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?
React is currently working on figuring out how to adapt their API to allow asynchronous updating of the DOM. If the virtual DOM was standardized already, then the React team would have been very limited in how they could implement asynchronous rendering.
>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?
Virtual DOM is needed to enable a programming model where in each UI iteration, you return the entire UI tree anew. Actually creating a new DOM tree anew would be terribly wasteful, and you might lose lots of state (e.g. half entered text or selected text or something) so instead you do dom-diffing. For some reason, people consider that model to be more hip than the normal one where you take care of updating yourself…
A huge benefit of the virtual dom model as used in React is that you don't need to have separate code paths for the initial render of a widget and updating part of a widget. I can't count the number of times I've seen pre-React widgets coded to assume most attributes would never change, had bugs in updating some uncommonly-updated attributes, or gave up on having separate initial-render/update code paths by throwing away the widget's entire DOM and re-rendering on most attribute changes. With the React way, there's one code path for initial render and updating, so it doesn't take any special effort to make every attribute efficiently update-able. A whole category of bugs disappeared in codebases I've worked on that adapted React.
>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?
Virtual DOM is needed to enable a programming model where in each UI iteration, you return the entire UI tree anew. Actually creating a new DOM tree anew would be terribly wasteful, and you might lose lots of state (e.g. half entered text or selected text or something) so instead you do dom-diffing. For some reason, people consider that model to be more hip than the normal one where you take care of updating yourself…
We can debate if that's good or not, but it's not about "ease of use". Neither is it necessarily more wasteful. It's a different paradigm.
The benchmark has some old versions of Angular (2) and the legacy AngularJS (1.x) - how do the benchmarks look with a more recent version (v7)?
How exciting. One of the great things about React is that it's just as much a pattern as a library, and with Rust macros and v-dom it should be rather easy to build something similar to JSX in Rust (with the proper Rust-isms of course). Can't wait for Rust to rule the web.