[deleted]
Virtual DOM is pure overhead (2018)
31–40 of 293 posts
Re: Virtual DOM is pure overhead (2018)
#32You could also say Python is pure overhead. You can write any Python programme in C, but more efficiently! C is faster, and therefore better. This article avoids the fact that declarative programming has proven to be more pleasant for most people. And React simply is fast enough for most use cases, even though it has a performance penalty compared to Svelte. The virtual DOM is an elegant optimisation that usually wor…
This article is specifically attacking a claim that I have heard before - that React is fast, because it works on virtual DOM, therefore it is faster than real DOM operations.
I have heard that claim myself before.
Re: Virtual DOM is pure overhead (2018)
#33I 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 might be a problem is at Facebook SPA scale, and the vast majority of apps are not Facebook.
Re: Virtual DOM is pure overhead (2018)
#34I will probably get downvoted as I am in minority who still believe Server Side Rendering is the best approach for most of the web with exceptions to some websites that require Single Page App functionality. I still think web would be best if you do SSR and then replace HTML DOM elements using frameworks like Stimulus Reflex or Hotwire. For millisecond interactivity you may want to write JS in a framework like Stimul…
about the monolith, the way data is growing in companies it will be impossible for one team to manage apps running for all data business domains. Businesses are not monoliths, they are organized in departments. The Supply chain department is the best suited for building supply chain services. The monolith might make technological sense but it’s making less and less business sense, just look at how quickly monolith systems like SAP or Salesforce are becoming obsolete.
Re: Virtual DOM is pure overhead (2018)
#35The most important line: > It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Declarative, state-driven UI development is a valuable abstraction. I really hope readers take this to heart, rather than the article title becoming a new meme.
They note right after that: > it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in The abstraction is valuable, but its cost need not be so high. I do wish they'd elaborate on what Svelte does differently though, or link to another post which elaborates.
The front page of their website proclaims Svelte to be "Cybernetically enhanced web apps", whatever that means.
The "Rethinking" post gives a little more detail:
> Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.
https://svelte.dev/blog/svelte-3-rethinking-reactivity
Seems like a great idea, if it can gain the critical mass required and build a community of people developing code for it.
Re: Virtual DOM is pure overhead (2018)
#36Okay, but - why does Rust frontend libraries (like Yew and Seed) use vdom instead of doing whatever Svelte does? Actually, is anyone else doing it the Svelte way?
Because VDOM is useful for writing declarative code. It's DX over UX - and most of the time it won't impact UX anyway.
Re: Virtual DOM is pure overhead (2018)
#37I've never really bought into this.
The diffing is mostly an implementation deatil that is abstracted away. React could check to see if props.items changed instead of the nonsense it does. If it still does that in 2021.
The thing is vue uses getters and setters that would trigger direct changes without needing to diff the entire tree. It could theoretically be really fast, but it still used a virtual dom, and it was around react speeds, give or take.
I am convinced that if react really wanted to, they could make optimizations to make it really close to svelte. I remember seeing a tweet by Evan You about vue3 being pretty much as fast svelte if not slightly faster.
The point is that speed, when it comes to front-end frameworks, is a weird thing. There are other factors that are much more important like tooling, stability, code style, dealing with animations, etc.
Things like svelte's compiler approach are much more interesting and unique selling points.
Re: Virtual DOM is pure overhead (2018)
#38If you don't need Virtual DOM then Web Components are a great idea for building reusable components that work with all frameworks, including React. You can even use JSX to build Web Components: https://github.com/wisercoder/uibuilder
Re: Virtual DOM is pure overhead (2018)
#39I will probably get downvoted as I am in minority who still believe Server Side Rendering is the best approach for most of the web with exceptions to some websites that require Single Page App functionality. I still think web would be best if you do SSR and then replace HTML DOM elements using frameworks like Stimulus Reflex or Hotwire. For millisecond interactivity you may want to write JS in a framework like Stimul…
The SPA movement has always seemed like a cargo cult to me. Yes, AJAX is handy and it was exciting when it came out. We used it to update search results when you changed a filter.
For 90-95% of applications, a single page app architecture with a front-end JavaScript framework running a bunch of application code and rendering output is overkill and you could write the same app in half the time using server side rendering.
Re: Virtual DOM is pure overhead (2018)
#40I 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…
It's not only performance, but cpu time and data volume.