If I see html in a javascript file, I boycott the codebase
Virtual DOM is pure overhead (2018)
201–210 of 337 posts
Re: Virtual DOM is pure overhead (2018)
#202Earlier quoted context omitted.
innerHTML doesn't preserve event handlers. So you're either reassigning event handlers over and over or relying on delegate handlers everywhere. And while your statement makes intuitive sense regarding performance, actual measurements show clearly that idiomatic Svelte (and other modern frameworks) routinely beat VDOM-based efforts handily in their idiomatic cases and often even when folks jump through the performanc…
From what I know React does not register event handlers on individual nodes, but rather on root component. Then it uses virtual events from it’s pool in your callbacks.
Wow, I didn't know this! All that Synethetic stuff makes sense in retrospect...
I tried a quick google and didn't find any articles discussing it directly. Do you have any links to offer?
Thanks in advance!
Re: Virtual DOM is pure overhead (2018)
#203Earlier quoted context omitted.
None of the good frameworks really do any more DOM operations than any other. It's all about how you find out which set of DOM operations need to be done. Svelte does this with a compiler, Lit does it with tagged template literals, and a bunch do it with vdom. Calculating the vdom diff is pure overhead in that if you have better syntax (or a compiler) you can just skip it.
They don't because since React set the bar, any new framework that didn't solve the problem VDOM did in some way, was dead on arrival. If Svelte way is better at minimizing and batching DOM updates, they should probably argue and show that, not misrepresent what VDOM does (while blaming strawmanning on others no less).
> any new framework that didn't solve the problem VDOM did in some way, was dead on arrival.
Most frameworks before and after React were solving that problem one way or another.
The reason React won was that V = f(S) turned out to be most user-friendly solution. VDOM is exactly what Rich is saying: a means to efficiently implement V = f(S)
Vue/MobX are another, better iteration on the same idea. Svelte, arguably, is even better iteration.
Re: Virtual DOM is pure overhead (2018)
#204Reading this as a native developer is a bit like reading about alchemy or astrology - two fields with their own vast suite of terminology and internal logic that doesn't fully correspond to anything real ... ... only to find out that this stuff is actually real and is how a big chunk of the visible web actually works.
> native developer You probably haven't done any native UI as native UI uses exactly the same idiom. CWnd* parent = ... parent->appendChild( new EditBox() ); native UI also uses DOM concept, it is just that instead of child elements it uses term child windows or [Gtk]widgets or [ns]View s.
Come back when you know about HWND, boy.
Re: Virtual DOM is pure overhead (2018)
#205All abstractions are pure overhead. Let's code everything by hand by flipping bits in memory using a tiny magnetic needle.
This is not correct. Zero cost abstractions are not overhead. Some abstractions are zero cost abstractions. Thus, not all abstractions are pure overhead. More on zero cost abstractions here: https://stackoverflow.com/a/69178445/315168
I thought the second half would make it clear that I'm being sarcastic but clearly I'm wrong. Pendants gonna pedant I guess.
Re: Virtual DOM is pure overhead (2018)
#206So is the JS runtime. So why don't we just write apps in raw WASM?
Do you have benchmarks showing that it is worthwhile? Anyway, another idea is to ditch the entire DOM and render on the canvas.
That would mean we need no re-invent all form controls and other gui elements. And it's super hard. Desktop envs are trying to do it for decades and Electron just came and ate their lunch.
Re: Virtual DOM is pure overhead (2018)
#207All abstractions are pure overhead. Let's code everything by hand by flipping bits in memory using a tiny magnetic needle.
This is over-simplified: the overhead of an abstraction can be cancelled out by work or optimizations which you wouldn't have done without the abstraction. As a simple example, most Python programs are faster than the C code the same developer would have written in the same time because they have a rich library of optimized code and getting it working quickly means that they had more time to focus on algorithm-level…
Tough crowd today... My comment was a reference to xkcd: https://xkcd.com/378/
Maybe I should have made it more obvious by referencing the butterflies instead.
Re: Virtual DOM is pure overhead (2018)
#208I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…
Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from doing something you can do in React, and Svelte/Vue make getting into a codebase far more accessible for people with a wider range of skillsets.
The secondary effects of React's popularity have been a significant loss in emphasis on HTML and CSS skills over doing everything in JS which often results in div-soup that is less performant and less capable. HTML and CSS not being first class-citizens as they are in other frameworks means developers simply aren't encouraged to learn them nearly as well as they used to.
Front-end frameworks should not be just for front-end developers. They should be understandable and accessible to people who are not JS first and who come from backgrounds that are not purely engineering. In my experience it is much easier to teach someone familiar with design and HTML/CSS how to explore a Vue or Svelte codebase than a React one, and the JS devs I have worked with who fully learn these libraries have not complained about any limitations compared to React.
Re: Virtual DOM is pure overhead (2018)
#209Earlier quoted context omitted.
Again, in case of Sciter, event handlers are not the problem at all as it supports declarative event handlers: class FooBar extends Element { render() { return Foo Bar } // event handlers: ["on click at button.foo"](evt,button) { console.log("click on button foo") } ["on click at button.bar"](evt,button) { console.log("click on button bar") } } document.body.append( ); This approach will define event handlers on the…
I swear, folks and their JSX have me convinced they have Stockholm Syndrome. HTML+CSS in JS was always a pragmatic choice back in 2015, never the most elegant or most maintainable one. It's like the folks who refused to use anything but the DOM APIs when JQuery was sitting right there. Or who keep on using onclick handlers on their div tags instead of using perfectly good HTML tags like: JSX was never the best of any…
> We have better ones now.
Would you mind elaborating on what the better options are? The way I see it, there are a few possible alternatives:
1) Keep the same runtime DOM representation but use normal JS (something like `div({className: 'beer'})`). I know some people disagree, but I strongly believe that this is strictly worse than JSX because it's more verbose and far less readable.
2) Use string templates parsed at runtime. You lose most of the structure you get with JSX—static syntax checking, type safety, autocomplete, etc. Composition becomes a matter of string concatenation, which is possibly the worst way to do it. On top of that, you have to learn templating primitives specific to your templating library instead of being able to simply use what you already know: JavaScript.
3) Use templates parsed at compile-time. This removes most of the drawbacks of #2, but you still have to learn a new templating language and all of the idioms that come with it. On top of that, you're entirely dependent on IDE integration for syntax highlighting and autocomplete. (I realize that JSX has the same problem with custom syntax, but the tooling around it is ubiquitous by now.)
You could make a strong case for #3 being a good way to do templating, but there is no "best" or "most maintainable" option; there are only tradeoffs. JSX happens to have a really good set of tradeoffs going for it, and no one has (yet) created anything that's strictly better.
Re: Virtual DOM is pure overhead (2018)
#210Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast . Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base…
> They are all fast I would say they all can be fast. But try browsing the web on a low end Android device and tell me all sites are fast. To my mind the differentiator is how easy a framework makes it to shoot yourself in the foot. And React makes it very easy to re-render a huge swathe of your app when you've only changed one tiny element. React also needs to hydrate every element even when it isn't ever going to c…
> But try browsing the web on a low end Android device and tell me all sites are fast.
Holy smokes, that's more like a straw kaiju than a strawman. Obviously slow sites exist. That has almost nothing to do with the inherent overhead of recently created JS frameworks.