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

141–150 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#141

Post by Marazan »

JMTQp8lwXL wrote: post #117
brobdingnagians wrote: post #55

Earlier quoted context omitted.

I love Vue.js. I've never really caught onto the JSX stuff. If you have ".Vue" files then you get nice separation of the template html, methods, and the scoped styling. The Javascript syntax is pretty straightforward, and the templates just add nice directives like v-if, v-for, etc. I think it look pretty clean and is fairly easy for JS developers to pick up. Integration into a project is pretty straightforward as we…

I've never understood how people view the separation of template, styles, and business logic into separate files as simpler. Now, to work on a single component, I need to open three files in my editor, instead of one.

It is an over reaction to bad PHP.

Bad PHP pages mixes all kinds of shit together. This leads to the thought that to do it 'good' everything needs to be seperated.

It's a wrong thought but I see how people got there.

Re: Virtual DOM is pure overhead (2018)

#142

Post by ups101 »

oraphalous wrote: post #79
Chris_Newton wrote: post #65

Earlier quoted context omitted.

In short - the DOM was often used to store state. And this just isn't a very efficient approach. 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. I think the basic premise of the article here is correct. The important development with React that hadn’t previously been widely seen in front-end, JS-based w…

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

> It's the VDOM that allowed them to take state management out of the DOM - and thus why they claimed that the VDOM was faster than the DOM.

Do you have a reference to this claim?

Re: Virtual DOM is pure overhead (2018)

#143

Post by Mikushi »

Sawamara wrote: post #136

I was running some quite complex UI systems in several of my projects with vanillaJS, cached DOM elements, all that jazz. Nothing like VDOM. Then eventually, it started to finally bog me down. Like rendering an inventory in an RPG system where you can buy stuff from the vendors: I started to get dissatisfied with change operations that lasted upwards to 2-3ms in a bad day. Then I started caching even more DOM element…

Not to be grating but your problem sounds more like using the wrong tool for the job. DOM is not made to render video game UI, it is a bad tool to do so as you discovered yourself.

Re: Virtual DOM is pure overhead (2018)

#144

Post by vfc1 »

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 its default change detection mode has to check all the template expressions in all the components for changes, because the browser event might have potentially triggered changes in any part of the component tree.

If we want to introduce some restrictions and make the data immutable, then we can check only the components that received new data by using OnPush change detection, and even bypass whole branches of the component tree.

This is the current state of things, for the near future Angular is having it's internals rebuilt in a project called Ivy.

One of the main goals of Icy is to implement a principle called component locality.

Ivy aims at getting to a point where if we change only one component, we only have to recompile that component and not the whole application.

I think the article puts the focus on the wrong thing. The current change detection and DOM update mechanisms made available by modern frameworks virtual DOM or not are more than fast enough for users to notice, including on mobile and once the application is started.

What we need is ways to ship less code to the browser, because that extra payload makes a huge difference in application startup time.

Re: Virtual DOM is pure overhead (2018)

#145

Post by avip »

sam0x17 wrote: post #134
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…

My god, it finally all makes sense! And this is why I've been developing all my modern web applications as essentially an S3 bucket of flat HTML with vanilla javascript and jquery sprinkled in sitting behind cloudfront, connected to a fast API built of cloud functions / lambdas written in crystal/rust/etc. I use a custom routing system (I have S3 set up to respond with a 200 at the index in the event of a 404, so I h…

Pricing aside (as it's almost unreasonably expansive if your app requires frequent db writes), firestore is indeed "A magical database that has perfect automatic horizontal scaling". But as you have your happy setup on aws it probably makes little sense to switch.

Re: Virtual DOM is pure overhead (2018)

#146

Post by dmitriid »

preommr wrote: post #130
namelosw wrote: post #61

Earlier quoted context omitted.

It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte), it's never clear what's the differences between them. It's almost a new language but similar every time, with different pitfalls -- an ad-hoc, informally-specified, bug-ridden, sometimes slow implementation of half of HTML and half of JavaScript. For example, a framework Foo does not have the concept '…

