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

Re: Virtual DOM is pure overhead (2018)

#161

Post by IceDane » Tue, Jun 29, 2021, 4:10 PM UTC

rendall wrote: post #133

KronisLV wrote: post #105

Earlier quoted context omitted.

> Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue. This makes me feel conflicted. With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech. With JS libraries it's the wild west once again and befor…

> With React/Angular/Vue you're given a stable base upon which to build new components and logic Oh you sweet summer child. Wait until you see the multilayered horror of devs insisting on styled components because they never spent the time to learn the specificity rules of CSS; their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves; suggesting t…

This is an extremely cringey, gatekeepy reply. It's just missing a "it's nothing personal, kiddo".

Good on you if you prefer writing everything from scratch. Some of us have shit to do and goals to meet and we'd rather spend our time on building actual functionality than reinvent the wheel for the nth time.

Re: Virtual DOM is pure overhead (2018)

#162

Post by madacol » Tue, Jun 29, 2021, 4:15 PM UTC

mvolfik wrote: post #155

strangescript wrote: post #113

Time and again it has been proven that the number one metric for success of a language or framework is developer experience. Javascript was a meme language, but it was easy to use and highly accessible. Now its everywhere, in everything, including places it has no business being. React has become that for frontend development. React is easier to use than Svelte. I got excited when I first learned of it, but its awkwa…

Where do you find React easier to use than Svelte? I did mostly backend and simple pure-JS frontends before and never picked up react because of how long the tutorial was and how messy the tooling felt. Svelte was a breeze in both of this and I didn't experience larger issues yet, so I'm curious what I'm missing out on?

I'd argue that Svelte is easier for beginners or simple stuffs, the tutorial is miles better than react's.

But of course, for complex stuffs, react's bigger community becomes to the rescue with many edge-cases solutions

Re: Virtual DOM is pure overhead (2018)

#163

Post by mtm7 » Tue, Jun 29, 2021, 4:16 PM UTC

FractalHQ wrote: post #77

The most important part of Svelte, to me, is that it allows me to write web applications in the most elegant possible way. The compiler first approach means we get to choose whatever syntax we want to make the whole process as enjoyable as possible. The most brilliant part of Svelte was the decision to stay as close to JavaScript as possible, so anyone who knows JS, HTML, and CSS knows svelte. Importing any vanilla J…

> The DX is so good that building things is incredibly fun, intuitive, and headache free. I can’t emphasize enough how empowering it is.

Yes! I've been a full-time React developer for about 5 years, and recently had the chance to try Svelte on a small pet project. I'd written most of the project in React and had a free weekend so I figured what the heck – let's see how it'd look in Svelte. :)

Within a day most of the functionality was in place, and the code just felt _beautiful_. I loved that it removed so much boilerplate (wrote some examples here[0]), and some of the React headaches (like using "Undo" in a controlled ) were just gone. The ergonomics (especially the built-in stores, error handling, and ) were lovely surprises!

I'm really bullish on it and so happy it's starting to grow.

[0]: https://mtm.dev/react-vs-svelte

Re: Virtual DOM is pure overhead (2018)

#164

Post by midrus » Tue, Jun 29, 2021, 4:17 PM UTC

ferdowsi wrote: post #33

I feel like nobody is asking: what is the point of all this performance chasing with frontend frameworks? You might get a millisecond here or there. So what? In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application. It's almost always some type of network communication issue, be it the database stalling or static assets not being served. Where JS rendering mi…

Tell that to my cpu when using the new reddit

Re: Virtual DOM is pure overhead (2018)

#165

Post by dceddia » Tue, Jun 29, 2021, 4:23 PM UTC

madeofpalk wrote: post #55

jchw wrote: post #41

Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works. If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compile…

> this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.

> No one actually really cares about it, and its not the reason why people use React.

This is probably true today, especially for newcomers, but the article is from 2018 and the context of the time period is significant here, I think.

Having used React since around 2015, there definitely was an aire of "React is fast because of the Virtual DOM!" and it was one of its big selling points early on. I can remember reading this article and nodding along, but reading it now evokes more of a sense of "I remember when VDOM mattered". I think around that time was maybe the tail end of VDOM being a big selling point, and this article might've even precipitated that, to a degree.

As React's usage has grown, I think the significance of VDOM as a feature has fallen by the wayside in favor of things like "everyone uses React so we use React too." The competition between frameworks at the moment seems less about performance and more about their approaches and tradeoffs.

Re: Virtual DOM is pure overhead (2018)

#166

Post by macspoofing » Tue, Jun 29, 2021, 4:23 PM UTC

aidenn0 wrote: post #146

mumblemumble wrote: post #124

Earlier quoted context omitted.

> React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim. My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars. Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you'…

