Live data from Hacker News

React vs. Backbone in 2025

backbonenotbad.hyperclay.com

31–40 of 245 posts

Re: React vs. Backbone in 2025

#31
post #13

??? I absolutely failed to follow the logic of this article - is there any? The toy examples having the same amount of code is meaningless. They're saying it's bad because react is more complicated. But this works in react's favor that simple examples are simple. It's also meaningless because it's a toy example. Even if the react code was half the size of the backbone, you could still use the strawman of "react's com…

> "react's complexity isn't worth saving 5 lines of code" which people would agree with.

If you look at the code the example shows, the replication is a bunch of HTML and tailwind CSS classes in backbone. So basically if you decide you want to change the input to have a different radius in one place, you need to implicitly know that there's another piece of code patching and replacing that elsewhere, which has duplicated the code.

I'm not one to pray to the alter of DRY like it's the end-all be-all of programming principles, but you take this pattern and repeat it throughout a production codebase and you have a bunch of repetitions that need to happen.

This is the problem with Backbone - it's edits are imperative - meaning, each one is a source of errors. React makes state updates declarative, so you only need write the rules just once. Somebody coming along to edit the code doesn't need to find the implicit relationships in the imperative code that might break or cause inconsistency, because they don't need to exist anymore.

React is safer. It's not even a contest.

Re: React vs. Backbone in 2025

#32
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…

> For massive apps with 1,000 components on the same page

If have a 40X25 table on your page that's editable, that's your 1,000 components right there. But away from tables, it does seem overkill to have 1,000+ components on a single page.

Re: React vs. Backbone in 2025

#33
post #9

Try typing a full word into each password box. Then, try to undo (Cmd/Ctrl-Z, etc). Backbone's undoes the typing, one letter at a time. React's behaves correctly and undoes the whole word. Good job, React (I still see "controlled" inputs on the web today falling prey to the former)

Why is overriding native browser behaviour “better”? I don’t get this line of thinking at all. It’s like those js libraries that hijack scrolling behaviour only to make it more clunky and less responsive than native scrolling.

[deleted]

Re: React vs. Backbone in 2025

#34
post #9

Try typing a full word into each password box. Then, try to undo (Cmd/Ctrl-Z, etc). Backbone's undoes the typing, one letter at a time. React's behaves correctly and undoes the whole word. Good job, React (I still see "controlled" inputs on the web today falling prey to the former)

wait, why is undoing by word better? I like backbone's approach!

https://jsfiddle.net/pn6bzyhk/1/

Native behavior for comparison. React is following it; Backbone is not. The native behavior on macOS, for instance, undoes all three words in one action: https://imgur.com/a/jKl5exU

(Not your fault: most people misremember this...)

Re: React vs. Backbone in 2025

#35
post #6

I'm ready for all the "what about x" comments, because I'm going to check them all. I'm choosing React over anything else right now because of how well my DevEx has been. I can say the same about Angular, you really need to know how Angular works to know what you're doing. That's the whole issue with these frameworks. At least React doesn't try to abstract too much

And the LLMs are better at React than other frameworks. You need less React devs now than other frameworks. And with greenfield project with the compiler, it seems like an easy path. We don't use React, and I would not choose to do so, but LLMs + Compiler make it a great default for shops starting new apps.

Re: React vs. Backbone in 2025

#36
post #3

I think about React vs Backbone from time to time, too, but have drawn different conclusions. Backbone was one of my first "JS frameworks". I thought it was neat, but when React came out, I thought "oh, something actually useful, unlike Backbone, which is mostly application framework glue code, but doesn't actually do all that much for me. Concrete huge wins for me from React were: - Not having to regularly touch the…

A little nostalgic for me, I wrote a bunch of backbone tutorials back in the day.

https://news.ycombinator.com/item?id=3110025 https://web.archive.org/web/20111015073638/https://backbonet...

Other than the lack of imports, 15 years later I don't hate it.

Due to LLM's my thinking about coding has changed quite a bit, I'm far more interested in what is the best way a language can be written such that LLM's can most effectively write it. JSX/declarative is seemingly solid. I think the React community from useEffect onwards is starting to get a bit wishy washy, probably not a great way for LLM's to "think". (something about expressiveness, explicitness and parse-ability)

Re: React vs. Backbone in 2025

#37
post #9

Try typing a full word into each password box. Then, try to undo (Cmd/Ctrl-Z, etc). Backbone's undoes the typing, one letter at a time. React's behaves correctly and undoes the whole word. Good job, React (I still see "controlled" inputs on the web today falling prey to the former)

Why is overriding native browser behaviour “better”? I don’t get this line of thinking at all. It’s like those js libraries that hijack scrolling behaviour only to make it more clunky and less responsive than native scrolling.

[deleted]

Re: React vs. Backbone in 2025

#38
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…

> For massive apps with 1,000 components on the same page If have a 40X25 table on your page that's editable, that's your 1,000 components right there. But away from tables, it does seem overkill to have 1,000+ components on a single page.

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.

Re: React vs. Backbone in 2025

#39
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…

> For massive apps with 1,000 components on the same page If have a 40X25 table on your page that's editable, that's your 1,000 components right there. But away from tables, it does seem overkill to have 1,000+ components on a single page.

1,000 is a lot, but not uncommon for a CRUD app. Especially when you start with a small one and the scope creeps. Users want one more feature, and one more field. Then it's time to replace some other CRUD app and you've already got this one going ...

Re: React vs. Backbone in 2025

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

Post reply on HN