51–60 of 62 posts
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.
Earlier quoted context omitted.
> 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…
> Why waste time implementing and “reducing it even further” and not just implement it in the browser? 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 conce…
Oh wow. You just described the existing imperative DOM APIs, haven't you? Inflexible implementation wasting everyone's time. When is the last time you used actual DOM APIs? The story of web development has been: "JFC, these things are impossible to work with, let's waste time creating actual useful abstractions on top of them".
> 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.
You know what one of the goals of jQuery was? To become a disappearing library. As browser APIs got better and better, the need for jQuery would diminish and it would disappear, becoming just a browser API.
Why would browsers implement querySelector and querySelectorAll? We already had it in jQuery and it was working well.
Why would browsers implement fetch? We already had jQuery.ajax, axios, superfetch and dozens of others, and they were working well.
Why would browsers implement ? We already have and they are working well.
> it is easier to build one library than implement the same spec in all major browsers.
It doesn't mean we should freeze the spec in the same state it was in 1998.
> The concepts of Components, State, Context, Thunks, Fibers, Plugins, etc. are very important differentiators between various virtual DOM APIs.
None of those refer to actual APIs. Those are parts of internal implementations or additional implementations/additions/APIs on top of virtual dom.
We are talking about one thing specifically: we need a browser-native declarative DOM API with browser-native DOM-diffing that wouldn't require us implement it in userland.
The rest like thunks, state management, plugins, whatever can be provided by actual libraries on top of actual built-in high performant built-in virtual-dom API.
Because the browser knows infinitely more about what's happening to the DOM than userland libraries and has access to infinitely more optimisations. All userland code needs to do is to tell the browser: this and that changed.
Funnily enough, browser implementors are now spending considerable amounts of time implementing CSS Containment [1] (emphasis mine):
--- quote ---
Browser engines can use that information to implement optimizations and avoid doing extra work when they know which subtrees are independent of the rest of the page.
Imagine that you have a big HTML page which generates a complex DOM tree, but you know that some parts of that page are totally independent of the rest of the page and the content in those parts is modified at some point.
Browser engines usually try to avoid doing more work than needed and use some heuristics to avoid spending more time than required. However there are lots of corner cases and complex situations in which the browser needs to actually recompute the whole webpage.
--- end quote ---
Wow. Browsers (and browser implementors) actually want the developers to tell them what exactly changes on the page so that they don't do extra work. And wow, you can actually implement the same spec in all major browsers (eventually).
So why not virtual DOM?
> this whole standardization and reimplementation exercise will be rendered a giant waste of time.
So what you're saying is essentially this: new things are hype, DOM APIs should never get updated because who cares about the needs of developers.
[1] https://blogs.igalia.com/mrego/2019/01/11/an-introduction-to...
Earlier quoted context omitted.
> Why waste time implementing and “reducing it even further” and not just implement it in the browser? 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 conce…
> because those standardized APIs will stay with us for much longer than they will be useful, wasting everyone's time. Oh wow. You just described the existing imperative DOM APIs, haven't you? Inflexible implementation wasting everyone's time. When is the last time you used actual DOM APIs? The story of web development has been: "JFC, these things are impossible to work with, let's waste time creating actual useful a…
Existing DOM APIs are very simple, low level and unopinionated. A pleasure to build libraries on. That's what durable platform APIs should look like.
It is very easy to build virtual dom and importantly other DOM management paradigms on top of those low level APIs.
The same can not be said about virtual dom - it's a very opinionated, very rigid paradigm. I know because I built FRP UI libraries based on Snabbdom and on native DOM APIs. The latter is much simpler to deal with and more performant. Virtual DOM only works well if that's exactly what you want. It has no place among browser APIs, at least not in any recognizeable shape or form.
Regarding performance, the whole point of the virtual dom is that the diffing engine does not know which elements changed or didn't change. It gets a new virtual subtree and has to diff it with the previous one. The browser would be doing all the same diffing work, just closer to the metal. But we will soon be able to do the same with just WASM.
Earlier quoted context omitted.
> because those standardized APIs will stay with us for much longer than they will be useful, wasting everyone's time. Oh wow. You just described the existing imperative DOM APIs, haven't you? Inflexible implementation wasting everyone's time. When is the last time you used actual DOM APIs? The story of web development has been: "JFC, these things are impossible to work with, let's waste time creating actual useful a…
> Oh wow. You just described the existing imperative DOM APIs, haven't you? Inflexible implementation wasting everyone's time. Existing DOM APIs are very simple, low level and unopinionated. A pleasure to build libraries on. That's what durable platform APIs should look like. It is very easy to build virtual dom and importantly other DOM management paradigms on top of those low level APIs. The same can not be said ab…
I built something on native APIs and on userland APIs. Native APIs are more performant.
Really? That surprises you?
> The browser would be doing all the same diffing work, just closer to the metal.
Exactly my point
Earlier quoted context omitted.
Could you elaborate on what Piet and Druid are, perhaps with a few links? I assume you don't mean the esolang[0]. [0] https://esolangs.org/wiki/Piet
Sure, sorry about the initial omissions. https://github.com/xi-editor/druid https://github.com/linebender/piet
And no worries, it's very easy to forget not everyone is introduced!
Anyway, to actually engage with your point: I can see the appeal of an all-Rust framework: good typing system + high performance (both in speed and low memory use, ideally) sounds fantastic!
So out of curiosity: how do you think hot swapping would be handled? I'm asking this who has not dived into Rust at all and only observed it with interest from a distance.
For starters, I understand Rust has fairly slow compilation times, no? Or is that only true for optimized code and do we have fast debug options?
Similarly, hot swapping requires maintaining state. With JS that's not too difficult because you don't worry about memory layout: as long as the high-level structure and names are the same the code works fine (it just kills the JIT optimizations).
With WASM, that goes out the window: add or remove a field to your struct and all offsets change. Rust may guarantee no memory leaks, but that is not the same as guaranteeing that a snapshot of the memory state of one Rust program works on a different one.
I guess some kind of "export to/import from JavaScript based representation" glue code that runs every hot reload could work, but that sounds like it could really freeze the browser when hot-reloading the big frameworks.
[0] https://www.youtube.com/watch?v=4YTfxresvS8 would be funny if I forgot to include links myself at this point :p
Earlier quoted context omitted.
Sure, sorry about the initial omissions. https://github.com/xi-editor/druid https://github.com/linebender/piet
Thanks! Looks very interesting, going to watch the video about Druid linked in the README.MD later[0]. And no worries, it's very easy to forget not everyone is introduced! Anyway, to actually engage with your point: I can see the appeal of an all-Rust framework: good typing system + high performance (both in speed and low memory use, ideally) sounds fantastic! So out of curiosity: how do you think hot swapping would…
Why virtual DOM is not a part of browser APIs is anyone’s guess at this point.
>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.
I agree though, nothing that requires a place in web standards at all.
Earlier 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.
The things a VDOM get you is a simpler interface than the browser DOM, with an often faster comparison than the browser actually provides. There have been significant real browser DOM improvements since React came out, but I'm pretty sure an optimized VDOM in WASM could be faster because of issues of interaction with the real/full browser DOM. There are also side effects wrt the full/real DOM in practice. I agree tho…
But there are other non-virtual-DOM ways to manage DOM state efficiently and in a maintainable manner. For example, my own library uses Observables to drive precise DOM updates and works with trees holding real (not virtual) DOM elements, so it doesn't need to do any diffing at all: https://github.com/raquo/Laminar
I don't think it's a given which of these techniques would be faster, it depends heavily on the particular use case and the implementation of diffing (for virtual DOM) and Observables (for my pattern). If both are well optimized I'd expect virtual DOM to lose in a lot of cases.
Earlier quoted context omitted.
The things a VDOM get you is a simpler interface than the browser DOM, with an often faster comparison than the browser actually provides. There have been significant real browser DOM improvements since React came out, but I'm pretty sure an optimized VDOM in WASM could be faster because of issues of interaction with the real/full browser DOM. There are also side effects wrt the full/real DOM in practice. I agree tho…
Well... faster than what exactly? You have to do the virtual DOM pattern (generating new DOM state and then diffing with old state) with virtual elements. You can't compare proper virtual dom to using real DOM elements instead of virtual ones in a virtual dom pattern, it wouldn't make any sense. But there are other non-virtual-DOM ways to manage DOM state efficiently and in a maintainable manner. For example, my own…