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

211–220 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#211

Post by davidwparker »

Panther34543 wrote: post #168

I spent part of last Saturday going through the Svelte tutorial, and I really liked the framework. I then was looking at recommendations for building fully functional web apps, and the official recommendation was to use "Svelte Kit". I began the tutorial for that, and was surprised at how the philosophy of that framework seemed to completely contradict the core Svelte framework. It was extremely odd and unappealing,…

I built https://www.listenaddict.com/ with Sapper. It was a good experience. That said, all of my other apps are using Kit, and I'm finding that experience even nicer.

What did you find unappealing about Kit?

Re: Virtual DOM is pure overhead (2018)

#212

Post by rendall »

rendall wrote: post #133
KronisLV wrote: post #105

Earlier quoted context omitted.

> Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue. This makes me feel conflicted. With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech. With JS libraries it's the wild west once again and befor…

> 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…

Gah, at least it's not Salesforce. That year I spent in a Salesforce shop I earned gobs of money and nearly slit my wrists. I took the following year off. Learned to play ukulele. What a shitty platform. God bless the devs who thrive in it.

Re: Virtual DOM is pure overhead (2018)

#213

Post by cuddlecake »

dimitrios1 wrote: post #170
IceDane wrote: post #161

Earlier quoted context omitted.

This is an extremely cringey, gatekeepy reply. It's just missing a "it's nothing personal, kiddo". Good on you if you prefer writing everything from scratch. Some of us have shit to do and goals to meet and we'd rather spend our time on building actual functionality than reinvent the wheel for the nth time.

Your reply is the real cringe here. "I got shit to do" is no excuse to toss aside quality and craftsmanship. And you misread their argument they didn't say write everything from scratch, they said write a simple leaner version, but the argument is most people lack even basic problem solving skills. If you spend all your day glueing things together, you forget how to design and build them yourself. Sure you can stack…

It's kind of gatekeepy insisting on styled components being of lower quality than using pure CSS. Styled Components serves a specialized purpose of styling things on the web.

Maybe less elegant or performant in some respect than pure CSS, but with trade offs that some development teams will happily take.

I also hate the sentiment, that software development needs to adhere to some notion of purity or divine elegance. And yes, I'm using the word divine because people like the grandparent comment keep acting like CSS is the church. It may well be, for some, but there's a reason why CSS is getting new features continuously... Because it's not perfect for every purpose across every development department.

Talking about this makes me sick.

Re: Virtual DOM is pure overhead (2018)

#214

Post by lhorie »

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…

innerHTML has been slower than the DOM API for a few years. React had a big refactor at one point to rip out innerHTML logic precisely due to this. To make matters more interesting, the order of DOM API calls also mattered. In IE, building a DOM tree bottom up was significantly slower than building it top down (meaning, no large document fragments for you!). There are also a ton of other quirks: `.textContent = ''` being faster than removeChild, appendChild vs insertBefore vs replaceChild, childNodes random access, properties being faster than attributes (which is a rabbit hole of its own because SVG), cloneNode being faster but nigh unusable in a framework setting, orders of magnitude difference in performance due to data structure polymorphism...

Squeezing performance out of DOM manipulation is really tricky because the performance profile of pretty much everything changes frequently without rhyme or reason.

Re: Virtual DOM is pure overhead (2018)

#215

Post by dragonwriter »

recursive wrote: post #206
nobody0 wrote: post #45

Earlier quoted context omitted.

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.

> JSX is exactly a customized template DSL.

Yes, but its a template DSL for JavaScript (and TSX is one for TypeScript), not a template DSL for HTML.

Building JSX outputs JS, not HTML.

Re: Virtual DOM is pure overhead (2018)

#216

Post by rendall »

IceDane wrote: post #161
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…

This is an extremely cringey, gatekeepy reply. It's just missing a "it's nothing personal, kiddo". Good on you if you prefer writing everything from scratch. Some of us have shit to do and goals to meet and we'd rather spend our time on building actual functionality than reinvent the wheel for the nth time.

I hear you. It's a balance. You grab a library or open-source project, boom! Done. Move on dot org.

Except later, maybe your project needs some custom functionality. Now you have to dig into docs to see if it's possible, then deeper into the source code to see if you can monkey patch using something undocumented. Maybe now it takes more time to cobble together what you need than wiring something lean from first principles. Understood the full import of the dependency from get.

Re: Virtual DOM is pure overhead (2018)

