React Vs. Backbone in 2025

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.

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)

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.

Seems more like personal preference.

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.

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.

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.

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

One might argue that it is Google Translate that messes up the DOM for 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.

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.

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?

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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?"