[afavour]

I think that kind of criticism is a reaction to the lack of critical examination of the industry standards.

I don’t think React is straight up bad by any means but I do think it is chosen unthinkingly in scenarios where it isn’t necessary. And what of Preact? It’s a 3kb library (compared to > 100KB for React) and is a drop in replacement for probably over 90% of React sites. That wastefulness speaks to an inattention to detail.

I see articles like this as a provocation to pay more attention rather than a serious proposal.

[ZvG_Bonjwa]

There is some good food for thought here.

One thing I’ll also say: building static websites and building big interactive web apps are two points on a LONG spectrum. Yet for some reason online discourse ignores this.

This enormous spectrum gets compressed into just “modern web dev” or “JavaScript”. Not just in conversation, but in teaching materials, job postings, you name it. It leads to wild disconnects and disagreements between people who think they are peers but are actually building radically different things.

[afavour]

100% agreed. If you’re making Gmail the extra bulk of React is an afterthought in the context of a giant web app. But when you’re building a mostly static marketing site and don’t consider what’s going to get the thing to load as quickly as possible you’re not prioritising the right things, IMO.

[AstroBen]

Preact adds, among other things..

1. Potential compatibility issues. Their preact/compat package doesn't cover 100% of cases (of course it doesn't, otherwise it'd just be React)

2. Risk. Will this thing be maintained long term? I mean sure a potential migration to React probably wouldn't be too painful but.. why?

So, starting from "The average speed for 4G LTE is typically between 10 and 30 Mbps for downloads"

Saving 100kb buys you what exactly? The initial download certainly isn't a factor.. and in a case where the performance really matters you probably want to skip both anyway

[nchmy]

The average speed/connection is not 4G LTE.

And react usually is not just 100kb.

SSR html is vastly faster for all parties involved. So much so that all spa frameworks have introduced some sort of server rendering, astro is growing a lot, and things like htmx, datastar, hotwire etc are all getting a lot of fawning attention.

[rkomorn]

> I do think it is chosen unthinkingly in scenarios where it isn’t necessary

Does this genuinely matter beyond (borderline dogmatic) perfectionism?

There are plenty of things that make products or projects bad, and I'd say, at most, the choice of framework is incidental. It only becomes symptomatic when you have an axe to grind.

[afavour]

IMO, yes. There are a lot of people out there with underpowered devices or slow internet connections (including me when I’m on the subway!) and modern web dev practices that output MBs of JS for simple things are a terrible experience. Just not one experienced by the developers on super fast computers and wired internet connections.

Try browsing the web with Chrome’s network throttling and CPU throttling enabled. It can be torturous.

Just to cite it again: there’s a 3kb library available that does 90% of what a >100KB library does. That no one ever even considers it is not about “perfectionism” in my eyes, it’s industry wide laziness.

[9dev]

If you're using my web app (I wouldn't have used React if it wasn't an application anyway, right?), you're very likely a returning visitor. Even if your first page load after signin in is a drag because you're on the subway and for some reason 100KB take five seconds—you're probably coming back anyway, because my app warrants recurring usage (and the industry heavily optimises towards that, but that's a different story).

So on the second visit, you'll have my vendor bundle cached anyway, the app loads instantly, and you will never even remember how long the first load took.

Given that—tell me again why I should care to convince my boss we need to put considerable investment into an alternative technology with a bunch of dragons lurking about, that may or may not be abandoned in a few years and bite us later on, which might introduce compatibility issues with new libraries, which existing staff and new hires must be trained to account for?

Why would I opt for a world of potential pain, just to make your first page load under bad (thus: rare) conditions slightly better?

[nchmy]

If Html and browser APIs might be abandonned in a few years, We've got bigger issues to worry about than react vs backbone

[littlecranky67]

That 10% missing are event normalization and event bubbling (preact bubble through DOM, react follows vDOM). Choose yourself what you need, but 100% compat with 3rd party libs is why I stick with react over preact.

[nchmy]

The browser bubbles events natively...

https://developer.mozilla.org/en-US/docs/Learn_web_developme...