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

171–180 of 245 posts

Re: React vs. Backbone in 2025

#171

Post by aatd86 »

jitl wrote: post #147
aatd86 wrote: post #69

Earlier quoted context omitted.

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.

Hmmh...

Warning: Lighthouse issues a warning when the page's element has more than ~800 nodes (elements).

Error: Lighthouse reports an error when the element has more than ~1,400 nodes.

Other Related Lighthouse Warnings Lighthouse also flags two other related issues, which often contribute to a large DOM:

Maximum DOM Depth: It warns if your DOM tree has a nesting depth greater than 32 levels.

Maximum Child Elements: It warns if any single parent element has more than 60 direct children.

The general recommendation for optimal performance is to keep your page's total DOM node count below 1,500.

source: https://web.dev/articles/dom-size-and-interactivity

These are "NODES", not even components as you say...

Re: React vs. Backbone in 2025

#172

Post by 9dev »

hansonkd wrote: post #149
panphora wrote: post #127

Earlier quoted context omitted.

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

> […] the backbone code has raw HTML strings. These are opaque for code editors and not type safe.

Try using a proper IDE, then, which can handle embedded HTML just fine.

Re: React vs. Backbone in 2025

#174

Post by paulddraper »

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?

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.

Re: React vs. Backbone in 2025

#175

Post by 9dev »

afavour wrote: post #68
rkomorn wrote: post #64

Earlier quoted context omitted.

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

IMO, yes. There are a lot of people out there with underpowered devices or slow internet connections (including me when I’m on the subway!) and modern web dev practices that output MBs of JS for simple things are a terrible experience. Just not one experienced by the developers on super fast computers and wired internet connections. Try browsing the web with Chrome’s network throttling and CPU throttling enabled. It…

If you're using my web app (I wouldn't have used React if it wasn't an application anyway, right?), you're very likely a returning visitor. Even if your first page load after signin in is a drag because you're on the subway and for some reason 100KB take five seconds—you're probably coming back anyway, because my app warrants recurring usage (and the industry heavily optimises towards that, but that's a different story).

So on the second visit, you'll have my vendor bundle cached anyway, the app loads instantly, and you will never even remember how long the first load took.

Given that—tell me again why I should care to convince my boss we need to put considerable investment into an alternative technology with a bunch of dragons lurking about, that may or may not be abandoned in a few years and bite us later on, which might introduce compatibility issues with new libraries, which existing staff and new hires must be trained to account for?

Why would I opt for a world of potential pain, just to make your first page load under bad (thus: rare) conditions slightly better?

Re: React vs. Backbone in 2025

#178

Post by [deleted] »

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.

[deleted]

Re: React vs. Backbone in 2025

#179

Post by amelius »

aatd86 wrote: post #171
jitl wrote: post #147

Earlier quoted context omitted.

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

Hmmh... Warning: Lighthouse issues a warning when the page's element has more than ~800 nodes (elements). Error: Lighthouse reports an error when the element has more than ~1,400 nodes. Other Related Lighthouse Warnings Lighthouse also flags two other related issues, which often contribute to a large DOM: Maximum DOM Depth: It warns if your DOM tree has a nesting depth greater than 32 levels. Maximum Child Elements:…

That's because a webpage should render properly on __all__ browsers.

You don't have this problem with UI libraries because all users will run the same library.

Re: React vs. Backbone in 2025

#180

Post by cloverich »

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…

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.

Post reply on HN