React vs. Backbone in 2025

I definitely do a lot less lifting with React than with jquery or backbone; like OP I also used all three (and others) in production, and my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air. In particular, counter point to the article, i loved that i could do something relatively complex, relatively easily, but still pop open dev tools and understand what was happening. I think tis great new libraries and concepts are sprouting but imo looking back wont help; browser javascript has come a LONG way obviating a large chunk of the reason we were all using jquery in the first place. Basic CRUD does fine with server side rendering, and is easier to test and maintain. Using that until it hurts is a solid strategy for avoiding react if thats ones goals.

The reality is stateful UI is complex on its own. Then JS tooling is complex (byo typescript and std lib). Then UI is something everyone sees so the whole company has opinions about how it should look. Mush it all together and FE development is rough. React is a punching bag because its been dominant so long. Id welcome the next phase when it arrives. But building toy apps with aged technology imo wont bring to light any unturned stones. Id recommend researching the plethora of real code and discussions that have beaten this horse to death on the open internet instead.

Which is the case for every library ever written

The job is to deliver complex software with ever changing requirements with a fungible team of engineers.

I'd say React is doing swimmingly at that job description.

For small, artisanal projects, there are lots of other choices and priorities.

I'm merely reiterating the blog's thesis.

Agree, but the article was about comparing React and Backbone.

There are a gazillion of options that resolve the same problems: Vue, Svelte, Solid, Lit, etc.

Backbone was born as better code organization on top of jQuery and CoffeeScript. It never attempted to solve these issues.

There are essentially infinitely many JS frameworks. You’ll have to recommend one or two to be taken seriously.

Look, I wrote one of the only published books on Backbone, and it will always have a special place in my heart, but ... the OP has no idea what he is talking about.

Backbone employed a two-way data binding flow. You're responsible for updating the models (ie. state) (way #1) when the user triggers events, AND you are responsible for updating the DOM whenever the models (ie. state) changes (way #2).

In React, they used a revolutionary new paradigm (flux), making it so you only worry about one direction (updating the models/state in response to events); you never render anything (React renders everything for you in response to state changes)!

If you've tried developing a non-trivial site with both, it quickly becomes apparent how much that one difference completely simplifies a huge aspect of development.

I remember watching one of the first React demonstrations/talks, and the biggest selling point was literally "You have a web page with various elements, and some of them needs to keep in sync, at Facebook we have chat messages and notifications, and they need to be in sync regardless of where you are, even on the same page, how do you solve that?" and then outlined how having one place for the state to live solves that issue without resorting to two-way data-bindings, instead data only flows in one direction.

Not sure if React isn't being presented as such anymore, but that's still the problem I see React solving, not more, not less.

Yeah I would argue that it's possible to do it well with Backbone, and you end up with something much leaner but it requires a really strong understanding of state/event flow and lot of discipline, whereas with React the correct way to handle this is the 'obvious' path, which dramatically lowers the barrier to entry.

Everything was so hard. Everything! Backbone was kinda fun to write though, I'll admit. But not fun at scale to manage.

You just need 2 components with bidirectional binding to enter a world of hurt.

As you say many people do not understand how important, vital and bizarrely _non-obvious_ uni directional data flow was.

Yes, applying compositional patterns and one-way data flow is most appropriate for all apps, independent of scale. Why? Because developer A (author of app x) leaves company. Developer B gets hired. Developer B is onboarded in an afternoon because things can be understood at a glance thanks to functional patterns and one-way data flow.

Having built many large-scale Backbone apps, anytime someone new came on board it was really very, very difficult, no matter how many design patterns one applied.

React's innovation was making FP mainstream. And then teaching the value of simplicity, as a principle. And yah, if something broke, it might be a little opaque, but at scale and in general, things broke _way less often_.

This is also the reason why most devs are full-stack now. Back in the day backend devs wouldn't dare touch FE code, and now its "not so bad", and pretty much anyone can work all over the stack.

Those problems of react are only react's problems. Other js framework like vue/svelte/solid do not suffer from them.

You can use other frameworks for the other 1% of apps

At one point I also moved from Angular to React, after moving from Backbone to Angular, and from "just" jQuery + jQuery UI to Backbone. After moving to React, I haven't found the need to move to something else, most of the alternatives are marginal improvements, while the difference before and after React is pretty drastic.

