Hacker News Reader

Comment by ferdowsi | Hacker News Reader

I feel like nobody is asking: what is the point of all this performance chasing with frontend frameworks? You might get a millisecond here or there. So what?

In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application. It's almost always some type of network communication issue, be it the database stalling or static assets not being served. Where JS rendering might be a problem is at Facebook SPA scale, and the vast majority of apps are not Facebook.

View on HN

For the applications I have worked on, rendering is basically the only reason for unresponsiveness. Loading from the network happens asynchronously and doesn't block the JS thread so any other interactivity or loading state/animation should work just fine. If loading over the network makes the application seem unresponsive, that's generally just bad UX implementation.

I am currently working with low-latency audio and the latency requirements mean I have minimal buffering. While the VDOM render cycle is generally fast enough to be unnoticeable to the user, it stalls the audio buffering just enough to cause some stalling. There's a few heavier parts of the application where the rendering is expensive enough to briefly stall animations as well.

While both of these issues are something we need to fix, it is specifically the rendering/vdom process that we need to work around to address these performance concerns, and we are definitely not at all Facebook.

> In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application.

Implemented a undo/redo stack on top of Vuex once that worked on some very large data structures.

Got unresponsiveness after only ~3 changes to the data. Purely due to how Vuex checks state for changes. No network, no database; purely in the frontend client.

Ended up needing to freeze the state as I pushed it into the Vuex store, so Vuex wouldn't check previously pushed state for changes.

My point is, there are multiple places where, if you are building an app of scale, you can run into client performance issues.

Would you mind elaborating a bit on _how_ you implemented this? In my experience with Vuex and large datasets with dozens of stores, the devil is in the detail and how you change stuff matters a lot.

For example, you can't just create and keep a copy of a dataset / variable. It will remain reactive. You need to clone it. Failing to do so will indeed quickly clog up... everything :D

you don't have to clone it. cloning the object and putting it in Vuex will still result in it being reactive.

`Object.freeze` is what I used. This causes Vuex to not traverse the object for changes. in my case, the objects I was pushing into the Vuex state were essentially immutable once I pushed them in, so this did the ticket.

well, that, and only pushing partials of the entire state, so the object model didn't get too unwieldy. To get the total state, i just replayed the changes on top of the base state. base state was reset once the number of changes got to a certain size.

You are considering this from the side of one web app, but users generally will have dozens of tabs open. When you need a Core i7 with 16GB of RAM to handle your browser, because each developer didn't care about their individual performance, the web experience becomes a nightmare.

Lots of vdom frameworks are more than fast enough to run business-style SPA applications, but start being very laggy for data visualisation kind of work, or anything where complicated animation combined with user interaction is involved. This means the developer only gets a nice declarative framework sometimes, and has to go back to a more messy way of thinking otherwise.

Svelte (and some other contenders, like concurrent mode React) improve performance enough that interactive animated datavis stuff can also be done declaratively.

Batteries. Inefficient JS aggregates to result in significant energy use.

If I'm building a desktop app that will run in the browser then it isn't much of an issue, but if that same app is expected to run on a mobile device then my wild JavaScript kludges start to really matter.

So it's no surprise why devs choose React over anything less plush. They test on desktop, test on their plugged in cellphones, and call it good.

It's not only performance, but cpu time and data volume.

And battery life.

Tell that to my cpu when using the new reddit

Reply on news.ycombinator.com