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

51–60 of 245 posts

Re: React vs. Backbone in 2025

#51

Post by stevepotter »

hamandcheese wrote: post #14

I love React, but the author does make some good points. React does have a lot of footguns, especially if you don't have a very solid grasp of how it works (or at least a solid mental model). A big part of the problem happens well before React though. Lots of people don't even know how JavaScript works despite using it every day. So it's no wonder that people get tripped up trying to understand functional components,…

This was downvoted? That’s sad. I tell folks getting started that they should build something without any framework so they can feel the pain that things like React are built to solve. Understanding the fundamentals is important so you can look at something like hooks as cognitive overhead that needs to be accepted

Re: React vs. Backbone in 2025

#52

Post by kaoD »

VladVladikoff wrote: post #30
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.

OP's point is that respecting native behavior (React) is better.

Re: React vs. Backbone in 2025

#53

Post by cluckindan »

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…

Marionette took away much of the Backbone boilerplate, though.

Re: React vs. Backbone in 2025

#54

Post by warpspin »

lelandfe wrote: post #34
saxenaabhi wrote: post #19

Earlier quoted context omitted.

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...)

Well played. Have been using Mac OS for 20 years and I did not expect this result, if asked.

This is why you should always be wary about re-implementing OS behaviour yourself in your widgets, you will always miss at least one detail, but more probably dozens of them.

Re: React vs. Backbone in 2025

#55

Post by kaoD »

dlisboa wrote: post #22

Something so simple such as this doesn’t even need a library, you can just use Web Components. Simple components are not why people use React.

Web Components are anything but simple, are cumbersome and inconvenient, and have even more footguns than the already footgun-y React.

Even if you only mean "custom elements" instead of "Web Components" (which "custom elements" are part of) they are still absurdly complex for what they do: how is it simple that instead of just having properties you have attributes AND properties, which are completely different things even though you'd expect them to serve the same purpose, and now you're in charge of syncing them!?

I'm trying to get away from the imperative DOM, not create even more quirks and footguns for my consumers!

They're not even meant to replace React. Web Components don't do templating. You can perfectly build Web Components with React since a Web Component is not concerned with rendering at all. If anything they are a replacement for jQuery-based "component"-wrappers (which were already replaced long ago... by React completely changing the frontend paradigm).

And they are client-side only. By design. They don't and will never work with JS disabled. Rendering a custom tag server-side just sends that custom tag over the wire... and there you can only send attributes (which are string-only) so good luck with complex stuff like a huge datatable.

You can tell they were designed by committee because they solve problems from 15 years ago in a worse way than the SotA.

Re: React vs. Backbone in 2025

#56

Post by austin-cheney »

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

Components are themselves a form of added complexity. The idea is to deliver a composed and self contained code island. To accomplish this you have a big ball of markup, presentation, event handling, business logic description, and then security and accessibility logic to compensate for the prior mentioned abstractions. What you see in your editor may not look like much, but just under the hood is a colossal mountain of foolishness.

Why do people prefer this? It doesn't increase speed of maintenance. Its preferred because its composable to a predefined architecture scheme the developer is comfortable with. That's it. Its just about comfort, but the complexity is through the roof.

Simple isn't free.

Re: React vs. Backbone in 2025

#57

Post by cj »

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 has a lot more of that built-in, and the downside is React is more opinionated with a “right” way to do things, while Backbone leaves a lot up for the developer to decide how to do. I guess this could be a benefit of react depending on how you look at it, or whether you want an opinionated framework.

All that said, I will always love Backbone for being the only open source framework that has source code that is actually possible to fully read and fully understand in a few hours in an afternoon.

The source code is surprisingly simple and easy to understand. There’s very little magic going on behind the scenes.

Re: React vs. Backbone in 2025

#58

Post by ZvG_Bonjwa »

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 subversive by playing into retro-idealist tropes. The engineering equivalent of paleo influencers.

Such proposals would suggest a huge global collective of the world’s most talented engineers have been conned into fundamentally bad tech, which is a little amusing.

Re: React vs. Backbone in 2025

#59

Post by cindyllm »

austin-cheney wrote: post #56
picardo wrote: 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…

Components are themselves a form of added complexity. The idea is to deliver a composed and self contained code island. To accomplish this you have a big ball of markup, presentation, event handling, business logic description, and then security and accessibility logic to compensate for the prior mentioned abstractions. What you see in your editor may not look like much, but just under the hood is a colossal mountain…

[dead]
Post reply on HN