React vs. Backbone in 2025 • Hacker News Board

Re: React vs. Backbone in 2025

#201

Post by fny » Sat, Oct 25, 2025, 6:52 PM UTC

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…

The example is also unrepresentative of anything meaningful. TodoMVC[0] is the classic point of comparison, and the Backbone version is a nightmare to grok compared to React[2].

Who wants to maintain this nightmare? https://github.com/tastejs/todomvc/blob/gh-pages/examples/ba...

Devs love to invoke Chesterton's fence but somehow forget about it when looking back on "the good old days."

What's worse, there were never good old days for frontend. It always sucked, and now it still sucks--just far less.

[0]: https://todomvc.com/

[1]: https://github.com/tastejs/todomvc/tree/gh-pages/examples/ba...

[2]: https://github.com/tastejs/todomvc/tree/gh-pages/examples/re...

Re: React vs. Backbone in 2025

#202

Post by laurencerowe » Sat, Oct 25, 2025, 7:02 PM UTC

cloverich wrote: post #180

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…

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

> my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air.

This was exactly how I felt. I building a Backbone app around the time React was released. It was only around 2600 lines of JS at the time but event handling and state management already felt like a tangled mess.

Porting it to React was a huge improvement even at that scale and really paid off over the next 5 years of development.

Re: React vs. Backbone in 2025

#203

Post by pyridines » Sat, Oct 25, 2025, 7:15 PM UTC

ppqqrr wrote: post #198

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

> spaghettification is also a non-issue, as long as the framework defines clear containers for spaghettis

Sorry, but I disagree strongly with this. When there is, inevitably, a bug that the LLM can't fix, someone's going to have to read all that spaghetti, and they'll curse whoever put it there. "clear containers for spaghetti" is a pipe dream, all abstractions leak, and the bug may very well be in the spaghetti. "Just start over" is unrealistic for large, complex apps.

Of course, if you really have a solution for this, that would be incredible.

Re: React vs. Backbone in 2025

#204

Post by scotty79 » Sat, Oct 25, 2025, 7:34 PM UTC

scotty79 wrote: post #121

austin-cheney wrote: post #112

Earlier quoted context omitted.

I have had other people tell me this because they perceived state management as a challenging problem to solve. That is true of the big frameworks, but otherwise state management is a ridiculously straightforward problem easily solved.

React came to be because folks at Facabook couldn't get the label displaying unread notifications always to display correct value. This seems like ridiculously straightforward problem easily solved. Yet still many websites and applications today struggle with that.

I'm getting downvoted into oblivion but you can hear it from horse's mouth:

https://youtu.be/nYkdrAPrdcw?t=757

Re: React vs. Backbone in 2025

#205

Post by afavour » Sat, Oct 25, 2025, 7:51 PM UTC

qudat wrote: post #187

afavour wrote: post #78

I think the broader point being made here isn’t “React is bad” it’s how far we haven’t come in all this time. The user experience on the web is still sorely lacking. To be sure some of it is a result of still missing browser primitives for e.g. performant scroll table views but there have been a lot of developments very few capitalise on. For example: one of the big benefits of apps vs the web is that you download th…

They exist and being developed but the use case is so small when their users have internet. I don’t really understand the argument either: local-first and offline modes are non trivial to get right, it’s not automatic even with a framework. Every product I’ve built is able to make a bunch of assumptions: client is working on behalf of a company, on their desktop computer, with good internet. It’s often even more hete…

> Every product I’ve built is able to make a bunch of assumptions: client is working on behalf of a company, on their desktop computer, with good internet.

That’s your experience, it is not mine. A great many people are making consumer facing web sites that experience majority mobile traffic. It’s not even rare!

Re: React vs. Backbone in 2025

#206

Post by wk_end » Sat, Oct 25, 2025, 7:56 PM UTC

bikeshaving wrote: post #186

