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

111–120 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#111

Post by onion2k »

AshleysBrain wrote: post #18

This blog says what I've always thought - that to keep a large web application performant, you need to eliminate all redundant calls and operations, even in to pure JavaScript code - not just DOM calls. If your pure JS code already is designed to eliminate redundant calls, then you already get the minimal DOM calls from JavaScript too. That's the best case, and VDOM can only be slower as it adds diffing overhead on t…

that to keep a large web application performant, you need to eliminate all redundant calls and operations, even in to pure JavaScript code

That will still only result in a performant, smooth 60fps application if you can do all the calls and ops that aren't redundant in less than 11ms (16.6ms per frame, but the browser needs about 5ms to update the screen). If you're trying to do more than you can calculate in 11ms then you have to start spreading things over multiple frames hopefully doing what's most important first. This is pretty much what React's concurrent rendering claims if can do for you. If it works well it really will make applications feel significantly better. As far as I know Svelte doesn't have a solution for that. It just hopes you can get everything done in that 11ms.

To be fair, 11ms is quite a lot of time on a modern computer, so unless you're doing some heavy calculation work that you can't move off the main thread to a worker you should be fine.

Re: Virtual DOM is pure overhead (2018)

#112

Post by blacktriangle »

slumdev wrote: post #58
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.

Writing HTML programmatically or using JSX are both unfortunate React-isms. Not saying that Angular's banana box is ideologically superior, just that all JS frameworks have idiosyncrasies.

Honest question, why? The problem one always runs into in client side apps is you need various features like conditionals and looping when rendering your HTML. This has lead to a proliforation of templating languages that half-assedly implement these features. Moving to using a full programming language for generating your HTML removes the need for janky inconsistant templating languages.

Re: Virtual DOM is pure overhead (2018)

#113

Post by strangescript »

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 awkward to use at times and far more quirky than React.

As others have pointed out, that bleeding edge performance is only as great as what you are building. If you don't need to update the DOM multiple times a second, then it barely matters.

Re: Virtual DOM is pure overhead (2018)

#114

Post by engineeringwoke »

vinnymac wrote: post #81
jchw wrote: post #71

Earlier quoted context omitted.

That’s the weird part. I agree with you, but then at the end, they say the important part: > It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. I find this bewildering because it makes me feel like the article does actually understand React. It realizes it was faster than frameworks it initially competed against, it understand…

Strangely, after having read the article, now I am wondering why the React team can't just borrow some of these optimizations. It would take a massive overhaul, but it's not like React has ever stood still, it's constantly evolving and changing. I wouldn't be surprised if the under the hood stuff continues to change in a huge way, just like it did when React Fiber was completed. At the end of the day, I've never spok…

I was quite involved in the project around 2017-2018, and this is just what I feel, but I think the API is pretty much hardened at this point. Context was a disaster. Hooks are useful but more difficult to reason about compared to classes. They have said straight out that JIT optimizations don't work well when the main pattern was to heavily manipulate a singular state object, and that was a culture that I think they failed to change with Hooks.

If Facebook comes up with something else, I think it will be something new. Maybe that is Reason, or something that abuses WASM/Rust in the core architecture. Who knows. The project has a lot of tech debt, and the ecosystem has changed quite a bit as well.

Re: Virtual DOM is pure overhead (2018)

#115

Post by macspoofing »

protonimitate wrote: post #106
macspoofing wrote: post #97

Earlier quoted context omitted.

>Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale. What do you mean 'at scale'. It's a UI framework that runs JS and mutates the DOM - there's no issues with 'scale' here. That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.

"at scale" here means # of contributors, not # of lines or scope of code base. Svelte vs React on a single side project I work on in my free time by myself is different conversation than Svelte vs React on a team that's moving fast and has more than a single dev.

>"at scale" here means # of contributors, not # of lines or scope of code base.

