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

21–30 of 245 posts

Re: React vs. Backbone in 2025

#21

Post by rs186 »

preommr wrote: 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…

Yeah. I don't follow react closely, but I do know Vue.js is still in very active development and releasing new features because of all the real use cases/bug fixes. Some of the use cases or issues didn't exist back in 2010 (e.g. interoperability with custom elements). "Look at how little progress we've made" only reveals author's ignorance instead of saying anything meaningful or true.

Put it another way -- you can find those "minimal JS frameworks" and create this same demo easily, but it doesn't mean the other JS framework is all that one needs.

Re: React vs. Backbone in 2025

#23

Post by gravity13 »

thedelanyo wrote: post #12
timcobb wrote: 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…

Does React have built-in state management?

Yes. `useState` is essentially the "two way binding" of React at the component level. You may also enforce two way binding via an external state manager, and pass it to your React components via props.

This is the beauty of React, it's reactive style, that essentially means your UI is always bound to your state.

In Backbone, you do not get this for free, as the problem is that two-way binding in Backbone requires manual re-renders (via jQuery) which are direct DOM manipulations. This is expensive, meaning, it is not performant as your DOM grows.

React solves the problem via it's virtual DOM, which keeps an optimized DOM engine in memory, batching expensive updates onto the real DOM.

This means you get the convenience of your UI always representing your state, which means your code can become more declarative (what you want), and less imperative (what you need to do in order to get it). The author calls this "magic," but as somebody who was a Backbone main turned React main, I call this "sanity."

Re: React vs. Backbone in 2025

#24

Post by BoredPositron »

lelandfe wrote: 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)

Deleting the whole word is not the correct undo...

Re: React vs. Backbone in 2025

#25

Post by gravity13 »

tuhgdetzhh wrote: post #15

I don’t think this comparison is correct. You concluded that not much has changed in 15 years, but you are not comparing 15-year-old idiomatic Backbone code with modern React. Instead, you are comparing modern Backbone code with modern React. You could make a similar comparison between Kotlin and Java and reach the same conclusion. However, Java has evolved significantly over the past 15 years, and most of Kotlin’s f…

This is how Backbone looked back in the day. Not that I agree with him, but there's nothing new to this, it's essentially a basic View wrapper around a jQuery dom manipulator.

Re: React vs. Backbone in 2025

#26

Post by mexicocitinluez »

justbees wrote: post #8
mexicocitinluez wrote: post #2

Components don't live in a vacuum. Which is why comparing one-offs like this make little practical sense in the long run.

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…

Well said and I totally agree.

Re: React vs. Backbone in 2025

#27

Post by dbattaglia »

justbees wrote: post #8
mexicocitinluez wrote: post #2

Components don't live in a vacuum. Which is why comparing one-offs like this make little practical sense in the long run.

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 introduced Backbone to my current company, hoping to make sense out of our existing jQuery + ASP.Net MVC application. After ~3 months of code from junior and mid level developers (in house and off shore) I began to deeply regret my decision. There was just not enough patterns and utilities in the framework to keep things from going off the rails. We eventually shifted to Angular v1 and it was glorious, things just worked and even the ceremony I needed to add felt worth the trouble for the speed of development we gained.

Re: React vs. Backbone in 2025

#28

Post by picardo »

> 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 frustration I had debugging a UI because it was freezing due to cascading state changes. That was because we were using Backbone Store, which had bidirectional data flow, and when one updated the store, it would trigger a change to the UI, which would change the state store, which would change the UI, etc.

You could argue that the real innovation of React was "unidirectional data flow," but React team made Flux architecture central to the framework, making it easier to adopt good practices, whereas Backbone remained store agnostic and even encouraged Backbone Store which used the observer pattern for many years. I think you should choose a framework that allows you to fall into the Pit of Success, and React was that framework at the time, and for my money, it still is.

Re: React vs. Backbone in 2025

#29

Post by nu11ptr »

You are ALWAYS programming in abstractions. The raw JS code is JIT'd into machine code, for example, which most wouldn't know how to read/debug. The JS functions called are built in the browser and are trusted to function properly.

That isn't to say you should accept every abstraction either, but my point is that we all use abstractions where we don't necessarily understand the non-abstracted form. The key metrics therefore are:

1) ensure the abstraction gives you coding velocity benefit commensurate to the complexity of the abstraction

2) be very sure the abstraction provider is trusted enough to ALWAYS generate valid code in non-abstracted form

3) ideally, have some level of capability to debug the abstraction/generated code (in the worst case - per #2 that should rarely be necessary)

Re: React vs. Backbone in 2025

#30

Post by VladVladikoff »

lelandfe wrote: 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.
Post reply on HN