I wrote a react application and VDOM overhead was so high that I had to cut down what parts of the UI were rendered to just what was on-screen at any given time. Performance was just barely okay on a desktop and completely unusable on an Android phone. Not using react made everything work amazingly fine. Granted this was an application with fairly low amounts of DOM manipulation (popup things when the user clicks on…

>I wanted to use React because the code was so much cleaner and concise, but it was just way too slow.

I've been hard on React in other places in this thread because I agree with the premise of the article that VDOM is not free and that the value of React is not in performance over raw DOM manipulations, but rather in code organization.

Having said that, React isn't bad either. That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React. It's been a few years since I did any meaningful React development, but back when I did, React code was simple enough that it wasn't hard to understand and trace trough, or profile. I guess I'm curious, what the bottleneck was.

Re: Virtual DOM is pure overhead (2018)

#167

Post by flyingchipmann » Tue, Jun 29, 2021, 4:29 PM UTC

slumdev wrote: post #157

blacktriangle wrote: post #112

Earlier quoted context omitted.

Honest question, why? The problem one always runs into in client side apps is you need various features like conditionals and looping when rendering your HTML. This has lead to a proliforation of templating languages that half-assedly implement these features. Moving to using a full programming language for generating your HTML removes the need for janky inconsistant templating languages.

Browsers support HTML and JS (and a few other things not relevant to this point). Neither HTML or JS on its own will do what you're describing. HTML doesn't allow binding to a data source. JS doesn't allow you to write HTML declaratively. So, people build abstractions. If an abstraction ever became popular enough and futureproof enough, there could be a case for supporting it natively. But I don't know of anything th…

What are you talking about? That's the exactly the purpose of jsx - manipulate html with straightforward javascript. and jsx is just a wrapper for React.createElement().

Re: Virtual DOM is pure overhead (2018)

#168

Post by Panther34543 » Tue, Jun 29, 2021, 4:32 PM UTC

I spent part of last Saturday going through the Svelte tutorial, and I really liked the framework.

I then was looking at recommendations for building fully functional web apps, and the official recommendation was to use "Svelte Kit". I began the tutorial for that, and was surprised at how the philosophy of that framework seemed to completely contradict the core Svelte framework. It was extremely odd and unappealing, and killed my newly gained enthusiasm for Svelte.

Has anyone built full web apps without Svelte Kit (previously Sapper)?

Re: Virtual DOM is pure overhead (2018)

#169

Post by shadofx » Tue, Jun 29, 2021, 4:35 PM UTC

datavirtue wrote: post #99

ferdowsi wrote: post #33

I feel like nobody is asking: what is the point of all this performance chasing with frontend frameworks? You might get a millisecond here or there. So what? In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application. It's almost always some type of network communication issue, be it the database stalling or static assets not being served. Where JS rendering mi…

Batteries. Inefficient JS aggregates to result in significant energy use. If I'm building a desktop app that will run in the browser then it isn't much of an issue, but if that same app is expected to run on a mobile device then my wild JavaScript kludges start to really matter.

So it's no surprise why devs choose React over anything less plush. They test on desktop, test on their plugged in cellphones, and call it good.

Re: Virtual DOM is pure overhead (2018)

#170

Post by dimitrios1 » Tue, Jun 29, 2021, 4:35 PM UTC

IceDane wrote: post #161

rendall wrote: post #133

Earlier quoted context omitted.

> With React/Angular/Vue you're given a stable base upon which to build new components and logic Oh you sweet summer child. Wait until you see the multilayered horror of devs insisting on styled components because they never spent the time to learn the specificity rules of CSS; their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves; suggesting t…

This is an extremely cringey, gatekeepy reply. It's just missing a "it's nothing personal, kiddo". Good on you if you prefer writing everything from scratch. Some of us have shit to do and goals to meet and we'd rather spend our time on building actual functionality than reinvent the wheel for the nth time.

Your reply is the real cringe here. "I got shit to do" is no excuse to toss aside quality and craftsmanship. And you misread their argument they didn't say write everything from scratch, they said write a simple leaner version, but the argument is most people lack even basic problem solving skills. If you spend all your day glueing things together, you forget how to design and build them yourself. Sure you can stack the blocks in order, and make a really tall tower, but how soon until it falls over, or how will it withstand the first gust of air. That's the larger point. And this isn't "gatekeepy" this is reality. As software continues to eat the world, and most of us are forced increasingly to rely on these shitty apps and interfaces, it could do a little good to the world if Software engineering as a discipline took on a little more professionalism. So less of the "I got shit to do" and "move fast and break things" mentality, and more of the "lets do this right" mentality. Good engineers can write a little utility that solves a problem wonderfully for their context or scope, and still get their shit done and meet their goals.