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

91–100 of 245 posts

Re: React vs. Backbone in 2025

#91

Post by hellcow »

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…

People make mistakes using bad (but popular) tech all the time. Remember MongoDB when every app needed to be NoSQL for web-scale? Remember when everything was event-driven using Kafka? Remember when every left-pad needed its own microservice?

When large organizations (Facebook, Google, LinkedIn, Amazon) start pushing it, when popular developers blog about it, when big conferences run talks on it, and lots of marketing and ads and sales funded by ad revenue or VC dollars start pushing a tech as “amazing,” it gets adopted by CTOs, becomes a hiring criteria, and suddenly no one wants to admit it’s crap because their entire career depends on it… or more generously they don’t know any better because they haven’t hit the painful edges in production yet, or they haven’t seen how simple things could be with a different architectural decision.

Something being popular doesn’t mean it’s well-suited for a common use-case. Very often it isn’t.

Re: React vs. Backbone in 2025

#92

Post by Izkata »

ascagnel_ wrote: post #67
maxloh wrote: post #18

Earlier quoted context omitted.

They had them from day one. Class component: class Counter extends Component { state = { age: 42 }; handleAgeChange = () => { this.setState({ age: this.state.age + 1 }); }; render() { return ( Increment age You are {this.state.age}. ); } } Functional component: function Counter() { const [age, setAge] = useState(42); const handleAgeChange = () => setAge(age + 1); return ( Increment age You are {age}. ); }

You can actually further simplify the functional component by using setState's callback form. You don't always need to do this, but it makes setting state from within a useEffect much safer in that it won't need the current state value in its dependency array. const handleAgeChange = setAge((prevAge) => prevAge + 1);

That's wrong, it's calling setAge immediately and not making a callback. You'll get an infinite render loop from that. It should be:

  const handleAgeChange = () => setAge((prevAge) => prevAge + 1);
https://react.dev/reference/react/useState#updating-state-ba...

The callback version is really only needed if there's a risk of setAge being called multiple times between renders and you do actually want all the mutations, vs only wanting it based on what's currently rendered.

Re: React vs. Backbone in 2025

#93

Post by qudat »

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…

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.

React isn’t just popular because it’s familiar, that might be a component, but it ignores the historical and technological achievement it created

Re: React vs. Backbone in 2025

#94

Post by _fat_santa »

I've been using React for just about a decade at this point and IMHO the thing that makes it a killer framework isn't one feature but all of them combined that makes it possible to move very fast in product development with multiple contributors. It's easy for devs to pickup relative to other languages, yes there are footguns but for the most part they are in the minority and you figure out the "Rules of React" pretty quickly and avoid them.

Remember folks, were all talking about our figurative drills and hammers in this thread and the folks paying us largely don't care and just want to see a working product. React in this analogy is a very quirky toolbox but it won because that toolbox helps people build the end product faster than most other toolboxes, even if it's filled with some questionable tools.

Re: React vs. Backbone in 2025

#95

Post by nop_slide »

> The Backbone code is brutally honest about what it's doing. An event fires, a handler runs, you build some HTML, you put it in the DOM. It's verbose, sure, but there's no mystery. A junior developer can trace exactly what happens and when. The mental model is straightforward: "when this happens, do this." > The React code hides a lot. And once you move past simple examples, you hit problems that don't make sense until you understand React's internals. I relate to this a lot. I have had to read these two very large articles multiple times to calcify my mental model for understanding exactly _when_ react does something and _why_ it did or did not. https://overreacted.io/a-complete-guide-to-useeffect/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-... Backbone was also my first framework that I haven’t touched in over 10 years, but looking at the code examples from the article I completely understood what was going on.

Re: React vs. Backbone in 2025

#96

Post by knollimar »

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…

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.

Re: React vs. Backbone in 2025

#97

Post by bitbasher »

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…

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

There's a sort of innocent ignorance that comes with people who assume well-adopted or renowned frameworks or technologies became renowned due to positive virtues and not due to external factors at the time.

React was Facebook's reaction to Google's Angular, which was a reaction to backbone and others at the time. At that point, it became a company pissing contest for developer mind-share that embroiled developers in hype trends when the companies themselves were not even using those technologies.

Bootcamps began to teach those technologies because of the hype train and then companies began to hire for those skills because it's what every "new" developer was skilled with due to the massive push by bootcamps at that time (mega rise of MOOCs and bootcamps).

I've spoken to countless founders that made tech choices due to "hiring concerns" and "it's what developers want" and "my buddy XYZ is using it" or "we can't use X because that's the old way".

There's certainly a space to discuss these technologies without being "arrogant" and dismissing what the "majority of developers" use. Maybe the majority is wrong.

Re: React vs. Backbone in 2025

#98

Post by Izkata »

gravity13 wrote: post #23
thedelanyo wrote: post #12

Earlier quoted context omitted.

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 man…

More than batching updates, what it advertised back when React was new, was the virtual dom's diffing with lightweight nodes - it finds what changed in the tree and only alters the heavyweight DOM nodes where necessary to get the end result. At the time it was common to just swap a whole subtree when anything inside it changed, to guarantee you got everything.

Re: React vs. Backbone in 2025

#99

Post by ruszki »

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.

Re: React vs. Backbone in 2025

#100

Post by [deleted] »

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…

[deleted]
Post reply on HN