Why virtual DOM is not a part of browser APIs is anyone’s guess at this point.
Fast, Bump-Allocated Virtual Doms with Rust and Wasm
31–40 of 62 posts
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#32Why virtual DOM is not a part of browser APIs is anyone’s guess at this point.
It is! They call it the DOM, for short.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#33>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?
Because virtual DOM is not the only way to achieve efficient DOM updates, and even within the concept of virtual DOM there could be many different ways to achieve efficient diffing (e.g. React vs Snabbdom). There is nothing special about a particular virtual DOM spec to deserve a place in web standards.
Web standards could specify an API (which is very simular across all virtual dom inplementations) and let browsers chise their own implementations and optimisations.
Since the browser has full access to the entire object model, and memory layouts, and dom optimisations, and..., and..., it’s a shame that we have to write code that is the prerogative of the browser.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#34Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#35Bump allocation sounds a lot like heap allocation. Is a "bump" a small heap?
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#36Why virtual DOM is not a part of browser APIs is anyone’s guess at this point.
It is! They call it the DOM, for short.
Uh no, actually virtual DOM would be a great addition to the browser. What is there is an imperative api, the big win of virtual DOM is the specification of the UI is the specification of all possible updates to the ui in an efficient manner. It would be nice for the browser to include an api method that takes VDOM data-structure, diffs it and applies the changes in native land vs implementing this in user land.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#37>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?
HTML is declarative, but it's also a string. It is faster to manipulate the DOM to make the changes you want than to generate an HTML string and ask the browser to parse it.
A virtual DOM allows you to use declarative _code_ instead of a string to get the same benefits as declarative HTML, but avoids the overhead of HTML by manipulating the DOM directly under the hood.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#38Bump allocation sounds a lot like heap allocation. Is a "bump" a small heap?
Bump allocation is a strategy for building an allocator; where that allocator's memory is is irrelevant to the algorithm itself. Most of the time, that is the heap, but you could write an allocator that takes a bunch of stack memory and hands it out too.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#39Earlier quoted context omitted.
Because virtual DOM is not the only way to achieve efficient DOM updates, and even within the concept of virtual DOM there could be many different ways to achieve efficient diffing (e.g. React vs Snabbdom). There is nothing special about a particular virtual DOM spec to deserve a place in web standards.
Web standards could specify an API (which is very simular across all virtual dom inplementations) and let browsers chise their own implementations and optimisations. Since the browser has full access to the entire object model, and memory layouts, and dom optimisations, and..., and..., it’s a shame that we have to write code that is the prerogative of the browser.
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 further. Focusing on that has the benefit of lifting all boats, not just a particular DOM building paradigm that has been popular recently.
[1] Just some examples that come to mind:
- logic that decides when to update an element vs when to create a new one (including but not limited to having the concepts of components, thunks, deciding to look at class names, ability to move nodes, etc.)
- design of lifecycle methods and hooks, as well as any performance-oriented optimizations such as asynchronous / delayed rendering, short circuiting logic, etc.
- handling of props vs attributes vs reflected attributes
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#40Earlier quoted context omitted.
Web standards could specify an API (which is very simular across all virtual dom inplementations) and let browsers chise their own implementations and optimisations. Since the browser has full access to the entire object model, and memory layouts, and dom optimisations, and..., and..., it’s a shame that we have to write code that is the prerogative of the browser.
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 identical in all virtual doms and similar lifecycle hooks exist in WebComponents (which squandered the opportunity to introduce a declarative API).
Third bullet point is valid, but the main problem isn’t the difference between library APIs. The main problem is that there is no browser API, so everyone has to reinvent the wheel. A simple {attrs: {}, props: {}} would render the differences moot (or you would have very thin wrappers on top for your favorite syntax)