undefined | Better HN

0 pointstgv2y ago0 comments

The user already is. The casual user's system is idling with all sorts of nonsense. Adding some light processing doesn't harm. I'm thinking 100-500ms per page. You don't render the page for the user neither, do you?

For heavier use cases (e.g. image processing), the user should be willing to spend some CPU power. It doesn't make sense to send an image to a server, put it in a queue, wait for an image processing worker to run it, and send back the result. It's simpler and more sensible to run that process client-side, if feasible. E.g. LLMs are too big for that, but many other tasks can.

0 comments

nottorp2y ago

Some "light processing" like 10 seconds of instantiating <js framework of the day> crap that gives me nausea while it redraws infinitely and boxes move around on the page?

Even the mobile oriented samey SAAS sites that have you scroll through 20 screens to read 5 lines sound better...

Edit: Btw, 100-500 ms on what? The latest Intel 500 W space heater? And tested only in Chrome because it's too expensive to notice that it's not very fast or responsive on other browsers?

Edit 2: Not to be misunderstood. If you're doing the computation for me, go ahead. If you're doing the computation because your framework has 100000% overhead, no thanks.

tgvOP2y ago

I don't like heavy frameworks either. I try to keep everything light, both server and client-side. 10s loading animations is too much. But having no framework at all severely limits development speed.

All browsers are approximately equally fast nowadays. I use Firefox, so no worries there.

j / k navigate · click thread line to collapse