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

201–210 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#201

Post by flyingchipmann »

slumdev wrote: post #189
flyingchipmann wrote: post #167

Earlier quoted context omitted.

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().

JSX isn't HTML. Is it truly less cognitive burden to have a language that looks like HTML but isn't? With properties changed because they're reserved words? And with control statements from other languages supported inline? If someone gave me a language that looks like Lisp but with car and cdr renamed to something else, is that really making my life easier?

What cognitive problem do you have? It's just syntax sugar to let you easily manipulate the dom tree. Generating dom nodes and intertwined logic becomes trivial when you have jsx. If u want a list u can do dataList.map(data -> SomeComponent); or do ifTrue ? Component1 : Component2; or even use a function to return conditionally with a switch.

JSX is not HTML because it need to blend logic and HTML seamlessly. React is not static site builder, it's an app builder. If your project doesn't need this sure go ahead. Otherwise are there much better choices?

Re: Virtual DOM is pure overhead (2018)

#202

Post by kgr »

When we designed to UI library for FOAM in 2011 at Google, we did extensive benchmarking, and discovered that DOM calls were very slow and that we could greatly improve performance by batching them. Yes, in the end, you still need to make DOM calls to update the DOM, but you were better off forming all of your DOM's html on the JS side and then just make one call to element.innerHTML = myHTML and then hookup listeners if necessary. The JS to C++ bridge was very slow, and so you were better off to make one large call and then have C++ parse your HTML and build all of the DOM itself than you were to make many small DOM calls adding each element and attribute value individually. However, I was recently writing a document on the performance advantages of FOAM's virtual DOM, but rather than just assert the fact without proof, I wrote some benchmarks to demonstrate... that it is in fact no longer faster. As a result, we're replacing FOAM's UI library, called U2, with a new non-virtual DOM library called U3.

Re: Virtual DOM is pure overhead (2018)

#203

Post by flyingchipmann »

icedchai wrote: post #187
flyingchipmann wrote: post #167

Earlier quoted context omitted.

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().

I find JSX is only straightforward for the simple cases. Often you wind up with unreadable, convoluted garbage because someone was trying to be clever with too many ternary operators, etc.

If you can refactor JSX with simpler js code then you should do that. It's just js expression. If u find reading js expression is harder than all those custom operators in other template languages, you can always switch.

Re: Virtual DOM is pure overhead (2018)

#204

Post by infogulch »

macspoofing said elsewhere ITT:

> DOM mutations are not the expensive thing, it's the final render.

This is the crux of the issue: Updating the DOM will immediately rerender the page, even if there are additional changes that need to be made at the same time. So library/framework authors twist themselves into pretzels trying to work around the browser automatically doing all this unnecessary extra work that developers don't even want. Clearly it's a DOM api deficiency; there is no api to 'make these 15 changes scattered across the DOM all at once', instead each individual change causes a cascade of wasted effort repeated until the last change is applied OR developers take the nuclear option and just replace the whole damn page with a completely new DOM on every frame. Insanity. The solution seems obvious to me:

Browsers should introduce a transactional DOM api that is only rendered after the transaction is 'committed'. It could be full-on transactions like a real DB or something simpler like a double-buffered frame swap. This would be relatively easy to retrofit into JS apps and frameworks and would enable them to effortlessly avoid a huge amount of wasted effort on the part of the browser.

Re: Virtual DOM is pure overhead (2018)

#205

Post by recursive »

moritzwarhier wrote: post #149
px43 wrote: post #103

Maybe this is a dumb question from a JS muggle, but the thing that kills me about this whole movement to virtual/shadow DOM is that it's made the "ctrl+f" search useless on more and more websites. Is there a nice way to hook the search function to actually look inside elements that haven't been swapped in yet? If so, more people should be using it.

Never had this problem really (doesn't mean that it doesn not exist). Is shadow DOM a thing outside of SVGs? For sure it's not used by React, Vue etc. MDN is telling me that the upcoming Web component spec uses it though, so maybe libraries like LitElement use it too? Sites using React or Vue all seem to be searchable using standard CTRL-F for me.

I suspect this is a reference to the specific feature infinite/virtual scroll. The DOM nodes are only materialized when you scroll near them. CTRL-F is not able to find text that isn't currently in the DOM. If you scroll it into view, it suddenly starts working.

Re: Virtual DOM is pure overhead (2018)

#206

Post by recursive »

nobody0 wrote: post #45
jeswin wrote: post #11

For 95% of apps, Svelte's custom syntax is pure cognitive overhead making little difference to the performance of the app.

This, that's why React was a bit revolutionary at its time. No customized template dsl. Just speak JS.

JSX is exactly a customized template DSL. It's not a particularly difficult one, but that's exactly what it is.

Re: Virtual DOM is pure overhead (2018)

#207

Post by SquareWheel »

throwaway894345 wrote: post #127
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…

> 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. JavaScript is the wrong example. It didn't succeed on merit, but because it was the sole language available for the web platform for the entire history of the web until recently and even now it enjoys significant "unfair" advantages (browsers only expose DOM API…

While never widely adopted, VBScript was able to be ran in script tags in Internet Explorer.

Re: Virtual DOM is pure overhead (2018)

#208

Post by davidwparker »

protonimitate wrote: post #74
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…

> React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output. Svelte has been around for a few years now - and I've yet to se…

I'd say that the NY Times is pretty good for "at scale".

Re: Virtual DOM is pure overhead (2018)

#209

Post by rendall »

jakelazaroff wrote: post #151
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…

The purpose of styled components (or CSS modules or what have you) isn't to deal with specificity. It's to deal with collisions between what are essentially global variables.

I don't think you and I disagree. Use the tool appropriate for the job. If the team doesn't have the discipline or will to use the cascade as intended, definitely, better to have a bloated CSS-in-JS that at least is usable, rather than a bloated cascade that people are afraid to use.

Re: Virtual DOM is pure overhead (2018)

#210

Post by madhadron »

kgr wrote: post #202

When we designed to UI library for FOAM in 2011 at Google, we did extensive benchmarking, and discovered that DOM calls were very slow and that we could greatly improve performance by batching them. Yes, in the end, you still need to make DOM calls to update the DOM, but you were better off forming all of your DOM's html on the JS side and then just make one call to element.innerHTML = myHTML and then hookup listener…

In my personal experiments, I ended up using document fragments. I wasn't doing FRP, just classic MVC, but a view (which was a JavaScript object) had a reference to the DOM elements it was responsible for. If it needed to replace them, it created a document fragment, did anything that needed to be done in there (including having children redraw) and then swapped out that fragment. This gave very nice performance.
Post reply on HN