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

131–140 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#131

Post by preommr »

wnevets wrote: post #37
ec109685 wrote: post #36

Earlier quoted context omitted.

Seriously, who actually said lack of typescript was a plus for React ever? That seems like a non-sequitur.

A lot of people back when every blog was comparing Angular (read not angularjs) and Reactjs.

People were upset about being FORCED to use typescript. It was hard for some people to accept both being bundled together. Not to mention I would say this is before when typescript had even less support and there was a chance it was going to be like coffeescript. Hell typescript adoption is still pretty low according to metrics like the TIOBE index (although that doesn't mean much).

Re: Virtual DOM is pure overhead (2018)

#132

Post by lenkite »

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.

Re: Virtual DOM is pure overhead (2018)

#133

Post by cryptica »

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…

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 incorporate it into a production application.

As soon as you scratch the surface, you understand that it's one of those tools that tries to take away complexity by adding complexity on top.

The story has gotten more complicated though because now React has so many components and there is all this conveninent tooling and boilerplate around it but still I would never choose it over VueJS.

Anything that comes out of Facebook is just pure manipulation.

Re: Virtual DOM is pure overhead (2018)

#134

Post by sam0x17 »

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…

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 have unlimited control over pathing from within my js logic) and I never let node touch anything at all. And I'm super happy about it. Never has it been easier to get things done. I don't have to fight with any system because there is no system to get in my way.

This gives me:

1. 2-4 second deploys

2. full control over assets pipeline (I call html-minifier, etc., manually in my build script)

3. literally serverless -- S3 or lambda would have to go down for there to be an issue (ignoring db)

4. caching at the edge for everything because of cloudfront

5. zero headaches because I don't have to do battle with node or react or anyone's stupid packages

6. (surprisingly) compatibility with googlebot! It turns out that the googlebot will index js-created content if it is immediate (loaded from a js file that is generated by a lambda and included in the document head tag as an external script, for example)

7. full control over routing, so I don't have to follow some opinionated system's rules and can actually implement the requirements the project manager asks me to implement without making technical excuses.

This does not give me:

1. A magical database that has perfect automatic horizontal scaling. Right now there is no magic bullet for that yet. Some come close but eschew the transactional part of ACID, making themselves basically useless for many applications.

And the parent post exactly matches my usage of jQuery :D

Re: Virtual DOM is pure overhead (2018)

#135

Post by [deleted] »

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…

[deleted]

Re: Virtual DOM is pure overhead (2018)

#136

Post by Sawamara »

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 elements, and started to build local data structures to see which was rendered last,and to what, to avoid rerendering everything, and to optimize to the change-based render only.

A few weeks of this, and it dawned on me that had I needed to generalize my solution, I would have arrived at the exacty same model that hyperscript does for its diffing, and something similar to whats underneath React's diffing method (or Preact since I prefer that, but they share the API).

So yeah, virtual dom is just a more clever and straightforward way to map your state to the dom, identifyng exactly where the changes happened, and only updating those nodes, instead of doing any queries towards the dom api (costly, can cause rerender,like when checking for bounding boxes, etc).

It IS more useful because you no longer need to maintain a hyper-specific update function per project and manuallí created/maintained differs.

Re: Virtual DOM is pure overhead (2018)

#137

Post by sam0x17 »

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…

Convenience is to be taken with a grain of salt, though. In the node.js world, "is-odd" can be a package, and it can have 926,000 weekly downloads and 22 dependents.

Re: Virtual DOM is pure overhead (2018)

#138

Post by namelosw »

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…

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 own that differs from JavaScript?

Re: Virtual DOM is pure overhead (2018)

#139

Post by Sawamara »

pier25 wrote: post #66
kevingadd wrote: post #4

Virtual DOM is a shaky long term bet since it's essentially betting that the cost of DOM operations will always be high enough to justify all the work you're doing (both at runtime and at trying-to-figure-out-how-to-write-this-code time). When it's easy to do your virtualization, you can just go 'well this is an optimization i can remove at any point', but if it's suddenly so complex it introduces bugs, you're in tro…

The cost of the DOM operation is the same. The difference is that React batches the changes to reduce the number of operations whenever possible.

Ew, not really. Even the getters can be performance-heavy in DOM-land. If you store your data in JS-land, and only diff against that, you never need to touch the dom for anything, except the endpoint insertions. At worst, it is matched evenly by any sort of custom vanillaJS+Dom manipulation tool (which needs to be perfectly well written, and hand-crafted to match what you are currently working on). At best, its several orders of magnitudes faster compared to a badly written DOM-manipulation-heavy code.

Re: Virtual DOM is pure overhead (2018)

#140

Post by galaxyLogic »

nemothekid wrote: post #83
thatswrong0 wrote: post #71

Earlier quoted context omitted.

I know that in concept not needing compilation is nice because it’s one less thing to have to worry about, but I don’t think I’d want to use JavaScript without any compilation. Just curious what the use case for not doing compilation is?

> Just curious what the use case for not doing compilation is? I'll add another one - the code that comes out is the code that goes in. Remember the days of Coffeescript and minimization before sourcemaps? When most of your work comes from maintaining a codebase being able to effectively debug your code is crucial and hitting an error in production that is only painfully traced back to development will quickly offset…

I think this is the the big reason to prefer plain old JavaScript. Compilation is ok in Java etc. where you can still debug your Java-code. But with many of these JavaScript frameworks I don't think that is possible, is it?

I would add that "debugger" is not mostly a tool for finding and fixing bugs. It is tool for code-understanding, giving you a "live view" of your code, for READING your (or someone else's) code in the order it executes.

Post reply on HN