Live data from Hacker News

React vs. Backbone in 2025

backbonenotbad.hyperclay.com

121–130 of 245 posts

Re: React vs. Backbone in 2025

#121
post #93

Earlier quoted context omitted.

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

I have had other people tell me this because they perceived state management as a challenging problem to solve. That is true of the big frameworks, but otherwise state management is a ridiculously straightforward problem easily solved.

React came to be because folks at Facabook couldn't get the label displaying unread notifications always to display correct value. This seems like ridiculously straightforward problem easily solved. Yet still many websites and applications today struggle with that.

Re: React vs. Backbone in 2025

#124
post #99
post #28

> For massive apps with 1,000 components on the same page, maybe React's complexity is justified. But what the other 99% of apps? The number of components is not the only yardstick of complexity. Most of the complexity in building a UI comes from state management and how state changes are propagated across the store and the UI. I worked with Backbone for many years, and I can distinctly recall the hours of frustratio…

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.

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.

Re: React vs. Backbone in 2025

#125

React is enterprise at this point. LOC isn’t the selling point. While i dream of post react world, none of the frameworks meaningfully push the needle. I’m working in angular now & signals make it fine. Everything is fine, nothing is great.

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

Re: React vs. Backbone in 2025

#126
post #28

> For massive apps with 1,000 components on the same page, maybe React's complexity is justified. But what the other 99% of apps? The number of components is not the only yardstick of complexity. Most of the complexity in building a UI comes from state management and how state changes are propagated across the store and the UI. I worked with Backbone for many years, and I can distinctly recall the hours of frustratio…

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.

Re: React vs. Backbone in 2025

#127

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 subversiv…

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.

Re: React vs. Backbone in 2025

#128
In fairness at the local level displayed here just vanilla JS is damn easy to implement. But when you have a larger app with various interactions that can happen at different levels of the tree, the react abstraction will be appreciated. I say this as someone who was around to see how we dealt with this in backbone and then switched to react for dealing with the same

Re: React vs. Backbone in 2025

#129

Its hilarious reading this article and then the code because despite sometimes being a React hater - the React code is entirely more readable and followable. Yes there are good frameworks that I'd argue beat React in multiple facets, but Backbone is not it having written it in the past. - Two way data flow with stores is terrible for predictability - Batching is not built in by default so you get layout thrashing as…

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

Re: React vs. Backbone in 2025

#130
post #18

Earlier quoted context omitted.

Does React have built-in state management?

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 ( Increment age You are {this.state.age}. ); } } Functional component: function Counter() { const [age, setAge] = useState(42); const handleAgeChange = () => setAge(age + 1); return ( Increment age You are {age}. ); }

[deleted]
Post reply on HN