#217

Post by notJim »

darepublic wrote: post #153
mumblemumble wrote: post #124

Earlier quoted context omitted.

> React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim. My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars. Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you'…

no its not wrong to criticize the culture in web development of salivating over every new framework. And rebuilding company code in hyped up framework X without pausing to understand the problem you're trying to solve and why the current glob of code is so damn buggy. I see experienced web devs, if not fall for this mistake themselves, happily prop it up to management every damn day across many companies. I've read t…

This feels like a tangential point about JS dev culture or engineering skill level rather than a point about the technical merits of React vs Svelte or whatever.

> As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.

I'm not sure I agree with this. Basically, it requires a much higher degree of experience and skill to write DOM manip well. There aren't really great resources that I've seen, because it's all very context dependent and something you learn over time. We used to send people straight into the DOM when they wanted to make a simple app, and the result was a lot of huge unmaintainable messes, security nightmares, and poor performance.

The value of React is that you can just follow the docs on reactjs.org that will give you a mediocre default. If your needs go beyond that, you can get a more skilled person to come in and improve the critical parts. The world's need for web apps outstrips the supply of highly-skilled, highly-experienced developers, so it makes sense to have libraries that lower the bar.

Re: Virtual DOM is pure overhead (2018)

#218

Post by rendall »

cuddlecake wrote: post #213
dimitrios1 wrote: post #170

Earlier quoted context omitted.

Your reply is the real cringe here. "I got shit to do" is no excuse to toss aside quality and craftsmanship. And you misread their argument they didn't say write everything from scratch, they said write a simple leaner version, but the argument is most people lack even basic problem solving skills. If you spend all your day glueing things together, you forget how to design and build them yourself. Sure you can stack…

It's kind of gatekeepy insisting on styled components being of lower quality than using pure CSS. Styled Components serves a specialized purpose of styling things on the web. Maybe less elegant or performant in some respect than pure CSS, but with trade offs that some development teams will happily take. I also hate the sentiment, that software development needs to adhere to some notion of purity or divine elegance.…

Use styled components if they suit your use case, by all means.

But if that use case is We don't have to learn CSS because we can just not think about it with this nifty innovation then the use case is horrific.

Re: Virtual DOM is pure overhead (2018)

#219

Post by rich_harris »

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…

Firstly, as the article emphasises, _diffing_ is far from the only issue with virtual DOM. And this isn't about microbenchmarks; plenty of people have run up against React's performance limits in real world applications and have had to spend time engaging in menial optimisation work as a result.

Secondly, you're dismissive of the idea that 'the virtual DOM is fast' is a meme (in the original Dawkinian sense; I'm not talking about gifs with Impact-typefaced captions), which suggests you haven't spent a lot of time around developers on places like Twitter and Stack Overflow. This misperception _absolutely_ exists, and this article was written to correct it, not to 'sell' Svelte.

Svelte isn't intent on 'taking over'. We're quite happy providing developers with an alternative to React that enables them to write less code and not have to worry about performance. That said, I'd argue the 'irrelevant' label is somewhat unfair (https://twitter.com/swyx/status/1409529125539254277, https://2020.stateofjs.com/en-US/technologies/front-end-fram...).

Re: Virtual DOM is pure overhead (2018)

#220

Post by cuddlecake »

rendall wrote: post #133
KronisLV wrote: post #105

Earlier quoted context omitted.

> Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue. This makes me feel conflicted. With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech. With JS libraries it's the wild west once again and befor…

> 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…

> their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves

Yeah let's stop (re-)using open source software and write everything ourselves.

Who needs React when we can have cuddlecake's spontaenously written mini-framework (I lovingly call it anguvuesveact, because I got inspired) that definitely does not provide the required feature set or developer experience to support a productive professional development process, but it's mine.

Now that we have WebAssembly, couldn't we write applications in actual Assembly? It just takes confidence that we can build something lean with it, no other considerations necessary.

Well, uh, I just realized we don't need to rely on Firefox, if we just, uh, develop our own browser, uh, from first principles. A lean one, to be sure, only providing the features we need for our Web App. If we need new features we'll build them along the way.

Ah shit, my DIY lodash (I lovingly call it cuddledash, because I got inspired) has a bug but I'm focusing on the custom browser, so no time to fix that. :/

> React/Vue/Angular will not protect you from bloated, poorly written apps.

Only our self-written lodash lib will protect us, hear hear.

Post reply on HN