People don’t or even can’t remember how was front end development before React/Flux/Redux. You could easily had problems with state management even with less than 1000 LOC simple pages. Of course, you could mitigate it, but it wasn’t trivial at all.

Author here.

I appreciate the point about unidirectional data flow solving real problems, but I think we're trading one complexity for another rather than actually simplifying things.

Yes, cascading state changes with Backbone Store were frustrating to debug. But React's abstractions introduce their own set of equally frustrating problems: stale closures where your click handler sees old state, infinite useEffect loops because an object in the dependency array gets recreated every render, mysterious input clearing because a key changed from stable to index-based.

The difference is that Backbone's problems were explicit and visible. When something broke, you could trace the event handlers, see what fired when, and understand the flow. The complexity was in your face, which made it debuggable.

React's problems are hidden behind abstraction layers.

I'm not saying React doesn't solve problems. I'm questioning whether those solutions are appropriate for the 99% of apps that aren't Facebook-scale. Sometimes the explicit, verbose approach is actually easier to reason about in the long run.

I did angular for many years and just recently came back to doing frontend work for a recent project. This is my experience with react, its not perfect and there are a few react-isms to learn, but it tends to make you do the right thing.

> You could argue that the real innovation of React was "unidirectional data flow"

Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up?

> but React team made Flow architecture central to the framework

Didn't they call it Flux rather than Flow?

Components are themselves a form of added complexity. The idea is to deliver a composed and self contained code island. To accomplish this you have a big ball of markup, presentation, event handling, business logic description, and then security and accessibility logic to compensate for the prior mentioned abstractions. What you see in your editor may not look like much, but just under the hood is a colossal mountain of foolishness.

Why do people prefer this? It doesn't increase speed of maintenance. Its preferred because its composable to a predefined architecture scheme the developer is comfortable with. That's it. Its just about comfort, but the complexity is through the roof.

Simple isn't free.

>which had bidirectional data flow, and when one updated the store, it would trigger a change to the UI, which would change the state store, which would change the UI, etc.

You can hit the same problem with React. Circular state updates. State change->trigger useEffect->change state. I hit those when I had just started React.

> For massive apps with 1,000 components on the same page

If have a 40X25 table on your page that's editable, that's your 1,000 components right there. But away from tables, it does seem overkill to have 1,000+ components on a single page.

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.

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.

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.

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.

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.

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.

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

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

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

> The reason I use React for simple things is because I also use React for complex things which require it...

The reason I drive my 18-wheeled semi truck to the local store is because I also drive my 18-wheeled semi truck when hauling cargo across the country, and I don't want to use multiple vehicles.

/s

Fallacies can exist in both directions. "Use the right tool for the job" is good advice.

A little nostalgic for me, I wrote a bunch of backbone tutorials back in the day.

https://news.ycombinator.com/item?id=3110025 https://web.archive.org/web/20111015073638/https://backbonet...

Other than the lack of imports, 15 years later I don't hate it.

Due to LLM's my thinking about coding has changed quite a bit, I'm far more interested in what is the best way a language can be written such that LLM's can most effectively write it. JSX/declarative is seemingly solid. I think the React community from useEffect onwards is starting to get a bit wishy washy, probably not a great way for LLM's to "think". (something about expressiveness, explicitness and parse-ability)

Marionette took away much of the Backbone boilerplate, though.

Does React have built-in state management?

This was downvoted? That’s sad. I tell folks getting started that they should build something without any framework so they can feel the pain that things like React are built to solve. Understanding the fundamentals is important so you can look at something like hooks as cognitive overhead that needs to be accepted

> Lots of people don't even know how JavaScript works despite using it every day.

Imo every React course on the internet should start by having people implement a multi-step form wizard using solely Jquery. You don't appreciate where you are if you forget where you came.

> The main thing to know about Backbone is it’s not intended to be a fully fledged framework like React.

Neither is React. The built-in state management was meant for concerns relevant to only that component, not your entire app's state - people just realized it worked well enough.

Back when React was new, one of the ways to use it in more complex apps was with Backbone as the data store: https://www.npmjs.com/package/react.backbone

People weren't just using this as a migration path, before Rudux became the clear winner of that early React era people would reach for this combination (though possibly not with that specific library, I don't remember the details about using them together).

> At least React doesn't try to abstract too much

What do you mean? The DOM is abstracted away. Hooks are magical, and don't work like regular javascript functions. The scheduler, and the concurrent features are magical. The string pragmas are magical. It is all getting more and more magical, and you need a linter to keep you in line with the magic.

And the LLMs are better at React than other frameworks. You need less React devs now than other frameworks. And with greenfield project with the compiler, it seems like an easy path. We don't use React, and I would not choose to do so, but LLMs + Compiler make it a great default for shops starting new apps.

If doesn't even use a Backbone model, the main thing that framework was known for. IIRC that's even where the name came from - it was designed to be the core of the site's functionality, the models acting as a bridge between the frontend and backend instead of having to make ajax requests and handle responses manually.

Why is overriding native browser behaviour “better”? I don’t get this line of thinking at all. It’s like those js libraries that hijack scrolling behaviour only to make it more clunky and less responsive than native scrolling.

Interestingly, this is the case in Chrome, but in Firefox both React and Backbone exhibit the same behaviour.

