Live data from Hacker News

React vs. Backbone in 2025

backbonenotbad.hyperclay.com

101–110 of 245 posts

Re: React vs. Backbone in 2025

#101
post #57

I was responsible for maintaining a large backbone app over the course of 10 years. The main thing to know about Backbone is it’s not intended to be a fully fledged framework like React. It’s more like jQuery in the sense that it has utility, but in order to use it in a way that is easy to maintain over time, you need build your own layer of abstraction on top of Backbone to make things work the way you want. React h…

> The main thing to know about Backbone is it’s not intended to be a fully fledged framework like React.

Neither is React. The built-in state management was meant for concerns relevant to only that component, not your entire app's state - people just realized it worked well enough.

Back when React was new, one of the ways to use it in more complex apps was with Backbone as the data store: https://www.npmjs.com/package/react.backbone

People weren't just using this as a migration path, before Rudux became the clear winner of that early React era people would reach for this combination (though possibly not with that specific library, I don't remember the details about using them together).

Re: React vs. Backbone in 2025

#102

There is, I think, a sort of innocent arrogance that comes with people who boldly claim that renowned, well-adopted frameworks or technologies are straight up bad or a non-improvement over yesterday’s tech. That’s not to say popularity guarantees quality, that progress is always positive, or that there’s not plenty to criticise. But I do think authors of articles like this sometimes get a big hit from being subversiv…

OTOH we are taking about the web, here. A domain notoriously defined by technical debt, the "when all you have is a hammer" mindset, NIH, and resume-driven development...

Re: React vs. Backbone in 2025

#103
10 years back, every month there would be a new JS framework, backbone, ember, angular 1, 2, vue etc.

With React, I would argue that UI got standardized. At this point the ecosystem is so active and robust that choosing anything else has to be because you have hit a edge case not solved by react, next etc.,

Re: React vs. Backbone in 2025

#104
> React looks cleaner. It reads better at first glance.

I've struggled to get past this. I don't find it easier to read, and the js and html mixed together is just icky. But I think this is an uncommon opinion, and that surprises me.

Re: React vs. Backbone in 2025

#105
post #4

It feels to me that this specific toy example would be even simpler in vanilla JS. A comparison with a serious, large SPA would be more fair and more informative for comparing frameworks.

If doesn't even use a Backbone model, the main thing that framework was known for. IIRC that's even where the name came from - it was designed to be the core of the site's functionality, the models acting as a bridge between the frontend and backend instead of having to make ajax requests and handle responses manually.

Re: React vs. Backbone in 2025

#106

There is, I think, a sort of innocent arrogance that comes with people who boldly claim that renowned, well-adopted frameworks or technologies are straight up bad or a non-improvement over yesterday’s tech. That’s not to say popularity guarantees quality, that progress is always positive, or that there’s not plenty to criticise. But I do think authors of articles like this sometimes get a big hit from being subversiv…

Is it arrogance or is it experience combined with a different perspective? One developer may love React because of the component ecosystem and talent pool, and another developer may dislike it because they're writing custom HTML/CSS anyways and React requires them to write way more JS than their preferred approach. Would I ever choose backbone? No. But many developers may be surprised by how little vanilla JS that it takes to build modern web apps. More than ever the tradeoffs of different frontend stacks need to be evaluated on a project-by-project basis.

Re: React vs. Backbone in 2025

#107
post #46
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)

Who says which behavior is the correct one? Seems more like personal preference.

The one that acts the same as the rest of the system. React isn't replacing the input element, so you get native behavior by default.

Re: React vs. Backbone in 2025

#108
post #99
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…

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.

I remember watching one of the first React demonstrations/talks, and the biggest selling point was literally "You have a web page with various elements, and some of them needs to keep in sync, at Facebook we have chat messages and notifications, and they need to be in sync regardless of where you are, even on the same page, how do you solve that?" and then outlined how having one place for the state to live solves that issue without resorting to two-way data-bindings, instead data only flows in one direction.

Not sure if React isn't being presented as such anymore, but that's still the problem I see React solving, not more, not less.

Re: React vs. Backbone in 2025

#109
post #66
post #50

Earlier quoted context omitted.

> Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up? That's right, but this communication pattern causes serious complexity. Imagine trying to find out what triggered a state change. You would have to listen to every event source to find out. With Flux, all state changes were mediated by the reducer in the store. It made things a lot simpler.

Shouldn't a state change should be purely event driven, and not dispatch its own events as side effect? That avoids reetrancy and is an easy rule to adopt...? Or am I misunderstanding the issue?

You're right about that, but that wasn't common practice at the time. We learned about side-effects from Elm and Flux.

Re: React vs. Backbone in 2025

#110
I've come to the opinion that for the vast majority of apps I've built, it could all be built using HTML + CSS (all built server side). I can sprinkle in little bits of interactivity using something like HTMX. And I'll have a website that is very easy to optimise, has phenomenal backwards compatibility, and gets rid of a whole class of issues associated with SPAs.

I often regret in my career not pushing back more on "requirements" that ended up requiring a more complicated app, whereas the customer would have been happier with a simpler solution.

Post reply on HN