React Vs. Backbone in 2025
Posted2 months agoActive2 months ago
backbonenotbad.hyperclay.comTechstoryHigh profile
heatedmixed
Debate
85/100
ReactBackboneJavascript FrameworksFront-End Development
Key topics
React
Backbone
Javascript Frameworks
Front-End Development
The article compares React and Backbone in 2025, sparking a debate about the complexity and trade-offs of different JavaScript frameworks, with some defending React's abstraction and others praising Backbone's simplicity.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
135
0-12h
Avg / period
20
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Oct 25, 2025 at 5:43 AM EDT
2 months ago
Step 01 - 02First comment
Oct 25, 2025 at 7:19 AM EDT
2h after posting
Step 02 - 03Peak activity
135 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 2, 2025 at 3:16 AM EST
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45702558Type: storyLast synced: 11/20/2025, 8:28:07 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
One off it seems fine, but a huge backbone app gets really complicated for me. Show me a huge react app vs a huge backbone app and I will understand the react much more quickly.
"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."
I don't think that's true. A large backbone app has a lot of code that you'll have to trace through multiple files in different directories - the template are here, the functions are there but the endpoints are over there and... maybe it's just the backbone app I have to update but it's much more confusing and abstracted than the react app I also have to update. And don't even get me started with adding a new component. I can drop a new component into the react app and import it anywhere and it's super fast and easy... backbone not so much.
This is exactly my experience with large scale Backbone apps (from 10+ years ago). Even with extras like Marionette it quickly became a complete nightmare to navigate or maintain. Zombie model and view objects leaking memory was almost inescapable.
I remember in 2013 I introduced Backbone to my current company, hoping to make sense out of our existing jQuery + ASP.Net MVC application. After ~3 months of code from junior and mid level developers (in house and off shore) I began to deeply regret my decision. There was just not enough patterns and utilities in the framework to keep things from going off the rails. We eventually shifted to Angular v1 and it was glorious, things just worked and even the ceremony I needed to add felt worth the trouble for the speed of development we gained.
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 DOM
- Reactive state management
These two things not only made my life as a programmer much easier, but they also developed my ability to build software that wasn't spaghetti.
Class component:
Functional component: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.
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 manual re-renders (via jQuery) which are direct DOM manipulations. This is expensive, meaning, it is not performant as your DOM grows.
React solves the problem via it's virtual DOM, which keeps an optimized DOM engine in memory, batching expensive updates onto the real DOM.
This means you get the convenience of your UI always representing your state, which means your code can become more declarative (what you want), and less imperative (what you need to do in order to get it). The author calls this "magic," but as somebody who was a Backbone main turned React main, I call this "sanity."
People do add state managers to store state outside the component tree, but a lot of components don't need that.
https://news.ycombinator.com/item?id=3110025 https://web.archive.org/web/20111015073638/https://backbonet...
Other than the lack of imports, 15 years later I don't hate it.
Due to LLM's my thinking about coding has changed quite a bit, I'm far more interested in what is the best way a language can be written such that LLM's can most effectively write it. JSX/declarative is seemingly solid. I think the React community from useEffect onwards is starting to get a bit wishy washy, probably not a great way for LLM's to "think". (something about expressiveness, explicitness and parse-ability)
I can say the same about Angular, you really need to know how Angular works to know what you're doing. That's the whole issue with these frameworks. At least React doesn't try to abstract too much
What do you mean? The DOM is abstracted away. Hooks are magical, and don't work like regular javascript functions. The scheduler, and the concurrent features are magical. The string pragmas are magical. It is all getting more and more magical, and you need a linter to keep you in line with the magic.
It's the definition of sunken cost fallacy: I mean, heck, I genuinely believe React is garbage, and yet I use it for just about every project because of its ecosystem and lazy "npm install <whatever-i-need>" muscle memory.
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)
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...)
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.
Seems more like personal preference.
I absolutely failed to follow the logic of this article - is there any?
The toy examples having the same amount of code is meaningless. They're saying it's bad because react is more complicated. But this works in react's favor that simple examples are simple.
It's also meaningless because it's a toy example. Even if the react code was half the size of the backbone, you could still use the strawman of "react's complexity isn't worth saving 5 lines of code" which people would agree with.
Then they go on to complain about use-effect and state-management. But use-effect isn't in the code example. But then why compare it to backbone which also doesn't solve those problems and is arguably much worse at them.
> People say "you need to rebuild React from scratch to really understand it," and they're right
Actually laughed at how shameless this is. Who said this? This is just a thing the author got and just decided is a fact. Not only is that quote not in the linked article, I don't think the average person would say this.
And the answer to what about something small, the answer is either lit-dev, or vanilla. It's not early 2010s, a lot of the functionality of libs like jquery, backbone that made them popular was incorporated into js.
Put it another way -- you can find those "minimal JS frameworks" and create this same demo easily, but it doesn't mean the other JS framework is all that one needs.
If you look at the code the example shows, the replication is a bunch of HTML and tailwind CSS classes in backbone. So basically if you decide you want to change the input to have a different radius in one place, you need to implicitly know that there's another piece of code patching and replacing that elsewhere, which has duplicated the code.
I'm not one to pray to the alter of DRY like it's the end-all be-all of programming principles, but you take this pattern and repeat it throughout a production codebase and you have a bunch of repetitions that need to happen.
This is the problem with Backbone - it's edits are imperative - meaning, each one is a source of errors. React makes state updates declarative, so you only need write the rules just once. Somebody coming along to edit the code doesn't need to find the implicit relationships in the imperative code that might break or cause inconsistency, because they don't need to exist anymore.
React is safer. It's not even a contest.
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, useEffect, etc.
Imo every React course on the internet should start by having people implement a multi-step form wizard using solely Jquery. You don't appreciate where you are if you forget where you came.
You could make a similar comparison between Kotlin and Java and reach the same conclusion. However, Java has evolved significantly over the past 15 years, and most of Kotlin’s features are now also available in Java.
A custom language that basically depends on a single guy is a hard sell.
Linux and Redis have funding and millions of users. So much depends on these projects. Rails is less popular these days but still a project with a long history, financial backing, and a huge ecosystem.
Imba has some brilliant ideas and Sindre is extremely smart... but IMO the decision to go with a custom language has hurt the project more than it has helped. It won't work with any of the tooling around JS/TS. Development is also extremely slow. More than 4 years after announcing v2 here on HN[1], it still hasn't been released.
The reality is that almost nobody is using Imba and it currently sits at about 2000 weekly downloads on NPM with no growth. Even Mithril which is also super niche has more downloads than Imba [2].
[1] https://news.ycombinator.com/item?id=28196158
[2] https://npmtrends.com/imba-vs-mithril
I do use react but only for very specific well-defined reusable components and I use js events to message them. I try to keep it as simple as possible. I can't imagine creating an entire site with react.
One might argue that it is Google Translate that messes up the DOM for 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.
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 frustration I had debugging a UI because it was freezing due to cascading state changes. That was because we were using Backbone Store, which had bidirectional data flow, and when one updated the store, it would trigger a change to the UI, which would change the state store, which would change the UI, etc.
You could argue that the real innovation of React was "unidirectional data flow," but React team made Flux architecture central to the framework, making it easier to adopt good practices, whereas Backbone remained store agnostic and even encouraged Backbone Store which used the observer pattern for many years. I think you should choose a framework that allows you to fall into the Pit of Success, and React was that framework at the time, and for my money, it still is.
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.
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.
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...
Warning: Lighthouse issues a warning when the page's <body> element has more than ~800 nodes (elements).
Error: Lighthouse reports an error when the <body> element has more than ~1,400 nodes.
Other Related Lighthouse Warnings Lighthouse also flags two other related issues, which often contribute to a large DOM:
Maximum DOM Depth: It warns if your DOM tree has a nesting depth greater than 32 levels.
Maximum Child Elements: It warns if any single parent element has more than 60 direct children.
The general recommendation for optimal performance is to keep your page's total DOM node count below 1,500.
source: https://web.dev/articles/dom-size-and-interactivity
These are "NODES", not even components as you say...
You don't have this problem with UI libraries because all users will run the same library.
There are a myriad of examples anyone can come up with that require a UI library to simply be fast. For example, perhaps someone wants to implement minesweeper with checkboxes. Or build an "infinite" feed, or a settings panel showing thousands of settings of a system where you can filter with a filter box, etc., etc. You can argue against all of these cases, or you can simply rely on a fast UI library and be done with it.
Why would you do it like that?! Just have a normal component for a table, and when the clicks on a cell, spawn (and teleport) an edit component over that cell.
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?
Ah, you may be right. It's been a long time.
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.
There is a DOM tree, but parents don’t pass data into or receive events from children.
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.
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
https://youtu.be/nYkdrAPrdcw?t=757
Secondly, they kept talking about this creeping complexity in their code base of about 8 lines of code. 8 lines is still ridiculously tiny. I suspect their actual concern is that the code did multiple things like decrementing a number and modifying a state. I understand this was before TypeScript where execution can be planned against an interface, but I still would have created an object that stores all the relevant data they need to modify on each interaction.
Its like comparing your car to a Kia Soul as opposed to a Bugatti or McLaren. It not a comparison of what's awesome. Its a comparison against that thing in common use. It doesn't take much to be better than that.
https://youtu.be/8pDqJVdNa44?si=kEhofuwlthON62xz
The basic idea of a unidirectional loop is how video games were built for years before React.
You pay for it for smaller stuff, though, since that multiplicative coefficient is high.
Never religiously cling to statements such as "strictly separate presentation and content". These are all just guidelines to suggest simpler solutions, not hard rules that guarantee simplicity. They will sometimes be excepted.
There are such things as components, which compose strictly by interfaces and externalize separate details, but it is up to the programmers to realize them in their programs. Also, simplicity is a global property of a system. Nothing can be judged on simplicity in a vacuum.
All that being said, I don't have experience in web or UI in particular. Seems like logic is moreso a local thing, whereas presentation is moreso global (but may consider locally defined advice). State can be local or global.
Readability is highly subjective. At this point you are talking about what is easier for you. Easiness is not simplicity. Simplicity, in almost all cases, requires addition effort and that is not easy.
"Everything should be as simple as possible, but not simpler"
- Einstein (probably[0])
Brainfuck is a simple language. A Brainfuck program written to parity with an existing non-Brainfuck program is likely complex. A musical note is simple, but a musical score may be highly complex.
I think your objections are misplaced.
[0] https://quoteinvestigator.com/2011/05/13/einstein-simple/
You can hit the same problem with React. Circular state updates. State change->trigger useEffect->change state. I hit those when I had just started React.
Backbone employed a two-way data binding flow. You're responsible for updating the models (ie. state) (way #1) when the user triggers events, AND you are responsible for updating the DOM whenever the models (ie. state) changes (way #2).
In React, they used a revolutionary new paradigm (flux), making it so you only worry about one direction (updating the models/state in response to events); you never render anything (React renders everything for you in response to state changes)!
If you've tried developing a non-trivial site with both, it quickly becomes apparent how much that one difference completely simplifies a huge aspect of development.
If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it. We've asked you at least once before: https://news.ycombinator.com/item?id=36796345.
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.
As you say many people do not understand how important, vital and bizarrely _non-obvious_ uni directional data flow was.
I appreciate the point about unidirectional data flow solving real problems, but I think we're trading one complexity for another rather than actually simplifying things.
Yes, cascading state changes with Backbone Store were frustrating to debug. But React's abstractions introduce their own set of equally frustrating problems: stale closures where your click handler sees old state, infinite useEffect loops because an object in the dependency array gets recreated every render, mysterious input clearing because a key changed from stable to index-based.
The difference is that Backbone's problems were explicit and visible. When something broke, you could trace the event handlers, see what fired when, and understand the flow. The complexity was in your face, which made it debuggable.
React's problems are hidden behind abstraction layers.
I'm not saying React doesn't solve problems. I'm questioning whether those solutions are appropriate for the 99% of apps that aren't Facebook-scale. Sometimes the explicit, verbose approach is actually easier to reason about in the long run.
Having built many large-scale Backbone apps, anytime someone new came on board it was really very, very difficult, no matter how many design patterns one applied.
React's innovation was making FP mainstream. And then teaching the value of simplicity, as a principle. And yah, if something broke, it might be a little opaque, but at scale and in general, things broke _way less often_.
This is also the reason why most devs are full-stack now. Back in the day backend devs wouldn't dare touch FE code, and now its "not so bad", and pretty much anyone can work all over the stack.
You can use other frameworks for the other 1% of apps
That’s not to say that there aren’t benefits from that but it’s definitely extra complexity compared to using web standards.
Meanwhile, there simply aren’t web standards that match React’s capabilities.
> Meanwhile, there simply aren’t web standards that match React’s capabilities.
This isn't true for much of the web but it’s more deeply missing the point: if you’re building a web app, you need to learn the web APIs because those are what all web apps actually use. Adding intermediaries means that you have more things to learn, troubleshoot, and optimize. React’s value comes from managing the complexity of the code you write, which can be a real benefit for some projects but it doesn’t remove the need for you to know how browsers work.
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.
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).
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.
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.
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.
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.
https://developer.mozilla.org/en-US/docs/Learn_web_developme...
So on the second visit, you'll have my vendor bundle cached anyway, the app loads instantly, and you will never even remember how long the first load took.
Given that—tell me again why I should care to convince my boss we need to put considerable investment into an alternative technology with a bunch of dragons lurking about, that may or may not be abandoned in a few years and bite us later on, which might introduce compatibility issues with new libraries, which existing staff and new hires must be trained to account for?
Why would I opt for a world of potential pain, just to make your first page load under bad (thus: rare) conditions slightly better?
One thing I’ll also say: building static websites and building big interactive web apps are two points on a LONG spectrum. Yet for some reason online discourse ignores this.
This enormous spectrum gets compressed into just “modern web dev” or “JavaScript”. Not just in conversation, but in teaching materials, job postings, you name it. It leads to wild disconnects and disagreements between people who think they are peers but are actually building radically different 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
And react usually is not just 100kb.
SSR html is vastly faster for all parties involved. So much so that all spa frameworks have introduced some sort of server rendering, astro is growing a lot, and things like htmx, datastar, hotwire etc are all getting a lot of fawning attention.
The "paleo influencer" comparison is interesting, but I think it actually works both ways here.
Yes, there's a temptation to romanticize the past and dismiss modern tools. But there's an equally strong tendency to assume that newer, more popular, and more widely-adopted automatically means better. React didn't just win on pure technical merit. It has Facebook's marketing muscle behind it, it became a hiring checkbox, and it created a self-reinforcing ecosystem where everyone learns it because everyone uses it.
The article isn't suggesting that a "huge global collective of the world's most talented engineers have been conned." It's asking a much more nuanced question: did all that effort actually move us forward, or did we just move sideways into different complexity?
Look at the two implementations in the article. They do the same thing. They're roughly the same length. After 15 years of React development, countless developer hours, and a massive ecosystem, we're not writing dramatically less code or solving the problem more elegantly. We're just solving it differently, with different tradeoffs.
Sometimes looking backward isn't about being a "retro-idealist," it's about questioning whether we added complexity without proportional benefit. The paleo diet people might be onto something when they point out that we over-engineered our food. Maybe we over-engineered our frameworks too.
But they arent the same, the backbone code has raw HTML strings. These are opaque for code editors and not type safe. React code is using typed objects to construct the html (if you used typescript like is standard in 2025 for react projects). The backbone app is disconnected in the rendering flow. the space-y-2 selector is ambiguous and causes unnecessary searching. Just in this small example adds a level of indirection that just adds noise to what the component does. With everything setting raw html, what if you wanted the requirements blob to be a seperate component for instance. this is super easy and clean in react because html and custom components are treated the same.
It also cherry picks an extremely narrow use case of a single element on the page of a password element. This hides the realities of mature apps that you then need another parent component to check if the confirm password field matches, submits the form to backend and displays errors, checks if username is taken etc. Your example doesnt show calling another component from inside a component, etc.
Your purposefully slicing it in to a narrow use case and trying to show equivalence where there isn't
This is the equivalent of those "Primitive Technologies" Youtube videos of building a swimming pool out of mud. Yeah sure technically you accomplished some definition of a "swimming pool". Yes, in some lens you can stand back and look at your pool and a inground pool with filtration, etc and say that you accomplished the same. Yes, technically you proved if you want a swimming pool you don't need a bunch of other equipment. But if you are building a swimming pool to last and be usable for the next 10 years, you will find out why modern pools are not a dug out hole filled with muddy water.
Try using a proper IDE, then, which can handle embedded HTML just fine.
Switching to React for that app (and everything else) was such a godsend. Once React landed in the codebase it spread like wildfire because of how eager everyone was to burn down the old way!
To me the “it succeeded because marketing” rings hollow because my experience at the time was:
- people loved their MVC ideas and “semantic makeup”, putting template in the JS was so WEIRD and ICKY. And no doubt the compile step for JSX still is annoying one-time complexity. Lots of resistance / thinking React was dumb.
- then you hear about someone on another team replacing a small but annoying feature with React and how relieved they are to be out of backbone hell
- you try yourself, it’s a weird new world and you struggle a bit with the new concepts. Hit a few sharp edges.
- after a week and a half you can’t go back.
- after 6 months (almost) everyone on every team wants to rewrite to React. (We had a few front end leads clinging to their Separation of Concerns as though changing class names on a node in backbone wouldn’t break a zillion event handlers)
If definitely became The Way and self reenforcing, but in my mind that happened primarily out of merit.
That’s not to say popularity guarantees quality, that every menu change is progress, 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 nutritional equivalent of paleo influencers.
Such claims would suggest a huge global collective of the world’s most experienced eaters have been conned into fundamentally unhealthy food choices, which is a little amusing.
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.
It has very little to do with the right abstraction or the best technical solution to the problem.
The web has no default design pattern. It’s the Wild West for better and worse.
I made my peace with modern web stack once I understood this.
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.
When people throw around words like "foolishness" to describe tools that millions of professionals use, its hard to take the rest of their comment seriously. It radiates a special blend of arrogance and ignorance.
Whether React is good or bad, there is a reason people use it. Outright dismissing it entirely seems a bit like chestertons fence.
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.
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.
In fact, Backbone is 17.7kb minified+g zipped. So I guess other frameworks make less sense than react?
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.
I agree that all frameworks require learning framework-specific concepts, but I think there's a meaningful difference in what you need to know and how that knowledge transfers.
With Backbone, jQuery, or vanilla JavaScript, you're learning DOM APIs, event patterns, and explicit state management. These are things that are visible, inspectable, and fundamentally close to the platform. When something breaks, you can pop open devtools, see the actual DOM, trace the event handlers, and understand what's happening. The knowledge you gain is transferable. It's about how the web platform actually works.
With React, you're learning abstractions on top of abstractions: virtual DOM diffing, reconciliation algorithms, why objects in dependency arrays cause infinite loops, why your click handler sees stale state, why your input mysteriously cleared itself. This is React-specific magic that doesn't transfer. It's knowledge about how to work around React's mental model, not knowledge about how the web works.
You mention that batching and DOM reconciliation are solvable problems that justify React's complexity. But the article's point is that for most apps -- not Facebook-scale apps with 1,000 components on one page, but normal CRUD apps -- those problems can be solved with simpler patterns and conventions. We don't need a virtual DOM and a sophisticated reconciliation algorithm to build a form validator.
The real question isn't "does React solve problems?" It's "does React's complexity match the complexity of the problems most developers are actually solving?"
Kind of disrespectful to reply to valid criticism of your AI slop article with more AI slop. Write like a human being man, what’s the point?
To be sure some of it is a result of still missing browser primitives for e.g. performant scroll table views but there have been a lot of developments very few capitalise on.
For example: one of the big benefits of apps vs the web is that you download the whole app once (perhaps at home, over WiFi) and then when you’re out and about you’re only downloading the data you need to perform tasks. An API to achieve the same on the web, Service Workers, have been around for years. But they’re an afterthought in an industry that prioritises developer experience over user experience.
Where are the frameworks optimising smart caching with Service Workers, using local-first data in IndexedDB then syncing with the Background Sync API?
Which is literally the entire reason any framework or abstraction is chosen (most of the time IMO).
Also Preact but the mental model is closer to React.
And Vue can be used from a script tag without a build step too.
That isn't to say you should accept every abstraction either, but my point is that we all use abstractions where we don't necessarily understand the non-abstracted form. The key metrics therefore are:
1) ensure the abstraction gives you coding velocity benefit commensurate to the complexity of the abstraction
2) be very sure the abstraction provider is trusted enough to ALWAYS generate valid code in non-abstracted form
3) ideally, have some level of capability to debug the abstraction/generated code (in the worst case - per #2 that should rarely be necessary)
I remember writing Backbone applications with lots of deeply nested components. Trying to keep all the state in sync and reacting to events. It certainly wasn't simple and straightforward.
This just feels like a very silly article.
Compared to my confusion making sense of that project, I simply cannot imagine getting so confused orienting in a React project, even if it were done by an inexperienced person. It seems to me that the "extra" abstractions of React compel you to use them, and so things end up in reliable, sensible places.
The entanglements the author mentions feel like part of the benefit, I guess?
[1]: https://github.com/compdemocracy/polis/tree/edge/client-part...
71 more comments available on Hacker News