The example is a fun one-page TodoMVC alternative. Here’s Crank.js: // Adapted from https://backbonenotbad.hyperclay.com/ // https://gist.github.com/panphora/8f4d620ae92e8b28dcb4f20152185749 function* PasswordStrength() { const requirements = [ {label: '8+ characters', check: (pwd) => pwd.length >= 8}, {label: '12+ characters', check: (pwd) => pwd.length >= 12}, {label: 'Lowercase letter', check: (pwd) => /[a-z]/.tes…

What's "for ({} of this)" about?

Re: React vs. Backbone in 2025

#207

Post by vacuity » Sat, Oct 25, 2025, 8:16 PM UTC

austin-cheney wrote: post #170

vacuity wrote: post #161

Earlier quoted context omitted.

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.

I did say that simple doesn't mean easy. I don't know how to judge whether something is many or few without a fixed norm, nor how to measure it without reference to the environment it exists within. Simplicity does not mean having so little to the point of unease.

"Everything should be as simple as possible, but not simpler"

- Einstein (probably[0])

Brainfuck is a simple language. A Brainfuck program written to parity with an existing non-Brainfuck program is likely complex. A musical note is simple, but a musical score may be highly complex.

I think your objections are misplaced.

[0] https://quoteinvestigator.com/2011/05/13/einstein-simple/

Re: React vs. Backbone in 2025

#208

Post by azemetre » Sat, Oct 25, 2025, 10:13 PM UTC

robertoandred wrote: post #165

acdha wrote: post #141

Earlier quoted context omitted.

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.

Pictures get encoded and decoded by browsers much much faster than the ability to parse then execute javascript.

Re: React vs. Backbone in 2025

#209

Post by bikeshaving » Sat, Oct 25, 2025, 11:42 PM UTC

wk_end wrote: post #206

bikeshaving wrote: post #186

The example is a fun one-page TodoMVC alternative. Here’s Crank.js: // Adapted from https://backbonenotbad.hyperclay.com/ // https://gist.github.com/panphora/8f4d620ae92e8b28dcb4f20152185749 function* PasswordStrength() { const requirements = [ {label: '8+ characters', check: (pwd) => pwd.length >= 8}, {label: '12+ characters', check: (pwd) => pwd.length >= 12}, {label: 'Lowercase letter', check: (pwd) => /[a-z]/.tes…

What's "for ({} of this)" about?

Crank.js uses generator functions for stateful components, where you yield instead of returning, and the scope is preserved for the lifetime of the component. You could technically use `while (true)`, but `for (props of this)` is the idiomatic way to get new props. The `this` object is an iterable of the latest props, and if the component doesn’t have props, `for ({} of this)` is the idiomatic way to loop over props without needing another variable assignment.

Re: React vs. Backbone in 2025

#210

Post by ricardobeat » Sat, Oct 25, 2025, 11:44 PM UTC

fny wrote: post #201

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…

The example is also unrepresentative of anything meaningful. TodoMVC[0] is the classic point of comparison, and the Backbone version is a nightmare to grok compared to React[2]. Who wants to maintain this nightmare? https://github.com/tastejs/todomvc/blob/gh-pages/examples/ba... Devs love to invoke Chesterton's fence but somehow forget about it when looking back on "the good old days." What's worse, there were never…

What you see as a nightmare is really straight-forward code from another perspective. It just looks very unfamiliar. Yes, it feels raw, it is verbose, it's imperative and not declarative, but the entire app lifecycle is there to see.

You can easily tell what every function is doing, including the library ones, and magical behaviour is kept to a minimum. It could be easily maintained 20 years from now, as you have a very thin layer over DOM manipulation and Backbone itself can be grasped and maintained by a single human.

One could argue that React leads to better development velocity, but from experience I can say that reality is not that simple. The initial speed boost quickly fades, instead a huge amount of time starts being allotted to maintenance, updates, workarounds, architecture and tooling as complexity compounds.