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

331–337 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#331

Post by norswap »

peterhunt wrote: post #153

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…

As a seasoned engineer (compiler background), but beginner in frontend, I'm curious aboutthe lack of expressive power that Svelte incurs.

Could you (or someone) characterize things that are hard to do in Svelte?

Re: Virtual DOM is pure overhead (2018)

#332

Post by intrasight »

MrJohz wrote: post #327
intrasight wrote: post #324

Earlier quoted context omitted.

For some reason I thought the virtual DOM was a native feature of the browser, in the form of the DocumentFragment class, and had nothing to do with diffing. But you are saying that it's just a concept, and is implemented by frameworks such as React, and involves the two steps of generating and diffing. I'll still ask why. Is it just something that React needs to do?

Using some sort of VDOM is still pretty standard in most frameworks, it's definitely not just React doing this. The motivation is generally an attempt to model an application as a function `(state) => DOM`. This is probably similar to the `renderMyModel` function in your example: take state in, and return what the document should look like given this state. The problem with this is that if you rerendering the entire…

>rerendering the entire DOM

No, just rerendering the viewport that was affected by the model. I have no need to re-render headers, footers, menus, etc.

>DOM itself has state

No. The viewport has no state. It's just a transformation on the model. And I don't place any event listeners in my viewport DOM.

> every time the user presses a key or moves their mouse

Of course not - and I wouldn't expect an application to be updating the model on key presses.

Re: Virtual DOM is pure overhead (2018)

#333

Post by SebastianKra »

norswap wrote: post #331
peterhunt wrote: post #153

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…

As a seasoned engineer (compiler background), but beginner in frontend, I'm curious aboutthe lack of expressive power that Svelte incurs. Could you (or someone) characterize things that are hard to do in Svelte?

Once a data is transformed into a view in Svelte, you can't do anything with it in JS. For example, a component can't iterate over the children in a slot [1].

This is limiting when designing generic Component-APIs.

As an extreme example: In React, I could trivially define a tabbed interface by mixing strings, JSX, and components, without imposing any DOM-structure. The component that reads this definition could use it to build a tabbed-view on mobile, and a master-detail-view on desktop. ...or it could build a table of contents. When defining the tab names, I can mostly use strings, but fall back to JSX if necessary. Importantly, the API is completely independent from the implementation.

    const tabs = [
       { name: "Tab 1", icon: , content: MainTab },
       { name: Tab with bold text, icon: , content: SecondTab },
    ] 

    return
[1]: https://github.com/sveltejs/svelte/issues/5381

Re: Virtual DOM is pure overhead (2018)

#334

Post by yencabulator »

peterhunt wrote: post #287
ricardobeat wrote: post #279

Earlier quoted context omitted.

What makes the svelte template language less expressive than JSX in your view? Props and expressions will look similar in both (minus the useXX ceremonies), and the rest is all loops and if conditions. Writing simple inline conditions in JSX is painful, so it already starts with a negative score.

The template language doesn't compete with JSX. It competes with JSX + JavaScript, which is far more expressive.

Svelte's template language can evaluate JavaScript just fine. Svelte's template language doesn't need to compete with JSX + JavaScript, Svelte + JavaScript is what competes with JSX + JavaScript.

Re: Virtual DOM is pure overhead (2018)

#335

Post by JadedBlueEyes »

satvikpendem wrote: post #225
peterhunt wrote: post #153

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…

Isn't SolidJS supposed to be like React (in that it has JSX, hooks etc) but without the VDOM? So I guess that would sidestep your point #2, but curious to hear your thoughts on it. Personally I don't use Svelte, Vue, Solid etc simply due to the (lack of) library support compared to React. For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparab…

> reached for react-three-fiber, there simply isn't something comparable in the non-React world.

This came out a year ago now.

https://svelthree.dev/ https://github.com/vatro/svelthree

Svelte, Vue, etc. all have plenty of awesome libraries - you just need to be aware of them.

Re: Virtual DOM is pure overhead (2018)

#336

Post by bruce343434 »

ko27 wrote: post #176
pweissbrod wrote: post #129

Earlier quoted context omitted.

Not for large DOMs. And for websites which Don't require support for low internet bandwidth this is optimizing for the wrong problem

Network latency is your no.1 bottleneck for every modern device, everything else is a distant second. Also you can optimize everything, but you can't make MPAs navigate without a network roundtrip.

Mpa still is faster so spa must have another type of bottleneck

Re: Virtual DOM is pure overhead (2018)

#337

Post by divan »

dangoor wrote: post #136
divan wrote: post #128

Is there any discussion in webdev community whether using typesetting engine from 80s is even a good idea for modern performant UI apps? Or it's just taken for granted and never questioned?

I don't think that perspective is fair to modern browser engines. The additions of flexbox and grid layouts took them beyond just typesetting, I think (not to mention all of the work on JS engines, providing APIs for a whole bunch more device functionality, etc.) So it's true that there's still a "typesetting engine from the 80s" in there, but there's also a powerful layer of app functionality built-in as well. It's…

As a thought experiment, imagine that we would have started with Lotus 1-2-3/Excel type spreadsheets instead of formatted text. I believe that we would develop tons of layers of abstraction on top of this too, in order to make cells and functions to emulate UI framework. It would probably work as well, and had some weird quirks related to the cell-based nature of this super-powerful engine. Yet, the question remains - would it be a good foundation for modern UI apps?

To me, most of the issues with web apps stem from the fact that foundation is just not built for that task. Like these weird selection issues, where you move cursor 1 pixel more to the bottom and it selects the whole visible area instead of text - that doesn't even make sense. Or jumping page and blocks all over the page while it loads fonts and stylesheets. Sure, we build more hacks on top of existing hacks to mitigate this, but that's just duct taping with complexity, not the engineering.

Post reply on HN