Re:JavaScript Bloat in 2024
by alexey2020 on Friday February 23, 2024 @06:49AM
(#39479459)
came here to write a similar comment.
Totally agree!
Focusing on a particular metric for the sake of the metric - what's the point?
Let's spend a couple months, refactor an app to generate less js just to look cool in the eyes of dev community?
Re:JavaScript Bloat in 2024
by AHTERIX5000 on Friday February 23, 2024 @08:44AM
(#39480463)
But the experience is not smooth as it can get if you're running a bit older HW. Gmail and Slack are notorious for bad performance even when the content displayed is rather simple plain text. As a user I don't really get anything in return when developers decide to use complex JS solutions for simple use cases.
I think it serves as a generic metric for bloat, because nobody really optimizes for size, thereby making it a good untainted metric. As the web gets bloaty and slow, the size of the websites grow as well, which also invites using size as a metric for bloat.
Smooth, fast, nice, these would be good to measure, but it's much harder. I like an interface response time metric, for example [0]. I always lament that interfaces are getting slow - I get that they are nicer, too, but god damn why am I waiting 1 second for anything, when my Pentium III with Win XP was near instant?
[0] https://www.nngroup.com/articles/response-times-3-important-...
Is the problem here that they perform poorly on slower computers/connections? Is it even true? Is there an audience of developers who can't use Vercel or GitLab productively because of that? Any metrics to support that? IMHO optimizing against bundle size/JS sent over the network is one of the worst metrics for performance I could imagine.