3 ms·

I don’t think there’s anything wrong in pointing out that X is a better practise than Y, even if only by a small amount. As the tweet in the article points out,

I don’t think there’s anything wrong in pointing out that X is a better practise than Y, even if only by a small amount. As the tweet in the article points out, it’s really easy to multiply that tiny benefit by 1000 icons before you know what you’re doing. Why not start off on the best foot? 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.

Aeolun 3y ago
That’s not really my point. All of these icons will cost you 5ms at worst. Should we make that tradeoff in the first place? The article present this as something you must do, or else you don’t care about your users. But as someone else points out elsewhere, including the icons in your code means no lazy loading, so everything is either instantly there or not at all. That’s a much bigger user benefit than a minimally faster bundle load. I just don’t see a convincing (concrete) argument in this article.
- afavour 3y ago
  > But as someone else points out elsewhere, including the icons in your code means no lazy loading 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.
  - pas 3y ago
    ... getting the job done is usually the first priority. wasted CPU cycles are comparatively cheap. just as experienced devs, who can write more optimized code are expensive. 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.)
  - Aeolun 3y ago
    You are making things harder than they are. I ship the representation to the client once (as a JS string) and then render it there as many times as I want. No SSR involved.
Swizec 3y ago
> 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! 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.

Aeolun 3y ago

That’s not really my point. All of these icons will cost you 5ms at worst. Should we make that tradeoff in the first place? The article present this as something you must do, or else you don’t care about your users. But as someone else points out elsewhere, including the icons in your code means no lazy loading, so everything is either instantly there or not at all. That’s a much bigger user benefit than a minimally faster bundle load. I just don’t see a convincing (concrete) argument in this article.

afavour 3y ago
> But as someone else points out elsewhere, including the icons in your code means no lazy loading 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.
- pas 3y ago
  ... getting the job done is usually the first priority. wasted CPU cycles are comparatively cheap. just as experienced devs, who can write more optimized code are expensive. 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.)
- Aeolun 3y ago
  You are making things harder than they are. I ship the representation to the client once (as a JS string) and then render it there as many times as I want. No SSR involved.

Swizec 3y ago

> 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! 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.