Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

Post reply on HN
Print view View original

51–60 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#51

Post by somerando7 »

jordache wrote: post #27
Lowkeyloki wrote: post #11

First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library,…

>functional and composable way components can be designed and implemented. Ughh.. that's the point of all modern FE frameworks... You are putting that description on a pedestal as if that is a unique property of React.

Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^)

Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?

Re: Virtual DOM is pure overhead (2018)

#52

Post by toastal »

adzm wrote: post #25
Lowkeyloki wrote: post #11

First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library,…

Note that even jsx is not technically required, and on occasion I've clenched my teeth and written non-jsx react code for some one-off demos.

Weird. I feel like clenching my teeth using JSX and a compilation step when a function suffices.

Re: Virtual DOM is pure overhead (2018)

#53

Post by antjanus »

somerando7 wrote: post #51
jordache wrote: post #27

Earlier quoted context omitted.

>functional and composable way components can be designed and implemented. Ughh.. that's the point of all modern FE frameworks... You are putting that description on a pedestal as if that is a unique property of React.

Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^) Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?

I personally enjoy using Angular, but yeah, Vue is your best bet!

Re: Virtual DOM is pure overhead (2018)

#54

Post by oraphalous »

I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced.

Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child elements that need updating - inspecting the DOM in various ways so as to determine the component's current state.

If your component needed to affect components higher up, or sibling to the current instance - then your application is often doing a search of the DOM to find the nodes.. and yes if you architect things well then you could avoid a lot of these - but let's face it, front end developers weren't typically renown for their application architecture skills.

In short - the DOM was often used to store state. And this just isn't a very efficient approach.

This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail.

As far as I'm aware React and its VDOM approach was the framework that deserves the credit for changing the culture of how we thought about state management on the frontend. That newer frameworks have been able to build upon this core insight - in ways that are even more efficient than the VDOM approach is great - but they should pay homage to that original insight and change in perspective React made possible.

I feel this article and many of the comments here so far - fail to do that - and worse, seem to be trying to present React's claim of the VDOM faster than the DOM as some kind of toddler mistake.

Re: Virtual DOM is pure overhead (2018)

#55

Post by brobdingnagians »

somerando7 wrote: post #51
jordache wrote: post #27

Earlier quoted context omitted.

>functional and composable way components can be designed and implemented. Ughh.. that's the point of all modern FE frameworks... You are putting that description on a pedestal as if that is a unique property of React.

Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^) Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?

I love Vue.js. I've never really caught onto the JSX stuff. If you have ".Vue" files then you get nice separation of the template html, methods, and the scoped styling. The Javascript syntax is pretty straightforward, and the templates just add nice directives like v-if, v-for, etc. I think it look pretty clean and is fairly easy for JS developers to pick up. Integration into a project is pretty straightforward as well. We have a webpack installation that pulls in the Vue files and bundles everything and it is quite clean.

Re: Virtual DOM is pure overhead (2018)

#56

Post by blotter_paper »

fouc wrote: post #34
Lowkeyloki wrote: post #11

First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library,…

Isn't it possible to skip the compile step in react, by using hyperscript instead of JSX?

Hyperscript isn't necessary. React's jsx is just getting transformed into React.createElement() calls which you can do manually: https://reactjs.org/docs/react-without-jsx.html

Re: Virtual DOM is pure overhead (2018)

#57

Post by arthurdenture »

ec109685 wrote: post #35
spankalee wrote: post #5

This is absolutely true. Virtual DOM diffs do a huge amount of unneeded work because in the vast majority of cases a renderer does not need to morph between two arbitrary DOM trees, it needs to update a DOM tree according to a predefined structure, and the developer has already described this structure in their template code! A large portion of JSX expressions are static, and renderers should never waste the time to…

One thing nice about React is that it can take care of quoting for you depending on the method call the jsx template translates into (attribute, value, element name). String templates doesn’t have that nice property.

lit-html is context-aware and safe, just like JSX. It's not a raw string templating library.

https://lit-html.polymer-project.org/guide/template-referenc...

Re: Virtual DOM is pure overhead (2018)

#58

Post by acemarke »

adzm wrote: post #25
Lowkeyloki wrote: post #11

First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library,…

Note that even jsx is not technically required, and on occasion I've clenched my teeth and written non-jsx react code for some one-off demos.

Jason Miller's `htm` library is a great alternative: nearly-JSX syntax via template strings, with no compilation needed:

https://github.com/developit/htm

Re: Virtual DOM is pure overhead (2018)

#59

Post by tylerhou »

Lx1oG-AWb6h_ZG0 wrote: post #48

Dan Abramov has a great thread about this here: https://mobile.twitter.com/dan_abramov/status/11209717954258... . In particular, I find this argument really persuasive: > Time slicing keeps React responsive while it runs your code. Your code isn’t just DOM updates or “diffing”. It’s any JS logic you do in your components! Sometimes you gotta calculate things. No framework can magically speed up arbitrary code. In my…

> In my experience, as your app grows, the amount of time you spend on dom reconciliation becomes negligible compared to your own business logic. In this case, having a framework like React (especially with concurrent mode) will really help improve perceived user experience over a naive compiled implementation.

In my experience, the exact opposite occurs. If there is ever any heavy computation I need to do, I usually try spawn a web worker or offload it to the server. In contrast, as your app tree grows reconciliation costs grow (super?)linearly, and more importantly there is (currently) no way to offload reconciliation.

Re: Virtual DOM is pure overhead (2018)

#60

Post by EGreg »

I have always said:

Angular is diffing the model

React is diffing the view

That’s all. Better to just skip the diffing usually, and grab references to elements and update them when certain events happen. It’s really ok!

Post reply on HN