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

171–180 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#171

Post by vast »

lacampbell wrote: post #111
QuadrupleA wrote: post #32

So glad to see this article, I've long wondered how this "virtual DOM is faster" myth got accepted as gospel when clearly it's pure overhead, compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps). Can't speak to the svelte approach due to inexperience with it, but good to see this myth challenged - react.js is fine but I worry there's been a ca…

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.

React and friends made themself show up on every party. Even if the model isn't remotely appropriate for the taks at hand, you have to argue about them. I am convinced that half the modern frontend devs don't even know how a "classic" web app could work. SPAs or frameworks usually used for SPAs are the default state and there isnn't any competitive option with a real name except jquery/ajax/html. Even talking about the latter will brand you as dinosaur in many circles.

Re: Virtual DOM is pure overhead (2018)

#172

Post by mercer »

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…

Do you really believe all of us React users are patsies and you're conveniently one of the smart guys who hasn't fallen for it?

Surely a more reasonable perspective is that React actually solved a real problem, and the fact that there's a big company backing it is actually a benefit because 1) there's a lot of money and experience poured into the project, 2) it's likely to be supported even if the lead dev gets hit by a bus, 3) it's an easier sell to management over ?

I'm no fan of Facebook the company and product, and I avoid client-side code as much as possible (yay Phoenix LiveView), but I think React is quite neat and made my client-side work easier. I'd also argue that it paved the way for an important shift in how front-end frameworks do their thing, and we're all better off for it.

Re: Virtual DOM is pure overhead (2018)

#173

Post by guipsp »

galaxyLogic wrote: post #140
nemothekid wrote: post #83

Earlier quoted context omitted.

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

>But with many of these JavaScript frameworks I don't think that is possible, is it?

It is, and works pretty much out of the box nowadays

Re: Virtual DOM is pure overhead (2018)

#174

Post by fauigerzigerk »

nailer wrote: post #158
sam0x17 wrote: post #137

Earlier quoted context omitted.

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.

Makes sense, you don't want to write your own tests for handling zero.

is-odd doesn't have any tests for handling zero. What would they be anyway?

What is-odd does is to throw an exception if you pass anything that isn't a safe integer or a string representation of a safe integer. Otherwise it just returns n % 2 === 1 (after converting string to int if necessary)

Re: Virtual DOM is pure overhead (2018)

#175

Post by floatboth »

concerned_user wrote: post #163
radicalbyte wrote: post #152

Earlier quoted context omitted.

That's just a symptom of Javascript being the entry-level language. You can be sort of productive without ever understanding how anything works. Where these frameworks really come into their own is when you want to create reusable components and share them outside a team. jQuery did a good job with their plugins back in the day but Angular 2 (and React, and soon native Web Components) so that far better.

I hear the tale of "soon native Web Components" for years and still none in sight yet. As far as I remember there are some attempts from Chrome and Mozilla but not sure I saw a real cross-platform spec out, so I stopped tracking the news around it really. Can you provide some references maybe?

https://caniuse.com/#feat=custom-elementsv1 https://caniuse.com/#feat=shadowdomv1

v1 shipped with Chrome 53, Safari 10 and Firefox 63. (And there's a polyfill.)

It's not "soon", it's very much "been in production for a while".

A base class like LitElement https://lit-element.polymer-project.org is all you need to achieve a sort of "react-like" development style (components with unidirectional data flow) WITHOUT build tools() and WITHOUT dom diffing! :)

() if you want to use npm dependencies instead of just plain files with a bundled version of lit, you still need to rewrite import paths, until https://github.com/WICG/import-maps becomes a thing at least. I wrote a tiny dev server that does that: https://github.com/myfreeweb/es-module-devserver

Re: Virtual DOM is pure overhead (2018)

#176

Post by DonHopkins »

nailer wrote: post #158
sam0x17 wrote: post #137

Earlier quoted context omitted.

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.

Makes sense, you don't want to write your own tests for handling zero.

Teach the Controversy [TM]!

https://en.wikipedia.org/wiki/Parity_of_zero#Education

Claims made by students:

    "Zero is not even or odd."
    "Zero could be even."
    "Zero is not odd."
    "Zero has to be an even."
    "Zero is not an even number."
    "Zero is always going to be an even number."
    "Zero is not always going to be an even number."
    "Zero is even."
    "Zero is special."
https://en.wikipedia.org/wiki/Teach_the_Controversy

Re: Virtual DOM is pure overhead (2018)

#177

Post by floatboth »

hn_throwaway_99 wrote: post #91
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…

> This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail. I disagree with this. I think the major key insight and innovation with React, which this article fully acknowledges, is that it is much easier to think about declarative UI as solely a function of the current state without having to think about the transitions to arrive at that st…

lit-html also lets you write declarative UI without diffing (and use actual HTML tag syntax without any build tools): https://lit-html.polymer-project.org

and LitElement gives you a base class for Custom Elements that uses lit-html with Shadow DOM: https://lit-element.polymer-project.org

Re: Virtual DOM is pure overhead (2018)

#178

Post by DonHopkins »

fauigerzigerk wrote: post #174
nailer wrote: post #158

Earlier quoted context omitted.

Makes sense, you don't want to write your own tests for handling zero.

is-odd doesn't have any tests for handling zero. What would they be anyway? What is-odd does is to throw an exception if you pass anything that isn't a safe integer or a string representation of a safe integer. Otherwise it just returns n % 2 === 1 (after converting string to int if necessary)

You don't want to start a religious war between the people who believe zero is special, and the ones who believe it should throw an error if you pass a string, and the people who believe it should attempt to convert the string to an integer, and the people who believe you should either round or truncate when the parameter is a floating point number, and the people who disagree about which direction to round, and the people who can't agree whether you should truncate towards zero or negative infinity.

Re: Virtual DOM is pure overhead (2018)

#179

Post by floatboth »

guscost wrote: post #15

From the conclusion: > Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. In other words, Virtual DOM is somewhat-valuable overhead. This is a cool alternative, seemingly sort of a compile-time version of Knockout. It's probably worth a try for writing an efficient client app, but I have a hunch that I'd miss the "HTML-…

You can easily do HTML-in-JS "react-like" rendering without diffing!

lit does just that https://lit-element.polymer-project.org

Re: Virtual DOM is pure overhead (2018)

#180

Post by floatboth »

nemothekid wrote: post #10

Virtual DOM is pure overhead* * Compared to doing static analysis and optimizing your UI updates at build time. While I certainly agree that svelte's approach may be the future, I think React and others, are very much a needed stepping stone (especially when you consider all the work done transpiling JS code). The Virtual DOM was the most performant solution that applied generally to many a large number of cases. The…

No, you don't need to do anything at build time! (You don't even have to have a build time.)

You can just… instantiate a template, remembering where the "holes" are, to get precise update functions for every data field that gets inserted into the template. This is what lit-html does, and it's such an obvious approach I'm really surprised that VDOM took off before it.

https://lit-element.polymer-project.org

Post reply on HN