I don't know how they perceive the performance. I see 41 network requests. That's 2.1 MB of CSS over the wire, blocking rendering and hurting painting and loading speed. There's 400 KB of Tailwind, 87 KB of general CSS, plus another 200 KB of other general CSS. They need to embrace functional CSS properly. I'm sure they could have a single CSS file under 80 KB that renders everything.
These type of comments often come from a place of arm-chair reasoning where you might not sit on the experience of working hands-on in a large team on a large product. While it’s probably true that X kB sufficient, that amount of performance optimisation is usually not warranted at this scale. Maintaining a design system, working with scoped classes, legacy code, and dealing with the complexities of chunking and probably further challenges we are not aware of from the outside. It seems like a common sentiment on HN (maybe not you in particular) is that engineers should drop everything and work overtime on optimizing performance, when it comes to web apps
This sort of comment has completely lost the forest for the trees.
You’re conflating scale with bloat. At large orgs the problem is that nobody is willing to step back and say “this sucks”. Trying to get this fixed involves getting 6 teams to agree upon something with no clear owner for the outcome and with everyone incentivised for not being blamed if one of the other groups tanks the effort.
> engineers should drop everything and work overtime on optimising performance
No, we’re asking for it to be taken seriously by the organisation. I work in games, and on large projects we usually have a small team (2/3 people of a team of 80-100) who are constantly working on this stuff. Their work is “subjective” improvements but often it’s just building tooling and telling other groups what they need to fix.
Frame rates are very important, so we prioritise them. That’s about it. The same “bloat” is often found in internal tooling in games. Unreal is a great example of it, nobody _really_ cared about how long packaging a build took, it got ad hoc improvements, but then epic decided to invest in it and its improved monumentally in the last 2-3 years. (Disclaimer, I worked there when nobody cared and was responsible for some of those as hoc changes)
meerita · · focus · HN ↗
karolusrex · · focus · HN ↗
maccard · · focus · HN ↗
You’re conflating scale with bloat. At large orgs the problem is that nobody is willing to step back and say “this sucks”. Trying to get this fixed involves getting 6 teams to agree upon something with no clear owner for the outcome and with everyone incentivised for not being blamed if one of the other groups tanks the effort.
> engineers should drop everything and work overtime on optimising performance
No, we’re asking for it to be taken seriously by the organisation. I work in games, and on large projects we usually have a small team (2/3 people of a team of 80-100) who are constantly working on this stuff. Their work is “subjective” improvements but often it’s just building tooling and telling other groups what they need to fix.
Xunjin · · focus · HN ↗
maccard · · focus · HN ↗