wait, why is undoing by word better? I like backbone's approach!

Who says which behavior is the correct one?

Seems more like personal preference.

Deleting the whole word is not the correct undo...

Interesting. Datastar, the front/back end framework, also has the concept of signals, allowing the backend to update them directly via HTTP responses or SSE events.

https://data-star.dev/guide/reactive_signals

Yeah. I don't follow react closely, but I do know Vue.js is still in very active development and releasing new features because of all the real use cases/bug fixes. Some of the use cases or issues didn't exist back in 2010 (e.g. interoperability with custom elements). "Look at how little progress we've made" only reveals author's ignorance instead of saying anything meaningful or true.

Put it another way -- you can find those "minimal JS frameworks" and create this same demo easily, but it doesn't mean the other JS framework is all that one needs.

> "react's complexity isn't worth saving 5 lines of code" which people would agree with.

If you look at the code the example shows, the replication is a bunch of HTML and tailwind CSS classes in backbone. So basically if you decide you want to change the input to have a different radius in one place, you need to implicitly know that there's another piece of code patching and replacing that elsewhere, which has duplicated the code.

I'm not one to pray to the alter of DRY like it's the end-all be-all of programming principles, but you take this pattern and repeat it throughout a production codebase and you have a bunch of repetitions that need to happen.

This is the problem with Backbone - it's edits are imperative - meaning, each one is a source of errors. React makes state updates declarative, so you only need write the rules just once. Somebody coming along to edit the code doesn't need to find the implicit relationships in the imperative code that might break or cause inconsistency, because they don't need to exist anymore.

React is safer. It's not even a contest.

This is how Backbone looked back in the day. Not that I agree with him, but there's nothing new to this, it's essentially a basic View wrapper around a jQuery dom manipulator.

> Does react still mess up the DOM and, for example, using Google Translate?

One might argue that it is Google Translate that messes up the DOM for react :-)

Using something like react-router or TanStack router makes building an entire site a piece of cake.

Author here.

I agree that all frameworks require learning framework-specific concepts, but I think there's a meaningful difference in what you need to know and how that knowledge transfers.

With Backbone, jQuery, or vanilla JavaScript, you're learning DOM APIs, event patterns, and explicit state management. These are things that are visible, inspectable, and fundamentally close to the platform. When something breaks, you can pop open devtools, see the actual DOM, trace the event handlers, and understand what's happening. The knowledge you gain is transferable. It's about how the web platform actually works.

With React, you're learning abstractions on top of abstractions: virtual DOM diffing, reconciliation algorithms, why objects in dependency arrays cause infinite loops, why your click handler sees stale state, why your input mysteriously cleared itself. This is React-specific magic that doesn't transfer. It's knowledge about how to work around React's mental model, not knowledge about how the web works.

You mention that batching and DOM reconciliation are solvable problems that justify React's complexity. But the article's point is that for most apps -- not Facebook-scale apps with 1,000 components on one page, but normal CRUD apps -- those problems can be solved with simpler patterns and conventions. We don't need a virtual DOM and a sophisticated reconciliation algorithm to build a form validator.

The real question isn't "does React solve problems?" It's "does React's complexity match the complexity of the problems most developers are actually solving?"

Web Components are anything but simple, are cumbersome and inconvenient, and have even more footguns than the already footgun-y React.

Even if you only mean "custom elements" instead of "Web Components" (which "custom elements" are part of) they are still absurdly complex for what they do: how is it simple that instead of just having properties you have attributes AND properties, which are completely different things even though you'd expect them to serve the same purpose, and now you're in charge of syncing them!?

I'm trying to get away from the imperative DOM, not create even more quirks and footguns for my consumers!

They're not even meant to replace React. Web Components don't do templating. You can perfectly build Web Components with React since a Web Component is not concerned with rendering at all. If anything they are a replacement for jQuery-based "component"-wrappers (which were already replaced long ago... by React completely changing the frontend paradigm).

And they are client-side only. By design. They don't and will never work with JS disabled. Rendering a custom tag server-side just sends that custom tag over the wire... and there you can only send attributes (which are string-only) so good luck with complex stuff like a huge datatable.

You can tell they were designed by committee because they solve problems from 15 years ago in a worse way than the SotA.

It's great. I wish they released a JS/TS version though.

A custom language that basically depends on a single guy is a hard sell.

I've used Svelte a bit and like it. Not really a suitable replacement for React in most of my work projects yet, though.

I totally agree - the example they give doesn't really need react OR backbone. You could just as easily show vanilla js as the 3rd example and wonder why you would ever even need a framework.

One off it seems fine, but a huge backbone app gets really complicated for me. Show me a huge react app vs a huge backbone app and I will understand the react much more quickly.

"It's verbose, sure, but there's no mystery. A junior developer can trace exactly what happens and when. The mental model is straightforward: "when this happens, do this."

I don't think that's true. A large backbone app has a lot of code that you'll have to trace through multiple files in different directories - the template are here, the functions are there but the endpoints are over there and... maybe it's just the backbone app I have to update but it's much more confusing and abstracted than the react app I also have to update. And don't even get me started with adding a new component. I can drop a new component into the react app and import it anywhere and it's super fast and easy... backbone not so much.