Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React vs. Backbone in 2025

backbonenotbad.hyperclay.com

Post reply on HN
Print view View original

161–170 of 245 posts

Re: React vs. Backbone in 2025

#161

Post by vacuity »

austin-cheney wrote: post #56
picardo wrote: 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…

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…

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.

Re: React vs. Backbone in 2025

#162

Post by tefkah »

panphora wrote: post #129
Jcampuzano2 wrote: post #63

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

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

Re: React vs. Backbone in 2025

#163

Post by ironmagma »

smrtinsert wrote: post #145
diegof79 wrote: post #134

I worked with Backbone, Angular 1, Ember, and then React. The article overlooks the problems that made React popular: - Composition: Composing components is easier and more efficient in React. Backbone’s render function assumes "this.$el" is mounted and available in the DOM. That makes composition difficult: you cannot simply nest one component inside another without managing the DOM lifecycle of subcomponents. You d…

There's a world of options away from React today that have those features. We can't pretend only React has them.

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

Re: React vs. Backbone in 2025

#164

Post by echelon »

ysavir wrote: post #154
diegof79 wrote: post #134

I worked with Backbone, Angular 1, Ember, and then React. The article overlooks the problems that made React popular: - Composition: Composing components is easier and more efficient in React. Backbone’s render function assumes "this.$el" is mounted and available in the DOM. That makes composition difficult: you cannot simply nest one component inside another without managing the DOM lifecycle of subcomponents. You d…

That's all true, but I think the article's point still stands: React trades one set of compromises for another, and regardless of the tool used, software engineers using that tool have to do a lot of lifting to get the tool to work. It's not a question of whether react is better than backbone or vise versa, it's a question of whether we software engineers, as a group, are emphasizing the correct compromises, and what…

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.

Re: React vs. Backbone in 2025

#165

Post by robertoandred »

acdha wrote: post #141
robertoandred wrote: post #140

Earlier quoted context omitted.

Also can we stop pretending React is any more "complex" than any other rendering library. You can't get much simpler than () => Hello, World

What makes React complex is that your simple example pulls in 100KB of code and entire layers like the virtual DOM which increase the memory and CPU requirements while adding significant new concepts a developer has to learn to be productive. That’s not to say that there aren’t benefits from that but it’s definitely extra complexity compared to using web standards.

A single picture is going to be more than 100kb.

Meanwhile, there simply aren’t web standards that match React’s capabilities.

Re: React vs. Backbone in 2025

#166

Post by krona »

tefkah wrote: post #155

> These aren't edge cases. They're normal problems you hit building moderately complex apps These aren’t real articles. They’re slopg diatribes generated by people who can’t even be bothered to communicate a thought. I feel annoying for being this guy, but i think someone should point out the fact that it’s barely written by a human being. What’s the point in engaging with the point the “author” is trying to make whe…

I can't help but notice your comment doesn't actually say anything of substance, either.

Re: React vs. Backbone in 2025

#168

Post by CaptainOfCoit »

campbel wrote: post #111
picardo wrote: 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…

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.

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.

Re: React vs. Backbone in 2025

#169

Post by flufluflufluffy »

azangru wrote: post #40
picardo wrote: 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…

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

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.

Re: React vs. Backbone in 2025

#170

Post by austin-cheney »

vacuity wrote: post #161
austin-cheney wrote: post #56

Earlier quoted context omitted.

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…

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…

You are mixing your terms. Complexity is another word for many. As such it is measurable objectively. The opposite, simplicity, means fewer.

Readability is highly subjective. At this point you are talking about what is easier for you. Easiness is not simplicity. Simplicity, in almost all cases, requires addition effort and that is not easy.

Post reply on HN