alt Hacker NewsAn extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity (which includes breadth of ecosystem). I can be both productive and respectful to my users with these common frameworks.
Note that I'm very mindful of web performance, and I've been quite vocal on this site about some alarming trends like calling for the end of bundling (native esm) and roundtrips for everything (liveview and co., or at least the abuse of them). In my experience waterfalls and roundtrips are the number one thing hated by people on slow and/or unreliable networks; 100KB added to a flat bundle at load is almost nothing.
Replies
Although payload can be indicative of page load speed, there are many good reasons Lighthouse scores are more complex than that. Specifically, at the start of this thread the criticism was that the js work in modern web apps is slow. I have thus far managed to avoid using react so I don't know the actual numbers, but I don't think the conversation should be reduced to payload size, even if it is obviously important. When I profile problematic pages, other than sites that don't properly scale their images, it is not usually network that bogs them down, it is the rendering.
Even focusing on Lighthouse score or similar for a basic app is totally missing the point of Nue as presented on the linked page. It about a framework designed for speed that can handle data at scale, that is easier to control and personalize, and easier to model and thus architect. And yes, of course, most any framework can be used for good work, but the relevant question here is which one promotes it the most from start to finish, and makes it the easiest to implement. Speaking only for myself, this focus is great to see.
> An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity
Is that 100ms on fiber? Cable? 5G? 4G?
Is that for the first button? Or each button? And what happens when you next need to manage dates as objects? Do you pull down dayjs or do you wrangle it yourself? What other libraries do you need to add? How's build speed? How much time to the linters take as they cascade through all that code? How are your Next.js (a pretty standard companion to react) version updates going? Keeping up with security alerts?
I'm biased against React because I manage a team trained in classic web design who now have to manage a giant React codebase and learn its special way of doing things, and it's a slog.
Agencies are going to keep building with React because they can get 90% of a project done in no time flat, and they don't have to deal with the infra challenges after they get their check. Small clients like us will continue to fall for it and slowly grind to a halt as the infrastructure pulls the team to a standstill.