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

111–120 of 245 posts

Re: React vs. Backbone in 2025

#111

Post by campbel »

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…

I did angular for many years and just recently came back to doing frontend work for a recent project. This is my experience with react, its not perfect and there are a few react-isms to learn, but it tends to make you do the right thing.

Re: React vs. Backbone in 2025

#112

Post by austin-cheney »

qudat wrote: post #93
austin-cheney wrote: post #56

Earlier quoted context omitted.

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…

I’m not sure i could disagree more with a statement. Reacts innovation is simple: view is a function of state. Before that we had to construct the ui imperatively where we managed state AND ui transitions to state changes. Now we mostly just focus on rendering a ui based on the snapshot of state we have. It is revolutionary (for ui dev), it is scalable, it is the reason why react STILL dominates the ui landscape. Rea…

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.

Re: React vs. Backbone in 2025

#113

Post by austin-cheney »

knollimar wrote: post #96
austin-cheney wrote: post #56

Earlier quoted context omitted.

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…

Composability is really valuable; you don't get bogged down in interconnectivity when your application gets really big. You pay for it for smaller stuff, though, since that multiplicative coefficient is high.

I don’t have that problem with large vanilla projects. It’s just a matter of organization and this is supremely straightforward when making heavy use of TypeScript interfaces to define that organization.

Re: React vs. Backbone in 2025

#114

Post by marcelr »

React is enterprise at this point. LOC isn’t the selling point.

While i dream of post react world, none of the frameworks meaningfully push the needle.

I’m working in angular now & signals make it fine.

Everything is fine, nothing is great.

Re: React vs. Backbone in 2025

#115

Post by Izkata »

BoredPositron wrote: post #24
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...

Yeah, it's a lot more complicated than that and has to do with a mix of typing speed and other things (like moving the cursor and focusing in/out of the input). But single character is also always wrong because then it doesn't act like a normal input - characters are grouped together and multiple undone at once. You can try it yourself here in the HN reply box.

Re: React vs. Backbone in 2025

#116

Post by slmjkdbtl »

> React looks cleaner. It reads better at first glance. But that readability comes at a cost: you're trading explicit simplicity for abstraction complexity.

Not always, SolidJS code can look the same as React code, but what goes under the hood is very simple and straightforward.

Re: React vs. Backbone in 2025

#117

Post by talkingtab »

I think many people fail to understand how many people choose to do things.

1. Most people are followers. We really don't want to choose, and don't care. So unless we meet some pain point we will choose the most common choice that requires no thinking.

2. People stick with what they know. Unless they meet some pain point. Windows anyone?

3. Sapir-Whorf modified to: "the language determines how easily you can think."

ANY language is an abstraction - with all that means. If one language enables you to think faster or with less effort it wins. Period. Elegance be damned. An interesting experiment: take a complex JSON file and convert it to JSX. Take a different JSX file and convert it to JSON. It is just much easier (for me) to JSX something. My point is how one way of expressing things can make a difference. Nothing about JSX or JSON as I love them both dearly, but about the difference between how easy/hard/effective they are to use.

Perhaps because (ahem) I am used to React, I can look at the code and reduce it to these things:

* a hook * an array * a return * the return has a nested return

And yes, I was forced to learn useSyncExternalStore, so not a fanboy.

Re: React vs. Backbone in 2025

#118

Post by treve »

ruszki wrote: post #99
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…

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.

Yeah I would argue that it's possible to do it well with Backbone, and you end up with something much leaner but it requires a really strong understanding of state/event flow and lot of discipline, whereas with React the correct way to handle this is the 'obvious' path, which dramatically lowers the barrier to entry.

Re: React vs. Backbone in 2025

#120

Post by AstroBen »

afavour wrote: post #61
ZvG_Bonjwa wrote: post #58

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…

I think that kind of criticism is a reaction to the lack of critical examination of the industry standards. I don’t think React is straight up bad by any means but I do think it is chosen unthinkingly in scenarios where it isn’t necessary. And what of Preact? It’s a 3kb library (compared to > 100KB for React) and is a drop in replacement for probably over 90% of React sites. That wastefulness speaks to an inattention…

Preact adds, among other things..

1. Potential compatibility issues. Their preact/compat package doesn't cover 100% of cases (of course it doesn't, otherwise it'd just be React)

2. Risk. Will this thing be maintained long term? I mean sure a potential migration to React probably wouldn't be too painful but.. why?

So, starting from "The average speed for 4G LTE is typically between 10 and 30 Mbps for downloads"

Saving 100kb buys you what exactly? The initial download certainly isn't a factor.. and in a case where the performance really matters you probably want to skip both anyway

Post reply on HN