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

141–150 of 245 posts

Re: React vs. Backbone in 2025

#141

Post by acdha »

robertoandred wrote: post #140
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…

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.

Re: React vs. Backbone in 2025

#143

Post by itqwertz »

dbattaglia wrote: post #27
justbees wrote: post #8

Earlier quoted context omitted.

I totally agree - the example they give doesn't really need react OR backbone. You could just as easily show vanilla js as the 3rd example and wonder why you would ever even need a framework. 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 jun…

> 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 This is exactly my experience with large scale Backbone apps (from 10+ years ago). Even with extras like Marionette it quickly became a complete nightmare to navigate or maintain. Zombie model and view objects leaking memory was almost inescapable. I remember in 2013 I introduc…

Angular v1 was absolutely the game-changer for sane UI patterns. Although it could choke on large datasets and models were iffy, it allowed us to worry less about the framework and more about the work at hand.

Re: React vs. Backbone in 2025

#144

Post by smrtinsert »

> For massive apps with 1,000 components on the same page, maybe React's complexity is justified.

Something is wrong if you need a 1000 components. Not everything has to be exposed as a component. Build something in lower level library and expose it as a react component. There's a real reason something like ag-grid has such a dedicated following.

The reality is Reacts abstraction has always been thin, which begs the question is it truly valuable. It's basically an application pattern masquerading as an abstraction. In 2025, there's no reason any thoughtful organization shouldn't investigate alternatives.

Re: React vs. Backbone in 2025

#145

Post by smrtinsert »

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.

Re: React vs. Backbone in 2025

#146

Post by iammrpayments »

ZvG_Bonjwa wrote: post #58

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…

There is, I think, a sort of innocent arrogance that comes with people who boldly claim that eating McDonald’s is straight up bad or an obvious step down from “real food.”

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.

Re: React vs. Backbone in 2025

#147

Post by jitl »

aatd86 wrote: post #69
amelius wrote: post #38

Earlier quoted context omitted.

1,000 components is my standard test for trying out a new UI library. I recently tried it with Kotlin/Compose. Turned out that everything becomes noticeably slower with so many components, even if the components are in a scroll view and only a few of them are visible.

Displaying so many would require virtualization. No one is going to see a myriad of components all at once anyway. The slowing down part might be eager computations in partially optimized implementations. The same way we use pagination on the web, or lazy loading, etc... But I guess the question is whether that should be a default...

1000 component should be trivial for a framework in 2025 without virtualization.

Re: React vs. Backbone in 2025

#148

Post by mattnewton »

Yeah no, we didn’t invent things like react to write a password input, we did because as soon as you have more than one event trying to edit one part of the page you’re in hell with backbone. So you add marionette, and a store object, and then there is magic bindings with performance problems or thrashing, and you debug that, and then you… That’s how we got here. This example is about 1/4th the minimum size needed to study the issue. You don't need hundreds of components, you need a single piece of state that is updated three ways to start seeing the pain.

Re: React vs. Backbone in 2025

#149

Post by hansonkd »

panphora wrote: post #127
ZvG_Bonjwa wrote: post #58

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

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

Re: React vs. Backbone in 2025

#150

Post by diegof79 »

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.

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.

Post reply on HN