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

201–210 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#201

Post by ralphstodomingo »

2T1Qka0rEiPr wrote: post #151
vfc1 wrote: post #144

Angular also works in a somewhat similar way, there is also no virtual DOM. Instead, the modern compiler is used at build time to generate what looks like a change detection function and a DOM update function per component. These functions will detect changes and update the DOM in an optimal way without any DOM diffing. However, because Javascript objects by default are mutable, after each browser event Angular in it…

Thanks for the write up - it's a very succinct explanation of how Angular works in comparison. I found the original article to be a really good read, and the Svelte approach in general seems rather neat. I do however find that in this current front-end framework sphere, there seems to be a huge amount of religiosity and one-upping going on. I hear routinely (on-line and off) developers vocalising some anti-[jQuery,an…

I would guess this is partly because the modern front-end framework leaderboard is a zero-sum game: you can't possibly be sane to use two or more different frameworks for most of your day-to-day work. Maybe you have one for work and one for hobby development, but that's about it. I'd be torn to remember quirks of both React and Vue, for example.

And thus you see it in discussions that people feel the need to pull one down to put their preferred one on the top. We know what happens to a library without a critical mass of adopters: they lose contributors, which in turn reduces the rate of growth, and in turn, the quality of the library over time.

Which is kinda sad. A lot of work goes into these frameworks that I really respect. There's no logical rule that says these new ideas completely succeed their precedents. I wonder what needs to be done to get us over that JS fatigue.

Re: Virtual DOM is pure overhead (2018)

#202

Post by austincheney »

computerex wrote: post #20

What a strange post. Yes, virtual DOM is overhead, much like JIT compilation is an "overhead". But this overhead ultimately translates to better performance because many virtual DOM transformations can be buffered into 1 transformation of the real DOM.

The JIT is not overhead and it is in no way related to the DOM. The JIT is a compiler in a VM. The DOM is a standard data model living in memory.

Re: Virtual DOM is pure overhead (2018)

#203

Post by awesomepeter »

namelosw wrote: post #49
Rusky wrote: post #30

Earlier quoted context omitted.

The point of the article is that you can get that same declarative interface at much lower cost, with a more efficient implementation.

I'm not sure if it's still an 'interface' since it's compiling another language to imperative code which operates DOM API. So it requires other platforms implements a similar imperative API surface as DOM.

Which is the same thing that a virtual DOM does, it also has to have an adapter(react-dom in Reacts case) which applies the VDOM to the real DOM via it's imperative API.

Re: Virtual DOM is pure overhead (2018)

#204

Post by citeguised »

jasonkester wrote: post #119
oraphalous wrote: post #54

I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child…

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 enforcement of modularity and state-management.

I'm interested in the way of architecting things you described, since I used to try similar ways, but always ended up state-in-dom. Would you have examples or literature on this?

Re: Virtual DOM is pure overhead (2018)

#205

Post by ralphstodomingo »

ng12 wrote: post #23

I keep hearing this and find it really hard to care about. Runtime performance is not a bottleneck for me. Once in a blue moon I'll have to optimize a React component with shouldComponentUpdate but otherwise I have no performance concerns even on old browsers. There are other characteristics that are very, very important like build size. VDOM is not worth thinking about. Honestly I don't understand Svelte. It sounds…

I feel as if Svelte came at the wrong time. These days, when most people know either React or Vue or some other thing, and computing devices are performing better over time, there's diminishing returns on performance optimization. Sure, you do a bit of it, and then you're often better doing something else, like enhancing developer experience for example.

I really like the idea, and will play around with it, but fat chance it's getting into production with me. I am much more productive with React now, and I worry more about business requirements than raw performance (that I almost never worry about these days).

Re: Virtual DOM is pure overhead (2018)

#206

Post by mercer »

Udik wrote: post #198
onion2k wrote: post #147

Earlier quoted context omitted.

Bare in mind that most people using jQuery weren't writing JavaScript applications. They were writing backend-driven applications with jQuery enhancements, so there was no real concept of frontend 'state' that was separate to the DOM itself. If your frontend code needed to work with 'state' like form values or element attributes you had to read them, and because there could be multiple separate bits of code working w…

> he thing that changed to make frontend development improve dramatically was hash based routing with ajax... I think that what's changed is simply that people realized that it's way less messy to use the backend only as a data source (with ajax calls), and leave everything else to the frontend. The cognitive overhead of having the server producing html with some implicit state, then updating that state interactively…

While I agree in theory, in practice I find that the frontend still has all sorts of warts that don't quite make it a great solution (yet).

