I remember when react was new and the reason why everyone should use it was because of its virtual dom and lack of typescript.
Now everyone is saying the virtual dom isn't the point and advocating typescript.
Virtual DOM is pure overhead (2018)
31–40 of 344 posts
Re: Virtual DOM is pure overhead (2018)
#32So glad to see this article, I've long wondered how this "virtual DOM is faster" myth got accepted as gospel when clearly it's pure overhead, compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps).
Can't speak to the svelte approach due to inexperience with it, but good to see this myth challenged - react.js is fine but I worry there's been a cargo cult mentality around it, that it's The One True Modern Way To Do Web Apps, when really it's a tradeoff that involves some extra layers and performance baggage, and like any tool you need to weigh the pros and cons.
Re: Virtual DOM is pure overhead (2018)
#33This 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…
Typo -- you didn't close your fragment on the JSX.
Re: Virtual DOM is pure overhead (2018)
#34First, 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?
Re: Virtual DOM is pure overhead (2018)
#35This 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.
Re: Virtual DOM is pure overhead (2018)
#36I remember when react was new and the reason why everyone should use it was because of its virtual dom and lack of typescript. Now everyone is saying the virtual dom isn't the point and advocating typescript.
Seriously, who actually said lack of typescript was a plus for React ever? That seems like a non-sequitur.
Re: Virtual DOM is pure overhead (2018)
#37I remember when react was new and the reason why everyone should use it was because of its virtual dom and lack of typescript. Now everyone is saying the virtual dom isn't the point and advocating typescript.
Seriously, who actually said lack of typescript was a plus for React ever? That seems like a non-sequitur.
A lot of people back when every blog was comparing Angular (read not angularjs) and Reactjs.
Re: Virtual DOM is pure overhead (2018)
#38To me, React is more about Developer Experience. The ease to reason about the app is far much more important than anything else.
The problem with Svelte, is that, it sounds "words louder than action".
You can learn from React documentation. Instead of throwing a bunch of concept to the dev face, it brings out the WHY of ReactJS with real code.
Teaching users right from documentation is the best way to introduce a library/framework for user to really experience with the tech.
Re: Virtual DOM is pure overhead (2018)
#39So glad to see this article, I've long wondered how this "virtual DOM is faster" myth got accepted as gospel when clearly it's pure overhead, compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps). Can't speak to the svelte approach due to inexperience with it, but good to see this myth challenged - react.js is fine but I worry there's been a ca…
tell me about it! Or, heaven forbid, just make the user get the entire html page rendered from server after every click like it's 2003 or 2004!
Re: Virtual DOM is pure overhead (2018)
#402 things I'm not seeing in the article or in the comments so far: 1) The virtual DOM is an abstraction that allows rendering to multiple view implementations. The virtual DOM can be rendered to the browser, native phone UI, or to the desktop. 2) The virtual DOM can, and should, be built with immutable objects which enables very quick reference checks during the change detection cycle.
On point #2, ClojureScript not only provides immutability out of the box, but also has libraries for replacing JSX with the same stuff everything else is built with. It's an insanely beautiful way to work with React.
Reagent is probably the best UI dev experience I’ve found yet.
A quick blog post explaining why for anyone curious about reagent: https://www.mattgreer.org/articles/reagent-rocks/