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

191–200 of 245 posts

Re: React vs. Backbone in 2025

#191

Post by qudat »

echelon wrote: post #164
ysavir wrote: post #154

Earlier quoted context omitted.

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.

Agreed. You want to run htmx at a company where the business requirements change every month? Good luck but you’re going to end up rewriting it and have a much harder time hiring.

Re: React vs. Backbone in 2025

#192

Post by Muromec »

ironmagma wrote: post #163
smrtinsert wrote: post #145

Earlier quoted context omitted.

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.

Vue.js is better react without hooks bullshit and with actual reactivity. Very nice, stable and mature.

Re: React vs. Backbone in 2025

#193

Post by Muromec »

treve wrote: post #118
ruszki wrote: post #99

Earlier quoted context omitted.

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.

Yeah I would argue that it's possible to do it well with Backbone, and you end up with something much leaner but it requires a really strong understanding of state/event flow and lot of discipline, whereas with React the correct way to handle this is the 'obvious' path, which dramatically lowers the barrier to entry.

And now everyone has phantom unreads again because it is cyclical and a different team is in charge of every other div

Re: React vs. Backbone in 2025

#194

Post by smrtinsert »

ironmagma wrote: post #163
smrtinsert wrote: post #145

Earlier quoted context omitted.

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.

Even the jquery version looks better: https://justpaste.it/3pz1n

But to keep in the good graces of our thought leader overlords, let's start solid or svelte.

Re: React vs. Backbone in 2025

#195

Post by smrtinsert »

diegof79 wrote: post #150
smrtinsert wrote: post #145

Earlier quoted context omitted.

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.

The raw jquery version looks better to me: https://justpaste.it/3pz1n

Re: React vs. Backbone in 2025

#196

Post by kelnos »

I've never used Backbone, so I can't speak to its ergonomics, but I've used React (a bit back in 2015, and now again this year I've been updating my knowledge and re-learning it), and absolutely agree with the author's frustrations with its "magic".

I'm working on both a backend (in Rust) and a frontend (Typescript, React). The backend makes sense; the code I write does what I expect it to, and there's no magic. The frontend... oh boy. I constantly run into infinite-loop re-renders, input elements that won't update or randomly lose state, etc. I ask Claude Code to help me fix it, and it ends up doing a bunch of the stuff mentioned in the article: adding useCallback, useMemo, tweaking dependency lists, restructuring things in useEffect, adding state variables, etc.

Fortunately I can read the changes and understand what Claude is doing and why, but all of these things feel like huge holes in the abstraction. They're arcane workarounds for problems that React itself creates. And despite learning via Claude's fixes, I still keep making similar mistakes, a phenomenon I've never encountered with any other framework or library I've ever used before.

Having said that, I'll keep using React: it has a huge community around it, answers to problems aren't hard to find, and Claude Code seems to be good at working with it when I screw up and can't be arsed to poke at it until it works. This unfortunately feels a lot like the old saying, "nobody gets fired for buying IBM", but... it is what it is.

Re: React vs. Backbone in 2025

#197

Post by uvaursi »

I moved our team from Backbone to Angular almost 6 years ago. I treasured BB on the fact that the entire source code can be read and understood by a junior developer, which made it appealing to me from an adoption perspective in our org, because there was no “magic” to it and a developer inherently understands and accepts that BB solves a real problem in a direct way. Having an army of jQuery devs who still wrote their own XmlHttpRequest functions and handled the inverted IE event bubbling by hand, I needed to ease them into thinking about front-ends as applications.

But my sensibilities as a software developer led me to adopt TypeScript and a kitchen-sink framework as a more stringent way of composing pages rather than just having a Wild West of filling patterns around what BB didn’t offer out of the box. After doing side-by-side comparisons Angular seemed like the most “similar” to what BB looks like day-to-day. I don’t have anything against React/Vue they’re fine.

We are on NG20 now and it’s looking good. I don’t miss BB, we still have some old pages that use it but overall I am not going to get caught up on this code golf stuff. Eventually when browsers catch up and offer out of the box solutions maybe that will be a point where we can go back to implementing things in a simple more native way.

Re: React vs. Backbone in 2025

#198

Post by ppqqrr »

most web pages are about to be HTML/JS/CSS generated by LLMs directly for users. Truth is, pre-LLM web frameworks were designed for two things: save developer keystrokes and delay the spaghettification of the codebase. We just automated keystrokes, so that's largely irrelevant now. Users don't read code, so spaghettification is also a non-issue, as long as the framework defines clear containers for spaghettis, and provide clear ways to fork the spaghetti or start over when the user is frustrated with some bug. There's no framework designed with these requirements in mind, but I am working on one.

Re: React vs. Backbone in 2025

#199

Post by jitl »

amelius wrote: post #179
aatd86 wrote: post #171

Earlier quoted context omitted.

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

#200

Post by throwawayffffas »

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 point would me much better served if the article compared react from 2014 to react today.

As others have noted working with react after having worked with backbone, jQuery and ember felt like a breath of fresh air.

It felt that was we were doing was same again, and I would argue understandable. 11ish years later cruft has pilled own to dev experience detriment.

Post reply on HN