Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

281–290 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#281

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

You absolutely 100% do not have to use Svelte Kit. Svelte Kit is just the equivalent of (an opinionated) Next.js, Gatsyby, or Nuxt.js framework. Those frameworks are also incredibly opinionated on purpose.

One of the things I came to enjoy regarding React was that the router was separate and kept the core React API small. I had hoped that something similar was the norm for Svelte, but it was quite clear that the official recommendation was to use SvelteKit.

Have you built production apps with just Svelte? Is the tooling and feature set good enough to use Svelte alone in an actual app?

Re: Virtual DOM is pure overhead (2018)

#282

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

We've been building Budibase without SK and it's great: https://github.com/Budibase/budibase

Very cool, thanks for the link.

Re: Virtual DOM is pure overhead (2018)

#283

Earlier quoted context omitted.

I'm not sure I'd agree that when React took over, Angular was a perfectly fine framework. I mean, what happened with React was actually very unusual and remains very unusual. It took over. There is this popular and snarky notion that js devs are constantly chasing every shiny thing but that is exactly the opposite of what has happened over the last several years with React. Instead I'd argue that js devs were nomads…

When React first come out, the whole notion of mixing HTML and Javascript code was, if anything, widely rejected. Rather than going viral as a kind of fashionable thing, I feel that it really had to earn its position.

>When React first come out, the whole notion of mixing HTML and Javascript code was, if anything, widely rejected.

And it still is. Mixing JS and HTML/DOM does result in fragile code and you shouldn't do it. React VDOM and JSX is not the same thing .. at all. Again, JSX isn't new. XML-based declarative UI frameworks with data-biding were an old thing by the time React arrived on the scene. That's how Flash Flex (MXML) and Silverlight (XAML) worked, for example.

Re: Virtual DOM is pure overhead (2018)

#284

Earlier quoted context omitted.

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?

This post [0] sums up my general feeling toward SvelteKit. It seemed very opinionated and very restrictive, two qualities which seemed opposite the philosophy of core Svelte. [0]: https://www.reddit.com/r/sveltejs/comments/ni9g5d/svelte_vs_... Do you have concerns with using SvelteKit in production? It's still in Beta last I checked.

Yes, it's very much in beta! And if that's a concern for you, then I'd stick with Sapper or Elder.js or another.

That said, I think the replies covered the concern pretty well. For me, I don't really have any concerns with it. I don't find it very opinionated nor restrictive, but I come from a Rails background where I'm used to convention over configuration, so maybe I'm biased towards reasonable defaults.

Re: Virtual DOM is pure overhead (2018)

#285

Earlier quoted context omitted.

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

Doesn’t the NYT do a lot of React too? From what I read in other comments Svelte was an experiment. I think what people mean when they say “at scale” is they want to see a large codebase, with a large team working on it, where Svelte is the primary front-end choice.

The creator of Svelte (Rich Harris) works for the NYT. If you ask him, I'd venture to guess he wouldn't say it's an "experiment" as they regularly use it. I doubt his frontend work there is alone too, so I'd guess it's fairly in-use. But again, that's just my guess.

Re: Virtual DOM is pure overhead (2018)

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

> Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second

And this, ladies and gentlemen, is how we ended up with web pages that lead modern mid- and even high-end personal computers grind to a halt.

Re: Virtual DOM is pure overhead (2018)

#287
post #267

Earlier quoted context omitted.

I agree. SvelteKit should not be advertised as the standard way to use svelte imho. Fortunately it’s not necessary to use svelte. I’ve some quite complex apps built using svelte, all without SvelteKit/sapper (I am of the “explicit is better than implicit” school of thought).

So, what do you use for something like a router?

I’ve used page.js and some other generic ones. It’s up to you, svelte is not bound to anything in particular.

Re: Virtual DOM is pure overhead (2018)

#288
I do agree. When I first see it I knew that. Comparing two sequences (actual dom and dom) to find diff is like O(n^2) and the assumption that dom ops is expensive is a lie (premature optimization). Dom ops on ids and classes and fragments is very fast. In most cases a slow dom is always a developer fault failing to use fragments.

Re: Virtual DOM is pure overhead (2018)

#289

Earlier quoted context omitted.

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…

React’s changes over time have always been broadly compatible, and the same under the hood, just presented and manipulated a different way at the surface. Migrating to anything like Svelte would be a radical and extremely incompatible change on multiple fronts. It’s never, ever going to happen; the closest you’ll get will be another layer on top of React that embeds something like Svelte—such as https://github.com/Ri…

> blocks are not written in JavaScript, but rather a language with the same general syntax but different semantics

One could argue that React's hooks are the same: they look like JS but change JS semantics.

However, your point is still valid.

Re: Virtual DOM is pure overhead (2018)

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

I liked Svelte reactivity but the component props are unergonomic to use and TypeScript support is lacklustre

Care to expand on this? Component props seem quite straightforward where I stand and Typescript support has improved drastically over the preceding months
Post reply on HN