[ZvG_Bonjwa]

There is, I think, a sort of innocent arrogance that comes with people who boldly claim that renowned, well-adopted frameworks or technologies are straight up bad or a non-improvement over yesterday’s tech.

That’s not to say popularity guarantees quality, that progress is always positive, or that there’s not plenty to criticise. But I do think authors of articles like this sometimes get a big hit from being subversive by playing into retro-idealist tropes. The engineering equivalent of paleo influencers.

Such proposals would suggest a huge global collective of the world’s most talented engineers have been conned into fundamentally bad tech, which is a little amusing.

[hellcow]

People make mistakes using bad (but popular) tech all the time. Remember MongoDB when every app needed to be NoSQL for web-scale? Remember when everything was event-driven using Kafka? Remember when every left-pad needed its own microservice?

When large organizations (Facebook, Google, LinkedIn, Amazon) start pushing it, when popular developers blog about it, when big conferences run talks on it, and lots of marketing and ads and sales funded by ad revenue or VC dollars start pushing a tech as “amazing,” it gets adopted by CTOs, becomes a hiring criteria, and suddenly no one wants to admit it’s crap because their entire career depends on it… or more generously they don’t know any better because they haven’t hit the painful edges in production yet, or they haven’t seen how simple things could be with a different architectural decision.

Something being popular doesn’t mean it’s well-suited for a common use-case. Very often it isn’t.

[panphora]

Author here.

The "paleo influencer" comparison is interesting, but I think it actually works both ways here.

Yes, there's a temptation to romanticize the past and dismiss modern tools. But there's an equally strong tendency to assume that newer, more popular, and more widely-adopted automatically means better. React didn't just win on pure technical merit. It has Facebook's marketing muscle behind it, it became a hiring checkbox, and it created a self-reinforcing ecosystem where everyone learns it because everyone uses it.

The article isn't suggesting that a "huge global collective of the world's most talented engineers have been conned." It's asking a much more nuanced question: did all that effort actually move us forward, or did we just move sideways into different complexity?

Look at the two implementations in the article. They do the same thing. They're roughly the same length. After 15 years of React development, countless developer hours, and a massive ecosystem, we're not writing dramatically less code or solving the problem more elegantly. We're just solving it differently, with different tradeoffs.

Sometimes looking backward isn't about being a "retro-idealist," it's about questioning whether we added complexity without proportional benefit. The paleo diet people might be onto something when they point out that we over-engineered our food. Maybe we over-engineered our frameworks too.

[hansonkd]

> They do the same thing. They're roughly the same length

But they arent the same, the backbone code has raw HTML strings. These are opaque for code editors and not type safe. React code is using typed objects to construct the html (if you used typescript like is standard in 2025 for react projects). The backbone app is disconnected in the rendering flow. the space-y-2 selector is ambiguous and causes unnecessary searching. Just in this small example adds a level of indirection that just adds noise to what the component does. With everything setting raw html, what if you wanted the requirements blob to be a seperate component for instance. this is super easy and clean in react because html and custom components are treated the same.

It also cherry picks an extremely narrow use case of a single element on the page of a password element. This hides the realities of mature apps that you then need another parent component to check if the confirm password field matches, submits the form to backend and displays errors, checks if username is taken etc. Your example doesnt show calling another component from inside a component, etc.

Your purposefully slicing it in to a narrow use case and trying to show equivalence where there isn't

This is the equivalent of those "Primitive Technologies" Youtube videos of building a swimming pool out of mud. Yeah sure technically you accomplished some definition of a "swimming pool". Yes, in some lens you can stand back and look at your pool and a inground pool with filtration, etc and say that you accomplished the same. Yes, technically you proved if you want a swimming pool you don't need a bunch of other equipment. But if you are building a swimming pool to last and be usable for the next 10 years, you will find out why modern pools are not a dug out hole filled with muddy water.

[9dev]

> […] the backbone code has raw HTML strings. These are opaque for code editors and not type safe.

Try using a proper IDE, then, which can handle embedded HTML just fine.

[nchmy]

Just wait til you discover hypermedia, the actual language of the web...

[jitl]

Did you work on any big backbone apps professionally? We had a huge one at Airbnb where after a certain scale any change by anyone - from new grad to expert - could get stuck in 2 days of debugging pure incidental complexity. Change some ui dom structure? Oops you broke someone’s selector and their event won’t fire anymore. Send an update at the wrong time? Render loop.