> It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte) This is the most ridiculous thing I hear when people compare frameworks. I don't know about angular anymore, but with vue you can use jsx if you wanted to. It's in the official docs, so it's not some random third party support either. Also, my dude, there's like half a dozen rules when it comes to vue…

> Also, my dude, there's like half a dozen rules when it comes to vue templates.

You mean, wildly inconsistent templates: https://news.ycombinator.com/item?id=19199423 and magically bound JS https://news.ycombinator.com/item?id=17471199 (see code and comments at the end)

Re: Virtual DOM is pure overhead (2018)

#147

Post by onion2k »

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…

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 with the same form or element you had to write values back to the DOM so the next bit of code had the correct 'state'.

The thing that changed to make frontend development improve dramatically was hash based routing with ajax, and later the introduction of the history API. That caused frontend development to have a need to retain state between 'pages', so then was a need to find a better way to store it than using DOM attributes.

Re: Virtual DOM is pure overhead (2018)

#148

Post by xfer »

namelosw wrote: post #138
preommr wrote: post #130

Earlier quoted context omitted.

> It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte) This is the most ridiculous thing I hear when people compare frameworks. I don't know about angular anymore, but with vue you can use jsx if you wanted to. It's in the official docs, so it's not some random third party support either. Also, my dude, there's like half a dozen rules when it comes to vue…

You can't expect most code bases use JSX as template. It's not even praiseworthy if the framework provide every possible choices. Just like you can do anything in C++, but in practice it's a terrible language to work with. For class part I'm sure it's just whatabouism... And for expressions it's not praiseworthy to put in the template, but my point is why not reusing JavaScript semantics rather than implementing you…

> Just like you can do anything in C++, but in practice it's a terrible language to work with.

It definitely beats working with JS for me.

Re: Virtual DOM is pure overhead (2018)

#149

Post by mellab2 »

cryptica wrote: post #133
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…

complexity also kept me away from React. The main reason that it got popular is because it's by Facebook and they know how to manipulate people to use certain products over others (that's their entire business). There have always been simpler and cleaner alternatives. If React was not by Facebook, it would not have gotten popular at all except as a 'cool hack/experiment' - Nobody would have seriously tried to incorpo…

Sorry but what complexity are you talking about? React (particularly in the early days) has always had a comparatively small API surface.

You have components with a render method, and in that render method you return other components which you can pass data to via "props" - that's basically react in a nutshell.

I've noticed React is often conflated with the wider ecosystem it is a part of (Webpack, Redux, Babel) - perhaps this is the complexity you are referring to, but to be clear React can be used without any of these things.

And sure React being developed by Facebook couldn't have hurt in terms of it gaining popularity - but the real reason it took off is that in contrast to what you said it removed a huge amount of complexity by alleviating the burden of developers having to manipulate the DOM directly in ad hoc ways. Instead of having to manually add classes, add elements, remove elements, append children, you could just say given this piece of state, give me this.

> Anything that comes out of Facebook is just pure manipulation.

This just shows that your issue lies with facebook the company, which is biasing you against react - the technology.

Re: Virtual DOM is pure overhead (2018)

#150

Post by dmitriid »

spankalee wrote: post #5

This is absolutely true. Virtual DOM diffs do a huge amount of unneeded work because in the vast majority of cases a renderer does not need to morph between two arbitrary DOM trees, it needs to update a DOM tree according to a predefined structure, and the developer has already described this structure in their template code! A large portion of JSX expressions are static, and renderers should never waste the time to…

> I really think the future is not VDOM, but more efficient systems, and hopefully new proposals like Template Instantiation can advance

Template Instantiation is like a half of a half of 1% "advance" in the best case scenario. It's being rushed forward despite the fact that no one sat down and listed all the benefits vs. all the downsides of implementing it in the browser.

What browsers do need is a declarative DOM API and a native "DOM as a function of state" which renders the whole instantiation proposal moot, and at the same time actually advances the browser as a platform.

There's a discussion on GitHub which in my opinion is going nowhere because TI is viewed as unquestionable good https://github.com/w3c/webcomponents/issues/704

Post reply on HN