Comment by Jcampuzano2 | Hacker News Reader

Comment by Jcampuzano2 | Hacker News Reader

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 your app scales unless you're very careful

- You can easily blow away entire DOM trees if you aren't careful since it does not do any sort of reconciling differences.

- And more.

And the argument about needing to know stuff about the framework is entirely worthless. There are frameworks all over every single programming language ecosystem and ALL of them come with something you have to know about the framework itself, thats the tradeoff you make by picking a framework at all. Can we stop using this as an argument that there is magic or not? Yes React does tend to have a bit more in certain areas but they things they mentioned aren't even close to the worst offendors and have legitimate use cases.

The number of quality of life improvements, performance considerations, warning/DX improvements, etc. Its just not comparable for a small toy example.

Go build a full app with Backbone and React and tell me React wasn't miles easier to reason about and continue adding features.

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

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

Kind of disrespectful to reply to valid criticism of your AI slop article with more AI slop. Write like a human being man, what’s the point?

Reply on news.ycombinator.com