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

301–310 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#301

Post by nsonha »

floatboth wrote: post #182
lenkite wrote: post #132

Personally, I find modern template based approaches like lit-html, hyperhtml/lighterhtml better and faster. And also being far, far smaller. Throw in a CSS framework like bulma or tailwind-css and you are good to go at a smaller footprint and better performance.

And lit works without any build tools!

the main reason templates are bad is not that it needs a build step, it's more about being non-standard (a problem lit-html doesn't have), and not statically analyzable (think typescript's jsx), which lit-html doesn't solve.

Re: Virtual DOM is pure overhead (2018)

#302

Post by im3w1l »

citeguised wrote: post #204
jasonkester wrote: post #119

Earlier quoted context omitted.

the DOM was often used to store state. Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did. But wow. I've been building javascript-heavy web stuff since the mid 90's and it had never occurred to me to do that. You hav…

When I got into front-end coming from Design, jQuery just got huge. Due to lack of senior front-end-devs in the company, my JS was this exact pile of jQuery with state in data-attributes. The things weren't really complex (Modals, Tabs, Form-Validation etc.), so it was never a problem. Nowadays I'd still do simpler components this way. For anything heavier I'll grab React from the beginning, because of it's enforceme…

If you know you will need the data again store it in some variable, in addition to the dom?

For instance if you have a chat, you could have a list of message objects as a normal variable and also show those messages in the dom.

Re: Virtual DOM is pure overhead (2018)

#303

Post by beetwenty »

weberc2 wrote: post #293
ppeetteerr wrote: post #286

Earlier quoted context omitted.

I would argue that the state of the global model includes some information about the state of a widget (e.g. selected="true") and some state is unique to the widget itself (hover). The trick here is how do you reconcile those two states when both have a copy of the data. For instance, the holds its own state and you hold the value in the global state. When a user types a character into the input, the input hold a cop…

If I understand correctly, the distinction between immediate mode GUI and retained is that in the former, there aren’t stateful widgets so there is no copy to reconcile.

That's correct. State is handled by the user, which is great for some things(dynamic quantities of elements - no caching layers, just feed it a for loop) and awful for others(maintaining pre-committed state for e.g. a configuration panel with checkboxes, text fields, etc.)

Ultimately the ground truth in both instances is that you have potentially many data models that the UI has to aggregate, and the source model, layout, display properties and hitboxes of elements are usually but not totally related and can change due to many kinds of events. Any formal structure you might come up with is bound to run into exceptions. As a result I tend to have this policy:

* I don't trust the framework

* But I leverage the framework to produce early results, and both immediate and retained modes offer ways of doing that

* I expect long-term maintenance to involve a customized framework design regardless

Re: Virtual DOM is pure overhead (2018)

#304

Post by lenkite »

nsonha wrote: post #301
floatboth wrote: post #182

Earlier quoted context omitted.

And lit works without any build tools!

the main reason templates are bad is not that it needs a build step, it's more about being non-standard (a problem lit-html doesn't have), and not statically analyzable (think typescript's jsx), which lit-html doesn't solve.

Web Templates support slots and are analyzed at definition time. All this is native code supported by the browser so big heavy JS doesn't need go be sent across the network and then run even more slowly in order to produce HTML. All web-template based libraries beat React/Angular/any VDOM based alternative in performance and footprint.

Re: Virtual DOM is pure overhead (2018)

#305

Post by keepsmiling »

hello very great article. i've been working as a developer for over 20 years now and have to say that do more experience you have on fewer and fewer trains you jump on what should not be heisen that i don't look at frameworks anymore but to describe it it's just often too much of a good thing. every framework has good pages but you should keep it simple. ciao

Re: Virtual DOM is pure overhead (2018)

#306

Post by _0w8t »

atan wrote: post #300
_0w8t wrote: post #166

Direct manipulations of DOM are expensive. It is vastly more cheaper to create or update JS object than create or manipulate DOM node. So the claim that VirtualDom is always an overhead is not true. The diff algorithm can give a set of DOM operations that are less expensive than typical sequence of manual mutations. So virtual DOM can be faster if savings from less DOM operations are bigger than extra JS work. Surely…

I'm not sure you understood the article. The Svelte compiler does in fact generate code that performs "carefully crafted direct DOM mutations," though it is not hard to maintain, because the compiler handles it. Given code that already knows exactly which DOM updates to make, virtual DOM would indeed be pure overhead.

Typical React code does not know which updates to make. It always builds the Virtual DOM from scratch as is was the first time. It is the diff algorithm then figures out the set of changes.

If code knows which updates to make, it essentially embeds a particular form of the diff algorithm. That inevitably leads to more code to write as besides the initial construction of DOM one has to track changes. And such manual tracking is not necessary optimal as the diff algorithm has a global picture and can target the globally optimally set of mutations, while manual in-component tracking optimizes for a particular component.

Re: Virtual DOM is pure overhead (2018)

#307

Post by [deleted] »

oblio wrote: post #275
hyperdimension wrote: post #216

Earlier quoted context omitted.

Just so you know (not just for this comment)--you are my favorite HN user. Everything you post is either funny, quirky, or extremely interesting (mostly all of the above).

And, to add to this (I'm not being snarky), he could be the father/grandfather of many HNers. I recall one of his comments about how he was doing stuff on computers in 1965. We need more old coders around!

[deleted]

Re: Virtual DOM is pure overhead (2018)

#308

Post by DonHopkins »

oblio wrote: post #275
hyperdimension wrote: post #216

Earlier quoted context omitted.

Just so you know (not just for this comment)--you are my favorite HN user. Everything you post is either funny, quirky, or extremely interesting (mostly all of the above).

And, to add to this (I'm not being snarky), he could be the father/grandfather of many HNers. I recall one of his comments about how he was doing stuff on computers in 1965. We need more old coders around!

Thanks, but my age was negative in 1965! (But not very.) Maybe I was taking credit for somebody else's work and forgot to get my story straight. ;)

Old coders never die, they just get frozen until their favorite programming languages come back into fashion.

https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39

Re: Virtual DOM is pure overhead (2018)

#309

Post by vaibhavkul »

beders wrote: post #164

It is simply mind-boggling how much effort the JS community has put into working around the performance properties of a document layout engine to make it 'interactive' and 'responsive'. With only 3 major rendering engines left standing, where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines? Back to Svelte vs. React vs. Reagent vs. Vue.JS vs. Angular v…

This is why I find the flutter approach interesting: it has its own rendering engine. I would guess it is optimized for this sort of thing (dynamically rendering UI elements) without depending on an external entity (DOM).

Maybe there is a future where flutter style renderers become standard, have a container like a browser (to avoid the entire runtime baggage when it's deployed), and people target it instead of the DOM? This gives best of both worlds--write apps in a declarative way, without the need of any external "optimizing" framework.

Re: Virtual DOM is pure overhead (2018)

#310

Post by infinite8s »

Chris_Newton wrote: post #102
oraphalous wrote: post #79

Earlier quoted context omitted.

>By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around. My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. Hell, just about all of the enterprise codebases I get contracted to work on are STILL do state management the old way. S…

My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. I can’t really dispute that since I don’t have any useful statistical evidence. All I can say is that in my experience there were mostly two types of people working on front-ends to run in browsers in the early days: Web designers who learned programming, and programmers who learned th…

There is a fourth group of people who used to build desktop apps applying the same approach to building webapps (no server generated HTML, treat the DOM as a retained mode widget set, and have a pure js data model). Two examples of this are JupyterLab and VSCode.
Post reply on HN