Is this another ‘optimize away this extra 5ms step on the worst phone in existence’ article? I need some rough numbers before I’ll pay any attention to something like this.
I don’t want to sound too negative (but I’m about to): this attitude in web development really bugs me. Shaving 5ms off render time on a crappy Android device should be a desirable goal, not something you have to be cajoled into doing. You should be motivated by that! But instead the industry is all about “DX”: is that change going to complicate my precious build script? Then out the window it goes.
We have an industry that prioritises developer experience over user experience and I think that has a role to play in the shittiness of the web these days.
I just don’t see a convincing (concrete) argument in this article.
And if you check the replies you’ll see examples of other, more efficient ways to do the exact same thing.
It speaks to a bad level of myopia in the React community that when presented with the challenge of “put statically rendered markup in HTML” the accepted solution is “take that markup, transform it into a bloated JS representation, transform it back to markup during server side render while also shipping the bloated representation in the client JS, then unnecessarily hydrate that representation on page load” and no one sees any problem.
of course if what the HTMX cult is chanting is true, then the best way to get the job done and save cycles is to skip as much of the frontend dev stuff as possible. (though this would probably lead to the problem of how to hire a dev versed in the occult.)
Here’s the thing: I would love to worry about 5ms optimizations, but my time is limited and there’s hundreds of 100ms optimizations I can do first. Those haven’t got done because, again, my time is limited and we had plenty of infinite-ms optimizations to do first by making various things possible to do at all.