The native DOM doesn’t have an idea of “data flow”, it’s just a big tree that you can modify in whatever way you see fit through its imperative API. For example you could add an event handler to a child node which directly modifies one of its ancestor nodes. With React, your “nodes” in the tree are functions. The child node has no idea about what its ancestors are, it only knows what it is passed as arguments (i.e. “props”). The only way implement a similar thing would be to raise the state/event handling code to the ancestor node, and passing relevant information down as props, thus giving the unidirectional data flow. Of course, if you really needed to, you could drop back down to the native DOM API, with React’s useRef and useEffect hooks, but the default behavior is this unidirectional data flow through function composition.

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

That's right, but this communication pattern causes serious complexity. Imagine trying to find out what triggered a state change. You would have to listen to every event source to find out. With Flux, all state changes were mediated by the reducer in the store. It made things a lot simpler.

There is no notion of components in the DOM (or at least there wasn’t, until after React), so there’s no sense of data flow.

There is a DOM tree, but parents don’t pass data into or receive events from children.

> Didn't they call it Flux rather than Flow?

Ah, you may be right. It's been a long time.

Composability is really valuable; you don't get bogged down in interconnectivity when your application gets really big.

You pay for it for smaller stuff, though, since that multiplicative coefficient is high.

From what you're saying, it sounds like components in this framework (React?) are not simple at all. A major hurdle in evolving a program is capturing and maintaining simplicity. The proof of whether something is simple lies in its composability, readability, and so on. If someone claims to have found a method of writing simple components, do not believe them if the simplicity is not evident. A truly simple solution would not be so burdened, and a somewhat simpler solution would be less burdened. Of course, simple still doesn't mean easy, because the Fast Fourier Transform may be simple, but I can't teach it to a 5 year old (or anyone, really).

Never religiously cling to statements such as "strictly separate presentation and content". These are all just guidelines to suggest simpler solutions, not hard rules that guarantee simplicity. They will sometimes be excepted.

There are such things as components, which compose strictly by interfaces and externalize separate details, but it is up to the programmers to realize them in their programs. Also, simplicity is a global property of a system. Nothing can be judged on simplicity in a vacuum.

All that being said, I don't have experience in web or UI in particular. Seems like logic is moreso a local thing, whereas presentation is moreso global (but may consider locally defined advice). State can be local or global.

I’m not sure i could disagree more with a statement.

Reacts innovation is simple: view is a function of state.

Before that we had to construct the ui imperatively where we managed state AND ui transitions to state changes. Now we mostly just focus on rendering a ui based on the snapshot of state we have. It is revolutionary (for ui dev), it is scalable, it is the reason why react STILL dominates the ui landscape.

React isn’t just popular because it’s familiar, that might be a component, but it ignores the historical and technological achievement it created

[dead]

You can, but it's harder, React will at least nudge you away from doing that.

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

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.

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

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.

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

Seems like your example isn't equivalent to op's because using multiple frameworks increases complexity while picking a different car to drive to local store doesn't.

Your comparison doesn't make any sense because React is just fine for small apps. You're yelling at someone over using their car instead of roller skates to get groceries.

They had them from day one.

Class component:

  class Counter extends Component {
    state = { age: 42 };

    handleAgeChange = () => {
      this.setState({ age: this.state.age + 1 });
    };

    render() {
      return (
        <>
          <button onClick={this.handleAgeChange}>Increment age</button>
          <p>You are {this.state.age}.</p>
        </>
      );
    }
  }

  function Counter() {
    const [age, setAge] = useState(42);

    const handleAgeChange = () => setAge(age + 1);

    return (
      <>
        <button onClick={handleAgeChange}>Increment age</button>
        <p>You are {age}.</p>
      </>
    );
  }

Yes. `useState` is essentially the "two way binding" of React at the component level. You may also enforce two way binding via an external state manager, and pass it to your React components via props.

This is the beauty of React, it's reactive style, that essentially means your UI is always bound to your state.

In Backbone, you do not get this for free, as the problem is that two-way binding in Backbone requires manual re-renders (via jQuery) which are direct DOM manipulations. This is expensive, meaning, it is not performant as your DOM grows.

React solves the problem via it's virtual DOM, which keeps an optimized DOM engine in memory, batching expensive updates onto the real DOM.

This means you get the convenience of your UI always representing your state, which means your code can become more declarative (what you want), and less imperative (what you need to do in order to get it). The author calls this "magic," but as somebody who was a Backbone main turned React main, I call this "sanity."

useState is the built-in way to manage state in React today. There were also similar mechanisms in class components before hooks came along. This is pretty integral to how React works.

People do add state managers to store state outside the component tree, but a lot of components don't need that.