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

251–260 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#251

Post by charrondev »

Bahamut wrote: post #229
namelosw wrote: post #18

I thought this was well known years ago. A better description for VDOM should be 'It's not fast, and is not slow either'. But frankly, what I see in virtual DOM is not about speed. It's a declarative interface, an abstraction. It's more like a blueprint that's easier to interpret across different environments like React Native, WebGL. Even if you don't need any of these cross-platform benefits it's still good for tes…

I work on one with React that is too slow in the browser with a team that only has senior devs, and users even filed bugs about the performance - we do heavy computations, and React's model of blocking rendering on having everything updated can freeze our UI for up to 10s while data comes in from various API requests. I believe our app would be performing much better for the end user if we were using Angular 2+ inter…

This seems almost entirely unrelated yYou framework though.

You are blocking rendering on IO. This can be greatly improved by offering

- Good loading indicators that stay consistent for related IO. - Caching to speed up or remove the need for requests. - Fetching related data in parallel. - Prefetching data.

Re: Virtual DOM is pure overhead (2018)

#252

Post by peterangular »

the_duke wrote: post #159
muxator wrote: post #92

Earlier quoted context omitted.

Which sometimes is not bad at all. Ever tried to ctrl-click an interface element (a navigation button, a menu) because you want to open its view in a new window? A lot of (admittedly badly coded) "modern" web apps ignore basic web idioms (like hyperlinks) and assume as unique single user workflow the one its designer tought the app (and the only one he tested).

A nice example of this: with the new Reddit interface, only visible comments are rendered, so you can't use your browser search functionality to search all comments on the page, just the ones currently in the viewport.

Amen to this. The new Reddit interface is a step backwards in functionality due to this sorta stuff and effectively breaks user experience.

Just to give an idea how bad it is: loading the front page cold of new reddit = 9685KB. Loading the front page on the old reddit (also cold) = 737KB. The compute profile is literally half for old.reddit.com (new peak 16%, old peak 7.5% - both metrics core-distributed over an 8c system; 1s sample rate).

I LOVE all of this talk that front-end devs like to have on optimization/state stability. Talk to an browser automation expert, esp. one that does it at scale. Almost 100% of the time older/simpler front-end tooling/development is faster and less error prone. Older also takes a FRACTION of the compute/memory/proxy resources. It's been this way for years!!!

ducks for the inevitable storm of HN hate for having a strong opinion

Re: Virtual DOM is pure overhead (2018)

#253

Post by sam0x17 »

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)

Yeah but point being, if you need to use is-odd, what you probably need more is something tailored to your particular application.

Re: Virtual DOM is pure overhead (2018)

#254

Post by sam0x17 »

avip wrote: post #145
sam0x17 wrote: post #134

Earlier quoted context omitted.

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.

Yeah there are a few in that category also Google Cloud Spanner and the stuff by CitusData. All of them work, but are prohibitively expensive to get started. I've harangued them a number of times about how people aren't going to want to use something they can't scale up from $1/month to $10000/month without migrating any data (that's the whole point of an auto-scaling horizontal service imo), but so far no changes from them. Like why would you design potentially infinite auto-scaling, and then lock it up behind a $90/month minimum fee. They could have been making money all along on those $20/month or $40/month or $5/monthers, who vastly outnumber those who _need_ autoscaling, but what the peace of mind that auto-scaling provides.

Re: Virtual DOM is pure overhead (2018)

#255

Post by markharper »

osrec wrote: post #24

We implemented a library at my company that does not use a virtual DOM, but instead captures reactive "change functions". The framework captures dependencies between the reactive "change functions" and underlying variables, and executes the functions whenever a variable's value changes. You can also have dependencies between variables (like computed vars in Vue), and the lib works out the correct order for calculatio…

That sounds similar to the incremental lambda calculus described in this paper: https://arxiv.org/abs/1312.0658 There's an implementation for DOM updates in Purescript (https://blog.functorial.com/posts/2018-04-08-Incrementally-I...), but I haven't come across a similar approach in Javascript yet.

Re: Virtual DOM is pure overhead (2018)

#256

Post by marcosdumay »

DonHopkins wrote: post #178
fauigerzigerk wrote: post #174

Earlier quoted context omitted.

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…

Let the fight begin! It goes well with some popcorn.

I can understand how fundamental education teachers don't grasp modern Algebrism and believe that Math is formed by fundamental, sacred definitions. But programmers ought to know better.

Re: Virtual DOM is pure overhead (2018)

#257

Post by gorbypark »

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.

In vue (or atleast the way the majority of people use vue), each component is separated into a .vue file. That component's template, style and business logic is all encapsulated in that one file. A basic .vue file starts out with . It keeps everything nice and simple, in my opinion. Each different "mode of thinking" is separated out, but still all together in one file.

Re: Virtual DOM is pure overhead (2018)

#258

Post by amelius »

I think most people in this thread focus too much on the vdom, and miss the important part of the post:

> Unlike traditional UI frameworks, Svelte is a compiler that knows at build time how things could change in your app, rather than waiting to do the work at run time.

Re: Virtual DOM is pure overhead (2018)

#259

Post by ivanhoe »

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…

To me the core problem wasn't with the data model, it's just that a declarative approach to binding events and reactive updates that knockout, vue, react, etc. provide reduces significantly the amount of repetitive, boilerplate code that you need to write. All that searching for nodes, adding handlers and callbacks, then updating the DOM when data model changes is now handled by frameworks. As you've said, this is not really jQuery vs React issue at all, jQuery just provides some nice cross-browser shortcuts. The main problem IMHO in jQuery era was in keeping the binding/callback logic separated from the html templates that define the dom structure itself. In big apps it made it difficult to follow which code binds to what part of UI, and there was no way to prevent someone from binding to the same node you're working on from some completely different part of the app. Now with declarative approach it's all in the same place and it's immediately clear what handlers you have in place on any html element, making refactoring much less stressful.

Re: Virtual DOM is pure overhead (2018)

#260

Post by tptacek »

rayiner wrote: post #85

Only ever having used MFC and Swing, this seems odd to me. A diff of the entire DOM on every state change? You never see anything like that in native toolkits. ELI5: What problem is that solving?

You write your UI declaratively, in almost straight-line code, and never "update" anything in the UI itself. It's significantly easier to write.
Post reply on HN