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 (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.
> 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.
No, adding another button does not duplicate the entire underlying libraries used to display said button.
Yeah, I don’t even know why people who are that clueless about frameworks are commenting; it takes less than an hour of learning of modern web development, from scratch, to shut down that notion. And other libraries to manage dates and stuff? Excuse me? How does that have anything to do with the rendering framework? Completely orthogonal choices.
And asking about basic math on download speed is golden. No idea how someone can “manage a team trained in classic web design” without that knowledge and then pretend to care about performance.
Eh, I'm clueless about this aspect of the framework (if you can call such a steaming pile of resume-driven-development such), and honestly I'm thankful for it.
Libraries like dayjs add complexity to the overall codebase and it's another piece of code you need to keep track of, update, and repair when its makers decide to go a different direction with it or some script kiddie decides to introduce a backdoor into it.
I think your larger concern shouldn't be about the "clueless people" who are commenting on this thread and rather the number of upvotes my comment got (especially compared to your rant). Clearly it struck a chord.
People are commenting and upvoting because the choices that went into building React leaves a lot of room for frameworks like Nue, Vue, hell even HTMX. Just because (it sounds like) you've staked your career on thinking React, the McDonalds of frameworks, is awesome doesn't change that.
No I’ve not staked my career on React, I’m not even primarily a front end guy and React is my least favorite framework among popular ones, but thank you for your concern. I was debunking one ridiculously wrong comment criticizing my least favorite framework with solid, reproducible statistics, but that’s apparently a rant compared to your very insightful questions like “100ms to download 100KB, is that fiber? Cable? 5G? 4G?”, then okay. You clearly struck a chord with a large number of people so out of touch that they believe a copy of React is required for each button, and pride themselves on such ignorance because it’s “resume-driven-development”, so congratulations.
(Another tip: Don’t bring votes into discussions, it’s both against site guidelines and laughable.)
> (Another tip: Don’t bring votes into discussions, it’s both against site guidelines and laughable.)
Honestly: thank you, I didn't know that and won't do it again.
> 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.
What special way is that? One of the big draws of React is its minimal api surface, and the ability to write standard JS alongside of your presentational HTML.
I am also curious what "classic web design" actually means, I have a theory, but I am curious all the same
I was speaking directly to the reactive framework itself (which is a smart way to get around some limitations), the div salad it pushes developers to sustain, and the fact that they felt they had to rewrite HTML such that instead of typing <h2> devs have to type something like <Heading.
HTML is a pretty simple markup language and abstracting from it doesn't seem to make any sense.
And I think your theory about what I mean by "classic web design" is probably right; keeping the JS separate from mark-up is one example of how I wish I could go back in time.
But I can't. So it's time to learn to manage people who want to go this direction.
Meta wrote React for Facebook mainly, and most other projects won't touch that scale. In my organization's case it's like we're water-skiing behind an aircraft carrier. It's the wrong tool for the job, and having three people manage 37k lines of code (excluding libraries) is tough.
> HTML such that instead of typing <h2> devs have to type something like <Heading.
...but they don't? Just use <h2> haha
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.