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

61–70 of 245 posts

Re: React vs. Backbone in 2025

#61

Post by afavour »

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

I see articles like this as a provocation to pay more attention rather than a serious proposal.

Re: React vs. Backbone in 2025

#62

Post by zarzavat »

There should be a name for the fallacy: "You don't need React to do therefore you don't need React".

Let's just call it "the React fallacy" because everybody always picks on React.

It's like judging a programming language based on the length of its Hello World program.

The reason I use React for simple things is because I also use React for complex things which require it (or another framework of equivalent power), and I don't want to use multiple frameworks.

After all, simple things have a habit of becoming more complex as you learn more about the requirements, but rarely the reverse. It makes sense to aim your most powerful tools at even simple problems, if it avoids a rewrite in the future.

Re: React vs. Backbone in 2025

#63

Post by Jcampuzano2 »

Its hilarious reading this article and then the code because despite sometimes being a React hater - the React code is entirely more readable and followable.

Yes there are good frameworks that I'd argue beat React in multiple facets, but Backbone is not it having written it in the past.

- Two way data flow with stores is terrible for predictability

- Batching is not built in by default so you get layout thrashing as your app scales unless you're very careful

- You can easily blow away entire DOM trees if you aren't careful since it does not do any sort of reconciling differences.

- And more.

And the argument about needing to know stuff about the framework is entirely worthless. There are frameworks all over every single programming language ecosystem and ALL of them come with something you have to know about the framework itself, thats the tradeoff you make by picking a framework at all. Can we stop using this as an argument that there is magic or not? Yes React does tend to have a bit more in certain areas but they things they mentioned aren't even close to the worst offendors and have legitimate use cases.

The number of quality of life improvements, performance considerations, warning/DX improvements, etc. Its just not comparable for a small toy example.

Go build a full app with Backbone and React and tell me React wasn't miles easier to reason about and continue adding features.

Re: React vs. Backbone in 2025

#64

Post by rkomorn »

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…

> I do think it is chosen unthinkingly in scenarios where it isn’t necessary

Does this genuinely matter beyond (borderline dogmatic) perfectionism?

There are plenty of things that make products or projects bad, and I'd say, at most, the choice of framework is incidental. It only becomes symptomatic when you have an axe to grind.

Re: React vs. Backbone in 2025

#65

Post by michaelcampbell »

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…

The Blub Paradox is real, and you'll see it everywhere.

Re: React vs. Backbone in 2025

#66

Post by aatd86 »

picardo wrote: post #50
azangru wrote: post #40

Earlier quoted context omitted.

> You could argue that the real innovation of React was "unidirectional data flow" Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up? > but React team made Flow architecture central to the framework Didn't they call it Flux rather than Flow?

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

Re: React vs. Backbone in 2025

#67

Post by ascagnel_ »

maxloh wrote: post #18
thedelanyo wrote: post #12

Earlier quoted context omitted.

Does React have built-in state management?

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

Re: React vs. Backbone in 2025

#68

Post by afavour »

rkomorn wrote: post #64
afavour wrote: post #61

Earlier quoted context omitted.

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…

> I do think it is chosen unthinkingly in scenarios where it isn’t necessary Does this genuinely matter beyond (borderline dogmatic) perfectionism? There are plenty of things that make products or projects bad, and I'd say, at most, the choice of framework is incidental. It only becomes symptomatic when you have an axe to grind.

IMO, yes. There are a lot of people out there with underpowered devices or slow internet connections (including me when I’m on the subway!) and modern web dev practices that output MBs of JS for simple things are a terrible experience. Just not one experienced by the developers on super fast computers and wired internet connections.

Try browsing the web with Chrome’s network throttling and CPU throttling enabled. It can be torturous.

Just to cite it again: there’s a 3kb library available that does 90% of what a >100KB library does. That no one ever even considers it is not about “perfectionism” in my eyes, it’s industry wide laziness.

Re: React vs. Backbone in 2025

#69

Post by aatd86 »

amelius wrote: post #38
jgalt212 wrote: post #32

Earlier quoted context omitted.

> For massive apps with 1,000 components on the same page If have a 40X25 table on your page that's editable, that's your 1,000 components right there. But away from tables, it does seem overkill to have 1,000+ components on a single page.

1,000 components is my standard test for trying out a new UI library. I recently tried it with Kotlin/Compose. Turned out that everything becomes noticeably slower with so many components, even if the components are in a scroll view and only a few of them are visible.

Displaying so many would require virtualization. No one is going to see a myriad of components all at once anyway. The slowing down part might be eager computations in partially optimized implementations.

The same way we use pagination on the web, or lazy loading, etc...

But I guess the question is whether that should be a default...

Re: React vs. Backbone in 2025

#70

Post by codingdave »

zarzavat wrote: post #62

There should be a name for the fallacy: "You don't need React to do therefore you don't need React". Let's just call it "the React fallacy" because everybody always picks on React. It's like judging a programming language based on the length of its Hello World program. The reason I use React for simple things is because I also use React for complex things which require it (or another framework of equivalent power), a…

> The reason I use React for simple things is because I also use React for complex things which require it...

The reason I drive my 18-wheeled semi truck to the local store is because I also drive my 18-wheeled semi truck when hauling cargo across the country, and I don't want to use multiple vehicles.

/s

Fallacies can exist in both directions. "Use the right tool for the job" is good advice.

Post reply on HN