Switching to React for that app (and everything else) was such a godsend. Once React landed in the codebase it spread like wildfire because of how eager everyone was to burn down the old way!

To me the “it succeeded because marketing” rings hollow because my experience at the time was:

- people loved their MVC ideas and “semantic makeup”, putting template in the JS was so WEIRD and ICKY. And no doubt the compile step for JSX still is annoying one-time complexity. Lots of resistance / thinking React was dumb.

- then you hear about someone on another team replacing a small but annoying feature with React and how relieved they are to be out of backbone hell

- you try yourself, it’s a weird new world and you struggle a bit with the new concepts. Hit a few sharp edges.

- after a week and a half you can’t go back.

- after 6 months (almost) everyone on every team wants to rewrite to React. (We had a few front end leads clinging to their Separation of Concerns as though changing class names on a node in backbone wouldn’t break a zillion event handlers)

If definitely became The Way and self reenforcing, but in my mind that happened primarily out of merit.

[8bitbeep]

React (and Tailwind for that matter) are great for hiring and getting hired. The chances of someone screwing it up or being lost in their first week/month when parachute into a project are pretty low.

It has very little to do with the right abstraction or the best technical solution to the problem.

The web has no default design pattern. It’s the Wild West for better and worse.

I made my peace with modern web stack once I understood this.

[hansonkd]

Took the words out of mouth. Every thread about React people come piling in about how overly complex it is.

When people throw around words like "foolishness" to describe tools that millions of professionals use, its hard to take the rest of their comment seriously. It radiates a special blend of arrogance and ignorance.

Whether React is good or bad, there is a reason people use it. Outright dismissing it entirely seems a bit like chestertons fence.

[evantbyrne]

Is it arrogance or is it experience combined with a different perspective? One developer may love React because of the component ecosystem and talent pool, and another developer may dislike it because they're writing custom HTML/CSS anyways and React requires them to write way more JS than their preferred approach. Would I ever choose backbone? No. But many developers may be surprised by how little vanilla JS that it takes to build modern web apps. More than ever the tradeoffs of different frontend stacks need to be evaluated on a project-by-project basis.

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

[ezst]

OTOH we are taking about the web, here. A domain notoriously defined by technical debt, the "when all you have is a hammer" mindset, NIH, and resume-driven development...

[theflyinghorse]

Let's be brutally honest. Big part of choosing tech has to do with the fact that I want to be able to be paid. If react is popular and has some potential for earning me money, then react it is.

[bdangubic]

if you are the one that gets to pick you are already making bank and don’t need to make tech decisions based on that

[iammrpayments]

There is, I think, a sort of innocent arrogance that comes with people who boldly claim that eating McDonald’s is straight up bad or an obvious step down from “real food.”

That’s not to say popularity guarantees quality, that every menu change is progress, or that there’s not plenty to criticise. But I do think authors of articles like this sometimes get a big hit from being subversive by playing into retro-idealist tropes. The nutritional equivalent of paleo influencers.

Such claims would suggest a huge global collective of the world’s most experienced eaters have been conned into fundamentally unhealthy food choices, which is a little amusing.

[michaelcampbell]

The Blub Paradox is real, and you'll see it everywhere.

[nchmy]

So what you're saying is that people should be taking ozempic rather than just getting some self discipline and eating some salad?

[bitbasher]

> ... a sort of innocent arrogance that comes with people who boldly claim that renowned, well-adopted frameworks or technologies are straight up bad or a non-improvement over yesterday’s tech.

There's a sort of innocent ignorance that comes with people who assume well-adopted or renowned frameworks or technologies became renowned due to positive virtues and not due to external factors at the time.

React was Facebook's reaction to Google's Angular, which was a reaction to backbone and others at the time. At that point, it became a company pissing contest for developer mind-share that embroiled developers in hype trends when the companies themselves were not even using those technologies.

Bootcamps began to teach those technologies because of the hype train and then companies began to hire for those skills because it's what every "new" developer was skilled with due to the massive push by bootcamps at that time (mega rise of MOOCs and bootcamps).

I've spoken to countless founders that made tech choices due to "hiring concerns" and "it's what developers want" and "my buddy XYZ is using it" or "we can't use X because that's the old way".

There's certainly a space to discuss these technologies without being "arrogant" and dismissing what the "majority of developers" use. Maybe the majority is wrong.