I mean, it's better than having to maintain both server- and client-side logic and state (and having to sync all that), and definitely better than the days where we also had to manage DOM diffing manually.

But I still get headaches from the NPM/node ecosystem, the build steps, having to decide whether logic goes on the client, server, or both, and to some extent javascript itself. And you can never fully let go of the server-side of things.

I'm very intrigued by the alternative idea of moving (almost) everything to the backend, and maintaining the dynamic bits by sending all events to the server and sending back diffs based on that which update the page. Phoenix'/Elixir's LiveView made some great progress in this area, and from what I hear other ecosystems are experimenting with the same thing.

It's not a panacea: if you need offline functionality you're gonna have to deal with js and everything that comes with it. But in many projects that's not a deal-breaker, and in practice the approach actually leads to smaller payloads sent between client and server, and significantly simpler codebases.

Re: Virtual DOM is pure overhead (2018)

#207

Post by _pdp_ »

Writing some basic apps with vanila js is fine. But I think we use browsers for much more than this these days. For that we do need this level of overhead because DOM is just too simple for the task.

Re: Virtual DOM is pure overhead (2018)

#208

Post by preommr »

dmitriid wrote: post #190
preommr wrote: post #169

Earlier quoted context omitted.

I am not sure inconsistent is accurate here. Take the following for example: v-on:click="counter += 1" v-on:click="greet" v-on:click="say('what')" Even without knowing vue, all of those examples are very straightforward in what they're doing. Just because the click event can take multiple options doesn't mean that it's inconsistent. And yea, it's more complicated than "everything in the brackets is javascript and you…

> Just because the click event can take multiple options doesn't mean that it's inconsistent. That's what inconsistency means. It has multiple v-* attributes and each has different rules on what it accepts. > ugly code that I've seen in some react projects where the programmer puts a tonne of js code into the templates which as I mentioned before I find an anti-pattern. JSX isn't templates ;) > It's a framework, it's…

Bunch of things going on there:

1 - things defined in data, computed, methods, and props can be accessed on the component directly as a shortcut. This is in the fairly short documentation and everywhere in the code examples. It's not inconsistent if you don't know the rule. It's like complaining that variable names in some languages can start with _ or other special characters but can't start with '1' or start with '2', or start with '3'...

2- and this.model.children definitely can be set directly, and it will be reactive. Unless you're passing an object literal without binding it or if it's not a data object, although I am not 100% sure on this since all my props are usually made reactive by vue and so they are bound. But I know for sure that code like this should work for sure because I've done it.

3 - I don't think that's the correct use of hoisted.

I feel like maybe you'd like vue a lot more if you gave it a chance and went through the documentation (which is pretty good, short and simple). I don't disagree that it has a little bit of magic, but it probably looks worse than it really is if you don't know the rules. Once you know a handful of rules, things are fairly easy to reason about. IMO, easier than angular, and sort of easier than react because there's less code.

Re: Virtual DOM is pure overhead (2018)

#209

Post by mercer »

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…

I started out much the same way, and took that approach for quite a while.

These days I avoid putting state in my markup even for small stuff. I remember some good articles on the topic, but sadly can't find them.

But at its most basic, I just make sure that any jQuery/dynamic component/widget, from the start, is essentially a render function that takes a bunch of data and updates the markup with this data (triggered via some event handler or setInterval(), or something like that). In many cases this doesn't have to be complex or efficient. Sometimes just an .innerHTML() or whatnot is fine. The crucial bit is that I always start with a js data structure and treat it as the single source of truth.

In most cases I just use Preact from the beginning, but I've worked on projects where that wasn't possible and I had to use jQuery or plain javascript. Whatever I used, I usually ended up regretting state in my markup.

Re: Virtual DOM is pure overhead (2018)

#210

Post by citeguised »

austincheney wrote: post #200
lacampbell wrote: post #111

Earlier quoted context omitted.

compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps) Do you do full blown SPAs with this technique? I mean I'm sure it's possible, but I wonder how difficult it is. I wouldn't use (p)react for a website that just needed a bit of AJAX, but I find it a bit hard to imagine doing an actual app with vanilla JS.

> but I wonder how difficult it is. Its not if you have some basic understanding how the code actually works. > but I find it a bit hard to imagine doing an actual app with vanilla JS. Try it. It will blow your mind how simple it is and how little overhead it requires.

I went from developing simple server-rendered websites enhanced with a bit jQuery straight to React-style JS.

I'm interested in studying the source of less or more complex JS-apps, that were developed without SPA-Frameworks.

One I'd like to see would be Construct3, but alas it's not open-source.

I'd very much appreciate links and hints!

Post reply on HN