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

271–280 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#271

Post by the__alchemist »

nextaccountic wrote: post #270
the__alchemist wrote: post #128

Earlier quoted context omitted.

I created Seed. I didn't know any better at the time! I'm no longer a fan of the extra computations VDOM does. Svelte's approach sounds like a clever way to mix declarative code without running extraneous computation.

I understand. Btw, what do you think about MoonZoon? ( https://github.com/MoonZoon/MoonZoon ) In special, the decision to not use Elm architecture. I see it's created by the current Seed maintainer. It appears MoonZoon uses https://github.com/Pauan/rust-dominator which, like Sycamore, is also a DOM library that doesn't use vdom.

Looks like a cool concept. Martin started working on it some time after I moved on, so I don't have any insight on it. I'd considered incorporating Dominator instead of an original VDOM, but at the time, it wasn't obvious how you'd interface with it. Ie not much in the way of docs or examples.

Re: Virtual DOM is pure overhead (2018)

#272

Post by yawaworht1978 »

People often say things like "because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code"

But what would be a minimal as possible example for this?

I know a bit reactjs and it can get complicated as well with multiform s and various elements states depending on each other quickly too.

A bad architecture can be "achieved" by either, I am curious about some examples showing me what people mean exactly by that.

Re: Virtual DOM is pure overhead (2018)

#273

Post by moritzwarhier »

recursive wrote: post #205
moritzwarhier wrote: post #149

Earlier quoted context omitted.

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.

That's a very far stretch from purely the topic "Virtual DOM" though, no matter how few JS knowledge. I hate Infinite Scroll with a passion. FWIW Infinite Scroll can be and is often implemented as a jQuery plugin.

Re: Virtual DOM is pure overhead (2018)

#274

Post by esprehn »

btown wrote: post #20

While this may have been true previously, React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames, to achieve perceptual improvements over synchronous DOM updates. Svelte’s AOT compilation approach, I believe, is limited in these kinds of time-spanning deferrals, though I’d love to be proven wrong! https://reactjs.org/docs/concurrent-mode-intro.html

React's concurrent mode doesn't split DOM updates across animation frames because that would cause visual tearing. It splits all the component "overhead" and the virtual DOM cost over multiple tasks though.

Re: Virtual DOM is pure overhead (2018)

#275

Post by jamra »

kujino wrote: post #174
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…

Svelte hasn't taken over because React is way too popular already. If you want a job you have to learn React (the same way Java is still one of the top lang to get a job but it's for legacy rather than technical reasons). Svelte performance is a nice bonus but it is the last reason I prefer Svelte over React. I prefer Svelte because it is truly reactive (unlike React) which makes everything easier, cleaner & more rea…

I’m in agreement with you that the performance is only a part of why Svelte is so nice.

The state management in Svelte is fantastic.

Re: Virtual DOM is pure overhead (2018)

#276

Post by recursive »

arcturus17 wrote: post #268
recursive wrote: post #256

Earlier quoted context omitted.

I seem to have a talent for coming up with things that shouldn't be, can't be, or are difficult to express in react. Note that I'm not particularly interested in other ways of writing this that would work. I now know several. I'm more interested in simple general rules that one could follow to stay out of trouble.

> I'm more interested in simple general rules that one could follow to stay out of trouble. I don't know what to tell you, just don't do this? I've been working professionally for years in React and have never encountered this particular issue. Once I've gotten to to it this morning with fresh eyes it's taken me like 5min to understand - React sees this as a list of the same element, which requires keys - this on the…

Thanks for your thoughts.

I eventually did figure out what's going on. I did figure out that using key= solves it. I also found I could use class components and make the three labeled instances in the constructor. That gives them a long enough lifetime to stay consistent also.

I'm not trying to tell anyone else they shouldn't use react. It's great that so many find it to be so productive.

You might say I dislike the general philosophy of react. I would rather choose whether I'm using 1-way or 2-way binding than being told. I actually have come around on JSX. I think it's pretty good now.

As for being weak and contrived, I don't know what to tell you. This honestly seems like a natural way to write this. I'm a react beginner. When I ran into this, it took me some time to figure it out, but I did eventually. I suppose another part of the philosophy I don't like is entire premise of virtual DOM and reconciliation. It creates another layer of concerns the developer needs to think about. This kind of stuff should be an implementation detail. Instead, you have to remember to use an array rather than unrolling. Or just use keys everywhere. More precisely, maybe you don't need to. But I would need to.

Re: Virtual DOM is pure overhead (2018)

#277

Post by pas »

porpoisemonkey wrote: post #30
vlovich123 wrote: post #2

The blog ends with > But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in. Ok. I’m convinced in principle but is there a follow-on blog that describes specifically what Svelte does differently?

There's a better explanation of the differences here: https://svelte.dev/blog/svelte-3-rethinking-reactivity Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write declarative state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like that eat into…

Isn't this very similar to Angular's Ivy compiler?

Re: Virtual DOM is pure overhead (2018)

#278

Post by nailer »

dragosmocrii wrote: post #26
nailer wrote: post #3

I thought most of the JS world know that virtual DOM is slow and ahead-of-time direct binding is the way forward at this point - why do something expensive inside your users browser when it should be done on the developer's machine? Svelte will either take over, or React will get patched to start doing this in a major new release. It could go either way at this point.

I doubt Svelte will take over. Although I really like Svelte, and worked with it before React, the tooling with React is simply superior. Besides, React already mentioned in one of their introduction tutorials that they are considering taking Svelte's approach at one point. Developers choose the tools that makes them productive and that are enjoyable, not the ones that are most efficient (otherwise we'd all be writin…

> Developers choose the tools that makes them productive and that are enjoyable

That true, but that points more towards Svelte taking over.

Re: Virtual DOM is pure overhead (2018)

#279

Post by Panther34543 »

panta wrote: post #267
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 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?

Re: Virtual DOM is pure overhead (2018)

#280

Post by Panther34543 »

davidwparker wrote: post #211
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?

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.

Post reply on HN