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

261–270 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#261

Post by gedy »

LandR wrote: post #228
Udik wrote: post #198

Earlier quoted context omitted.

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

I've recentlt started working on a project where they store data / state in the ids of dom objects. Sometimes even something like dash separated strings that need to then be parsed. I come from having done pretty much no Web development and this seems like a hateful way to do development.

It is, and basically the selling point of modern front end practices like APIs, state managed only in JS, SPAs, etc. Maybe this tech is overused in some cases, but it's vastly better than the "JavaScript Sauce" type development you describe.

Re: Virtual DOM is pure overhead (2018)

#262

Post by stolsvik »

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…

Why don't the credit of "changing the culture of how we thought about state management on the frontend" go to AngularJS? At least Angular is what changed it for me, and it is the oldest of them.

Re: Virtual DOM is pure overhead (2018)

#263

Post by pcmaffey »

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…

And my favorite case - that zero is false. (!!0)

Re: Virtual DOM is pure overhead (2018)

#264

Post by berns »

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…

DynamoDB now has ACID transactions across tables.

https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-transac...

Re: Virtual DOM is pure overhead (2018)

#265

Post by oceanstone »

sam0x17 wrote: post #254
avip wrote: post #145

Earlier quoted context omitted.

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

> All of them work, but are prohibitively expensive to get started

Firestore has a free tier: https://firebase.google.com/docs/firestore/quotas#free-quota

Re: Virtual DOM is pure overhead (2018)

#266

Post by epidemian »

bastawhiz wrote: post #239
dsissitka wrote: post #74

Earlier quoted context omitted.

Rich recently addressed this: https://youtu.be/AdNJ3fydeao?t=1128

I think it neglects Dan's original point. Say you're doing a search input that filters a list of elements using fuzzy matching. No amount of optimization in your components or the framework is going to make the fuzzy string matching library you use work faster. Faster renders might make more room for the main thread to update, but fundamentally the problem persists. Concurrent React would allow you to type while the…

> Say you're doing a search input that filters a list of elements using fuzzy matching. No amount of optimization in your components or the framework is going to make the fuzzy string matching library you use work faster. > Concurrent React would allow you to type while the fuzzy matching happens asynchronously.

Are you sure that is the case?

From what i gathered about concurrent React and Fiber is that it can split the rendering of multiple components into different time slices, and also give more priority to certain events, so that some re-renders are kept smooth and responsive (the input typing on the demo), while others can be split into multiple frames and delayed a bit (the update on the carts).

But all React can do is to split up multiple render() calls (or function component calls) into different time slices. It cannot "slice" a single render() call any further. So, if there's an expensive synchronous computation inside that render(), like the hypothetical `fuzzySearch(query)`, that computation will block the main thread no matter what, and the application will be unresponsive until that computation finishes.

There's no going around that if the fuzzy match function is synchronous. That function would have to be changed not to block the main thread. E.g., it could have a timeout so it doesn't take longer than, say, 10ms, and return a partial list of results on that case. Or be a generator, so you can consume its matches one by one and split that work into different frames. Or you could move that computation to a webworker, thus making it effectively asynchronous, and avoiding blocking the main thread.

I don't think there's much React, or any framework, can magically do in this case to make a synchronous expensive operation not block the app. But maybe i'm completely wrong and that's exactly what concurrent React does; or maybe i misunderstood your scenario entirely :)

Re: Virtual DOM is pure overhead (2018)

#267

Post by osrec »

markharper wrote: post #255
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.

Yes, it's a similar idea. The only difference I can see is that in our library, the dependencies are automatically tracked, and there is some additional clever scheduling around when a function should be run.

Re: Virtual DOM is pure overhead (2018)

#268

Post by chillacy »

sam0x17 wrote: post #254
avip wrote: post #145

Earlier quoted context omitted.

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

Hmm I wonder if spanner has more minimum hardware costs or something. Like if they have to provision you at least one standalone atomic clock to get started.

Re: Virtual DOM is pure overhead (2018)

#269

Post by hatch_q »

xtagon wrote: post #6

Svelte's philosophy on turning the virtual DOM concept inside out sounds like it has merit, and is very promising. But it's going to take a lot more than that, in my opinion, before a large number of people consider switching from React, Ember, etc. I don't see that as a drawback, I see it as an open opportunity for Svelte to keep building out on improvements other than the DOM updates, and catching up with everythin…

Tooling is the key word here. Svelte simply doesn't have the tooling needed for any big project. - testing/testability (unit-tests are easy, but what about functional, e2e?) - strong-typing support (flow, typescript) - good IDE support? - i18n? ICU support, etc? They need to redo what ember-intl or react-intl do.

Without these things it's simply not viable to start bigger projects with new framework.

Re: Virtual DOM is pure overhead (2018)

#270

Post by davidjnelson »

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…

> perfect automatic horizontal scaling

Nothing is perfect, but aws aurora serverless auto scales compute and storage for MySQL https://aws.amazon.com/rds/aurora/serverless/

Post reply on HN