Virtual DOM is pure overhead (2018) • Hacker News Board

Re: Virtual DOM is pure overhead (2018)

#161

Post by ttfkam » Wed, Feb 01, 2023, 7:11 PM UTC

ironmagma wrote: post #145

ttfkam wrote: post #120

Earlier quoted context omitted.

Are you calling a C compiler overhead as well? Ahead of time compilation is not runtime overhead, and for users of the web, runtime and network latency are all that matters with regard to the perception of speed.

Mental overhead matters much more than performance overhead to most applications. The whole plot of JS is that it’s easy enough to work with that it overpowers any performance limitations. Svelte invents a completely new execution model for JS which adds overhead.

I honestly don't believe you've actually used Svelte even in an experimental context to make such a comment. Go check out the tutorial on the Svelte site and get back to us.

It's literally >90% just HTML, CSS, and JS. The last <10% is split between stores, if- and each-blocks, and data binding syntax. If you don't know HTML, CSS, and JS as a web developer, I don't know what to tell you. If you do, the notion that Svelte has a substantial mental overhead compared to any other web framework—especially React—is utterly ludicrous.

Re: Virtual DOM is pure overhead (2018)

#162

Post by hbrn » Wed, Feb 01, 2023, 7:12 PM UTC

ttfkam wrote: post #112

fabiospampinato wrote: post #85

Earlier quoted context omitted.

> Even SolidJS hasn't quite crept the performance Inferno has managed to achieve. I see Solid to the left of Inferno in that benchmark, though they are very close indeed. Solid's code looks weird in its own ways I guess, but it looks less hacky/hand-optimized to me. Inferno seems to use less memory though, which seems interesting. Solid isn't fully memory optimized though, it could beat Inferno with more memory optim…

Yep, Solid is among the fastest but requires more cognitive overhead. Svelte requires very little over and above HTML and JS while still being closer to Solid in performance than React, Vue, or Angular. And the latest interactions of React and its ecosystem have both high cognitive overhead AND lackluster speed. At least Angular is opinionated. React is just a YOLO ball of yarn for large codebases.

Can you expand a bit more on cognitive overhead in Solid? What are the examples?

Re: Virtual DOM is pure overhead (2018)

#163

Post by scotty79 » Wed, Feb 01, 2023, 7:15 PM UTC

dgb23 wrote: post #155

scotty79 wrote: post #83

Earlier quoted context omitted.

Can we please go back to templates compiled directly to php files that just get executed?

PHP has many other problems. React was literally developed by arguably the largest PHP shop. In terms of performance specifically you do a ton of unnecessary, redundant work, because you recreate the whole world and throw it away again with every request. PHP does it’s best to be a fast language and mitigate this issue, but it can’t really solve it.

That's because there's no PHP in the front-end. ;)

Re: Virtual DOM is pure overhead (2018)

#164

Post by Rapzid » Wed, Feb 01, 2023, 7:15 PM UTC

SebastianKra wrote: post #98

Calling the VDOM pure overhead is a strong statement when there are patterns that are more difficult to express in Svelte because of how it manages views. Once a view is created, it can't be processed by JS. It can't be stored in an array or an object. You can't count or individually wrap children. This makes it harder to create flexible API's [1]. The question is: are we willing to give up the expressivity of React…

MobX and chill.

Seriously though, modelling the FE business logic entirely outside the view library and just wiring it up to observables where necessary is extremely refreshing, maintainable, and FAST.

Re: Virtual DOM is pure overhead (2018)

#165

Post by scotty79 » Wed, Feb 01, 2023, 7:18 PM UTC

postalrat wrote: post #148

scotty79 wrote: post #83

Earlier quoted context omitted.

Can we please go back to templates compiled directly to php files that just get executed?

Why php and not JavaScript?

Yeah, I can take JavaScript. After all it's 21 century.

So from now on we only use template engines that compile templates directly to simple .js files. Agreed?

Re: Virtual DOM is pure overhead (2018)

#166

Post by PaulDavisThe1st » Wed, Feb 01, 2023, 7:18 PM UTC

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

Re: Virtual DOM is pure overhead (2018)

#167

Post by TheRealPomax » Wed, Feb 01, 2023, 7:18 PM UTC

Note that a virtual DOM is pure overhead if you already have a real DOM to work with.

That's kind of the ignored superpower of a framework like React, which makes the virtual DOM the authority: there might be a DOM, but there also might not be. Whether the virtual DOM reflects to a real DOM, or native UI, or Qt, or an ASCII terminal interface, it doesn't care.

This is also the part that most web devs have the hardest time with: React (and some other frameworks) are not web frameworks. They really are just UI frameworks, that happen to (also) work in a browser. Even if they were original born out of a web need way back when.

Re: Virtual DOM is pure overhead (2018)

#168

Post by brap » Wed, Feb 01, 2023, 7:20 PM UTC

vbezhenar wrote: post #149

I can't trade TSX for any text templates. Being able to write tags and having them syntax-checked with types support is indispensable. I wish that those frameworks embrace TSX rather than trying to drag users to the dark past.

IMO, TSX really is beautiful, I can’t see how it can be beat. I’m not a big fan of how React handles state and effects, but TSX itself is joy to work with.

Re: Virtual DOM is pure overhead (2018)

#169

Post by c-smile » Wed, Feb 01, 2023, 7:22 PM UTC

zozbot234 wrote: post #151

ttfkam wrote: post #103

Earlier 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…

Element.insertAdjacentHTML() appears to fix the event handlers issue (and similar issues with element state), since unlike innerHTML it does not replace the element it's being used on.

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 class rather than on individual element.

And there is a slight difference between Sciter's components and React ones. Sciter component is real DOM element:

    const foobar = document.$("form.foobar");

    foobar instanceof FooBar; // true

That allows to use JSX/vDOM as Web Components as React Components - bests of two worlds.

Re: Virtual DOM is pure overhead (2018)

#170

Post by PaulHoule » Wed, Feb 01, 2023, 7:26 PM UTC

stillkicking wrote: post #150

PaulHoule wrote: post #138

Earlier quoted context omitted.

A classic example of: "you had one problem, now you have ten problems". That's fine if you aren't writing any unit tests or trying to fix bugs with the debugger. If context are in use you might have some 'simple' system with 10 components that shows 150 components in the React component viewer most of which are worthless context blocks that are just there to waste your attention and probably the CPU and memory of you…

>React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways So let's first back up and recognize that this earlier statement was flat out wrong. React does provide a systematic answer for this. Second, not only does it have a systematic answer, but it memoizes quite well because React will not re-render children if the `children` prop is identical to the previous ren…

No, the troubles building an SPA have a lot to do with the complexity of your app.

If you are building the average mobile app it is often really clear when you are writing code what needs to be updated in the UI when a piece comes in.

If you are building something more like Adobe Photoshop or Eclipse the user has the ability to open up property sheets and create other UI elements that could be affected by data structures anywhere in the application. In that case you need some systematic answer such as components registering to get notifications when something happens but you can run into some pretty bad problems such as having to hang on to references which keep the garbage collector from working as expected. My first SPA was a knowledge graph editor in GWT that I managed to get correct (though it probably leaked memory a little) and since then I haven't known whether to laugh or cry about the state of SPA frameworks.

As for the manuals I think the React manuals are some of the worst in the business. I have no problems finding answers in the Java manual or the Python manual or the Postgres manual or many others but the React manual baffles me.