I understood what you meant, I just disagree that this is a real consideration. Both are just UI frameworks following modern conventions in architecting your SPA code-base. From that point, both are just fine. Other considerations, like the fact that React is more popular and therefore more likely to be supported in the future, and therefore has more devs familiar with it, are way more important.

Re: Virtual DOM is pure overhead (2018)

#116

Post by ubercore »

macspoofing wrote: post #89
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…

>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. Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because…

I seem to remember that when React was first introduced, DOM mutations _were_ very expensive. I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?

Re: Virtual DOM is pure overhead (2018)

#118

Post by christophilus »

sopooneo wrote: post #108

For those who have worked on traditional desktop apps (rather than web), what underlying paradigm is used for UI updates there? I assume all these problems of fast partial updates must have been addressed there long ago. So apart from the specifics miasma of language and markup formats, how was it done? I ask in complete earnest, and if I should just be reading some particular Wikipedia article I'm grateful for any l…

It's been a while, but when I developed Windows applications, I generally had a well-defined, observable central data structure. You made updates to it in systematic ways, and then each important section of your UI would handle updates and redraw intelligently.

Sometimes, I'd make use of a component that did this itself, but yeah. At least back then, it was a lot of manual wiring. Maybe similar to backbonejs in some ways.

The toy video games that I wrote were more React-like, in that you would simply update your models, and then a separate process would re-render 30-60 times per second. So, as a developer, you could really just think in terms of data transformations.

Anyway, it's been 15 years since I've done either. I'm not sure how modern, native toolkits work. I assume there are decent React-like top-down-dataflow approaches these days.

Re: Virtual DOM is pure overhead (2018)

#119

Post by paavohtl »

mumblemumble wrote: post #69
ElViajero wrote: post #19

The web stack, from tunneling thru HTTP to the JavaScript language itself, is a very interesting case study. I think that many decisions, like creating a virtual DOM, make a lot of sense in isolation. But, if you look at the complete ecosystem, no sane human being would have ever designed anything like that. Maybe, the Virtual DOM is pure overhead if you look at the complete system, but: 1. It was reasonable at the t…

What's interesting to me, as someone who is currently learning Web development mid-career, is that I can see that vanilla JS is actually a really good option nowadays, but not necessarily available to anyone who's more established. Because it doesn't seem to have gotten good until fairly recently, and, for the most part, everyone had already made the important technical decisions before that happened. So, even if it'…

Pedantry time: there is no such thing as a vanilla JS way of building web applications, in the same way there is no vanilla C way of writing compilers. JavaScript as a language does not concern itself with web browsers - that's the responsibility of the DOM API. But even ignoring that, there is no standardized or widely adopted way to build interactive web applications without frameworks.

Re: Virtual DOM is pure overhead (2018)

#120

Post by datavirtue »

hallway_monitor wrote: post #39
ankurpatel wrote: post #7

I will probably get downvoted as I am in minority who still believe Server Side Rendering is the best approach for most of the web with exceptions to some websites that require Single Page App functionality. I still think web would be best if you do SSR and then replace HTML DOM elements using frameworks like Stimulus Reflex or Hotwire. For millisecond interactivity you may want to write JS in a framework like Stimul…

The SPA movement has always seemed like a cargo cult to me. Yes, AJAX is handy and it was exciting when it came out. We used it to update search results when you changed a filter. For 90-95% of applications, a single page app architecture with a front-end JavaScript framework running a bunch of application code and rendering output is overkill and you could write the same app in half the time using server side render…

But then we wouldn't have the ability to build cross platform apps in HTML/CSS/JS. I'm working on an app that is built on Ionic (packages app for various platforms) and Electron (primary deployment model for desktop utilized by Ionic) that would not be practical if we were stuck on a server side rendering paradigm.

I can use HTML/CSS/JS skills (and Angular) to build a serious business application that runs anywhere and looks the same on each platform (or morphs to the platform UI if I care about that).

Post reply on HN