I worked with Backbone, Angular 1, Ember, and then React.
The article overlooks the problems that made React popular:
- Composition: Composing components is easier and more efficient in React. Backbone’s render function assumes "this.$el" is mounted and available in the DOM. That makes composition difficult: you cannot simply nest one component inside another without managing the DOM lifecycle of subcomponents. You don’t need 1.000 components to feel the pain.
- Event handling: You can’t pass an event handler as a string, so the events object must be paired with the selector to locate the element. Any structural changes require updating selectors or managing unique IDs.
- State management: Re-rendering components when state changes becomes messy in Backbone fairly quickly. That mess is why Angular 1 gained popularity. React simplifies this further by enforcing a one-directional state flow.
- Efficient DOM updates: Even if you implement composition and state management ad hoc, you still must update the DOM efficiently to avoid layout thrashing and related issues. React isn’t immune, but these problems are typically easier to handle.
- Other features: Implementing useful capabilities from scratch, like lazy loading parts of components (for example, suspense) or building hybrid apps with server-side rendering, requires significant work.
I'll argue that nowadays, if you want to use vanilla JS with templating support, lit-html (not the full framework, just the template part) is a much better choice than Backbone.
The example is also unrepresentative of anything meaningful. TodoMVC[0] is the classic point of comparison, and the Backbone version is a nightmare to grok compared to React[2].
That's all true, but I think the article's point still stands: React trades one set of compromises for another, and regardless of the tool used, software engineers using that tool have to do a lot of lifting to get the tool to work. It's not a question of whether react is better than backbone or vise versa, it's a question of whether we software engineers, as a group, are emphasizing the correct compromises, and what takeaways we can make from examining the compromises of today's popular tools.
I definitely do a lot less lifting with React than with jquery or backbone; like OP I also used all three (and others) in production, and my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air. In particular, counter point to the article, i loved that i could do something relatively complex, relatively easily, but still pop open dev tools and understand what was happening. I think tis great new libraries and concepts are sprouting but imo looking back wont help; browser javascript has come a LONG way obviating a large chunk of the reason we were all using jquery in the first place. Basic CRUD does fine with server side rendering, and is easier to test and maintain. Using that until it hurts is a solid strategy for avoiding react if thats ones goals.
The reality is stateful UI is complex on its own. Then JS tooling is complex (byo typescript and std lib). Then UI is something everyone sees so the whole company has opinions about how it should look. Mush it all together and FE development is rough. React is a punching bag because its been dominant so long. Id welcome the next phase when it arrives. But building toy apps with aged technology imo wont bring to light any unturned stones. Id recommend researching the plethora of real code and discussions that have beaten this horse to death on the open internet instead.
> my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air.
This was exactly how I felt. I building a Backbone app around the time React was released. It was only around 2600 lines of JS at the time but event handling and state management already felt like a tangled mess.
Porting it to React was a huge improvement even at that scale and really paid off over the next 5 years of development.
Agreed. You want to run htmx at a company where the business requirements change every month? Good luck but you’re going to end up rewriting it and have a much harder time hiring.
> 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 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.
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.
Look, I wrote one of the only published books on Backbone, and it will always have a special place in my heart, but ... the OP has no idea what he is talking about.
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.
I remember watching one of the first React demonstrations/talks, and the biggest selling point was literally "You have a web page with various elements, and some of them needs to keep in sync, at Facebook we have chat messages and notifications, and they need to be in sync regardless of where you are, even on the same page, how do you solve that?" and then outlined how having one place for the state to live solves that issue without resorting to two-way data-bindings, instead data only flows in one direction.
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.
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.
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.
Yes, applying compositional patterns and one-way data flow is most appropriate for all apps, independent of scale. Why? Because developer A (author of app x) leaves company. Developer B gets hired. Developer B is onboarded in an afternoon because things can be understood at a glance thanks to functional patterns and one-way data flow.
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.
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.
At one point I also moved from Angular to React, after moving from Backbone to Angular, and from "just" jQuery + jQuery UI to Backbone. After moving to React, I haven't found the need to move to something else, most of the alternatives are marginal improvements, while the difference before and after React is pretty drastic.
> 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?
The native DOM doesn’t have an idea of “data flow”, it’s just a big tree that you can modify in whatever way you see fit through its imperative API. For example you could add an event handler to a child node which directly modifies one of its ancestor nodes. With React, your “nodes” in the tree are functions. The child node has no idea about what its ancestors are, it only knows what it is passed as arguments (i.e. “props”). The only way implement a similar thing would be to raise the state/event handling code to the ancestor node, and passing relevant information down as props, thus giving the unidirectional data flow. Of course, if you really needed to, you could drop back down to the native DOM API, with React’s useRef and useEffect hooks, but the default behavior is this unidirectional data flow through function composition.
Flow was a type checker (used to be Typescript vs. Flow debates early on before Typescript ended up with more support), Flux was the unidirectional data flow architecture.
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.
From what you're saying, it sounds like components in this framework (React?) are not simple at all. A major hurdle in evolving a program is capturing and maintaining simplicity. The proof of whether something is simple lies in its composability, readability, and so on. If someone claims to have found a method of writing simple components, do not believe them if the simplicity is not evident. A truly simple solution would not be so burdened, and a somewhat simpler solution would be less burdened. Of course, simple still doesn't mean easy, because the Fast Fourier Transform may be simple, but I can't teach it to a 5 year old (or anyone, really).
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.
You are mixing your terms. Complexity is another word for many. As such it is measurable objectively. The opposite, simplicity, means fewer.
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.
I did say that simple doesn't mean easy. I don't know how to judge whether something is many or few without a fixed norm, nor how to measure it without reference to the environment it exists within. Simplicity does not mean having so little to the point of unease.
"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 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.
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
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.
React came to be because folks at Facabook couldn't get the label displaying unread notifications always to display correct value. This seems like ridiculously straightforward problem easily solved. Yet still many websites and applications today struggle with that.
>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 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.
> 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...
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.
1,000 is a lot, but not uncommon for a CRUD app. Especially when you start with a small one and the scope creeps. Users want one more feature, and one more field. Then it's time to replace some other CRUD app and you've already got this one going ...
> If have a 40X25 table on your page that's editable, that's your 1,000 components right there.
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.
Also can we stop pretending React is any more "complex" than any other rendering library. You can't get much simpler than () => <div>Hello, World</div>
What makes React complex is that your simple example pulls in 100KB of code and entire layers like the virtual DOM which increase the memory and CPU requirements while adding significant new concepts a developer has to learn to be productive.
That’s not to say that there aren’t benefits from that but it’s definitely extra complexity compared to using web standards.
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.
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.
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.
> They do the same thing. They're roughly the same length
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.
Did you work on any big backbone apps professionally? We had a huge one at Airbnb where after a certain scale any change by anyone - from new grad to expert - could get stuck in 2 days of debugging pure incidental complexity. Change some ui dom structure? Oops you broke someone’s selector and their event won’t fire anymore. Send an update at the wrong time? Render loop.
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.
React (and Tailwind for that matter) are great for hiring and getting hired. The chances of someone screwing it up or being lost in their first week/month when parachute into a project are pretty low.
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.
Took the words out of mouth. Every thread about React people come piling in about how overly complex it is.
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.
Is it arrogance or is it experience combined with a different perspective? One developer may love React because of the component ecosystem and talent pool, and another developer may dislike it because they're writing custom HTML/CSS anyways and React requires them to write way more JS than their preferred approach. Would I ever choose backbone? No. But many developers may be surprised by how little vanilla JS that it takes to build modern web apps. More than ever the tradeoffs of different frontend stacks need to be evaluated on a project-by-project basis.
OTOH we are taking about the web, here. A domain notoriously defined by technical debt, the "when all you have is a hammer" mindset, NIH, and resume-driven development...
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.
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.
100% agreed. If you’re making Gmail the extra bulk of React is an afterthought in the context of a giant web app. But when you’re building a mostly static marketing site and don’t consider what’s going to get the thing to load as quickly as possible you’re not prioritising the right things, IMO.
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
> 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.
If you're using my web app (I wouldn't have used React if it wasn't an application anyway, right?), you're very likely a returning visitor. Even if your first page load after signin in is a drag because you're on the subway and for some reason 100KB take five seconds—you're probably coming back anyway, because my app warrants recurring usage (and the industry heavily optimises towards that, but that's a different story).
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?
That 10% missing are event normalization and event bubbling (preact bubble through DOM, react follows vDOM). Choose yourself what you need, but 100% compat with 3rd party libs is why I stick with react over preact.
There is, I think, a sort of innocent arrogance that comes with people who boldly claim that eating McDonald’s is straight up bad or an obvious step down from “real food.”
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.
> ... 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.
There should be a name for the fallacy: "You don't need React to do <simple thing> 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.
> 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.
Seems like your example isn't equivalent to op's because using multiple frameworks increases complexity while picking a different car to drive to local store doesn't.
Your comparison doesn't make any sense because React is just fine for small apps. You're yelling at someone over using their car instead of roller skates to get groceries.
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 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.
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)
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 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."
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.
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.
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.
useState is the built-in way to manage state in React today. There were also similar mechanisms in class components before hooks came along. This is pretty integral to how React works.
People do add state managers to store state outside the component tree, but a lot of components don't need that.
I moved our team from Backbone to Angular almost 6 years ago. I treasured BB on the fact that the entire source code can be read and understood by a junior developer, which made it appealing to me from an adoption perspective in our org, because there was no “magic” to it and a developer inherently understands and accepts that BB solves a real problem in a direct way. Having an army of jQuery devs who still wrote their own XmlHttpRequest functions and handled the inverted IE event bubbling by hand, I needed to ease them into thinking about front-ends as applications.
But my sensibilities as a software developer led me to adopt TypeScript and a kitchen-sink framework as a more stringent way of composing pages rather than just having a Wild West of filling patterns around what BB didn’t offer out of the box. After doing side-by-side comparisons Angular seemed like the most “similar” to what BB looks like day-to-day. I don’t have anything against React/Vue they’re fine.
We are on NG20 now and it’s looking good. I don’t miss BB, we still have some old pages that use it but overall I am not going to get caught up on this code golf stuff. Eventually when browsers catch up and offer out of the box solutions maybe that will be a point where we can go back to implementing things in a simple more native way.
This illustrates greatly why React got so popular.
If you look at the React code, it's 99% "just" JavaScript and HTML. The only proprietary function is `useState`, and even the people who have never touched React probably understand what `useState` does in this code without having to open the docs.
Also, in the Backbone code, half of the application relies on the string selector `.space-y-2`. So if someone in your team changes this class (or add it on another element), and forgets to ctrl+F `space-y-2` and change the string everywhere else, half of the application is broken. Also the layout/style for the checks list is repeated twice (in `render` and `updatePassword`), so if someone forgets to change both, the UI will be inconsistent once the user enters their password. And this a 50 LOC app… imagine now the same problems in a 10k+ LOC app. Maintenance hell.
I don't understand how the author wrote those two examples, didn't see the problems with the Backbone version and conclude there is no differences between both frameworks. React solved the problems present in the Backbone version.
> 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.
You are ALWAYS programming in abstractions. The raw JS code is JIT'd into machine code, for example, which most wouldn't know how to read/debug. The JS functions called are built in the browser and are trusted to function properly.
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)
> These aren't edge cases. They're normal problems you hit building moderately complex apps
These aren’t real articles. They’re slopg diatribes generated by people who can’t even be bothered to communicate a thought.
I feel annoying for being this guy, but i think someone should point out the fact that it’s barely written by a human being. What’s the point in engaging with the point the “author” is trying to make when the author is Claude?
I've never used Backbone, so I can't speak to its ergonomics, but I've used React (a bit back in 2015, and now again this year I've been updating my knowledge and re-learning it), and absolutely agree with the author's frustrations with its "magic".
I'm working on both a backend (in Rust) and a frontend (Typescript, React). The backend makes sense; the code I write does what I expect it to, and there's no magic. The frontend... oh boy. I constantly run into infinite-loop re-renders, input elements that won't update or randomly lose state, etc. I ask Claude Code to help me fix it, and it ends up doing a bunch of the stuff mentioned in the article: adding useCallback, useMemo, tweaking dependency lists, restructuring things in useEffect, adding state variables, etc.
Fortunately I can read the changes and understand what Claude is doing and why, but all of these things feel like huge holes in the abstraction. They're arcane workarounds for problems that React itself creates. And despite learning via Claude's fixes, I still keep making similar mistakes, a phenomenon I've never encountered with any other framework or library I've ever used before.
Having said that, I'll keep using React: it has a huge community around it, answers to problems aren't hard to find, and Claude Code seems to be good at working with it when I screw up and can't be arsed to poke at it until it works. This unfortunately feels a lot like the old saying, "nobody gets fired for buying IBM", but... it is what it is.
I've come to the opinion that for the vast majority of apps I've built, it could all be built using HTML + CSS (all built server side). I can sprinkle in little bits of interactivity using something like HTMX. And I'll have a website that is very easy to optimise, has phenomenal backwards compatibility, and gets rid of a whole class of issues associated with SPAs.
I often regret in my career not pushing back more on "requirements" that ended up requiring a more complicated app, whereas the customer would have been happier with a simpler solution.
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.
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
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.
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.
It feels to me that this specific toy example would be even simpler in vanilla JS. A comparison with a serious, large SPA would be more fair and more informative for comparing frameworks.
If doesn't even use a Backbone model, the main thing that framework was known for. IIRC that's even where the name came from - it was designed to be the core of the site's functionality, the models acting as a bridge between the frontend and backend instead of having to make ajax requests and handle responses manually.
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, useEffect, etc.
> Lots of people don't even know how JavaScript works despite using it every day.
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.
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
most web pages are about to be HTML/JS/CSS generated by LLMs directly for users. Truth is, pre-LLM web frameworks were designed for two things: save developer keystrokes and delay the spaghettification of the codebase. We just automated keystrokes, so that's largely irrelevant now. Users don't read code, so spaghettification is also a non-issue, as long as the framework defines clear containers for spaghettis, and provide clear ways to fork the spaghetti or start over when the user is frustrated with some bug. There's no framework designed with these requirements in mind, but I am working on one.
> spaghettification is also a non-issue, as long as the framework defines clear containers for spaghettis
Sorry, but I disagree strongly with this. When there is, inevitably, a bug that the LLM can't fix, someone's going to have to read all that spaghetti, and they'll curse whoever put it there. "clear containers for spaghetti" is a pipe dream, all abstractions leak, and the bug may very well be in the spaghetti. "Just start over" is unrealistic for large, complex apps.
Of course, if you really have a solution for this, that would be incredible.
I'm ready for all the "what about x" comments, because I'm going to check them all. I'm choosing React over anything else right now because of how well my DevEx has been.
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 actually kind of funny how React devs quite literally don't know how HTML or JavaScript actually works (let alone HTTP or TCP/IP). React is an absolute trash-heap of abstraction that just reinforces its dominance because of popularity, similar to Java in the early-mid 2000s.
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.
And the LLMs are better at React than other frameworks. You need less React devs now than other frameworks. And with greenfield project with the compiler, it seems like an easy path. We don't use React, and I would not choose to do so, but LLMs + Compiler make it a great default for shops starting new apps.
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.
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.
> "react's complexity isn't worth saving 5 lines of code" which people would agree with.
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.
Yeah. I don't follow react closely, but I do know Vue.js is still in very active development and releasing new features because of all the real use cases/bug fixes. Some of the use cases or issues didn't exist back in 2010 (e.g. interoperability with custom elements). "Look at how little progress we've made" only reveals author's ignorance instead of saying anything meaningful or true.
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.
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.
> The main thing to know about Backbone is it’s not intended to be a fully fledged framework like React.
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.
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).
For smaller projects I was very productive with Backbone + Backbone Stickit. With react the earliest projects I tried it with never really had satisfactory standardized data sourcing/binding. Now I've mostly been using the tanstack/react query library for the last few years and it's productive enough. I think I'll be more productive if/when I switch to something like svelte or live view, though. Modern react apps feel like building an app twice to build it once IMO.
I think some of the React vs Backbone debate misses how web projects often evolve in unpredictable ways. Most 'tiny' apps pick up complexity as features are added. So it's useful to build on a platform that scales smoothly and encourages best practices and grows with you.
React has become that platform that it is because teams can reliably ship, maintain the codebase and onboard new folks. Preference for 'right tool for the job' is good but real life means sticking to tools that won't bite you a year later.
I was part of a team building a complex web gui. We started the project in 2015. The GUI had a _lot_ of cascading business logic, an editable high-density grid, all kinds of fun.
In our tools evaluation, React just had too much overhead. changes would trigger a huge cascade of events that killed responsiveness. We went with Backbone and it served us very well.
I know React is king, but so far I have managed to live without it.
As long as React was the "View" and was marketed as such, being able to express declaratively what ui should render given a combination of state+props, it was great. Then... i don't now what happened with hooks sprecifically, but i still have hard time figuring out why they were needed other than making everything looks "more functional" I often read something like algebraic data types, I was astonished. React.createClass was all we needed, and some optimizations from there was possible. Today they market themselves as "don't use React without a framework" it's stupid
I think the broader point being made here isn’t “React is bad” it’s how far we haven’t come in all this time. The user experience on the web is still sorely lacking.
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?
They exist and being developed but the use case is so small when their users have internet.
I don’t really understand the argument either: local-first and offline modes are non trivial to get right, it’s not automatic even with a framework.
Every product I’ve built is able to make a bunch of assumptions: client is working on behalf of a company, on their desktop computer, with good internet. It’s often even more heterogeneous than that: we can often assume MacBook and chrome.
This is the primary use case for massive react web apps: apps behind a login for b2b
Why would anyone care about offline first in that scenario?
> Every product I’ve built is able to make a bunch of assumptions: client is working on behalf of a company, on their desktop computer, with good internet.
That’s your experience, it is not mine. A great many people are making consumer facing web sites that experience majority mobile traffic. It’s not even rare!
I don’t think this comparison is correct. You concluded that not much has changed in 15 years, but you are not comparing 15-year-old idiomatic Backbone code with modern React. Instead, you are comparing modern Backbone code with modern React.
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.
This is how Backbone looked back in the day. Not that I agree with him, but there's nothing new to this, it's essentially a basic View wrapper around a jQuery dom manipulator.
I've worked around a medium-sized and storied backbone project that (for good reason) didn't have time to "get things right" and hoooooo boy can it get complex and spaghetti.[1]
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?
In fairness at the local level displayed here just vanilla JS is damn easy to implement. But when you have a larger app with various interactions that can happen at different levels of the tree, the react abstraction will be appreciated. I say this as someone who was around to see how we dealt with this in backbone and then switched to react for dealing with the same
Yeah no, we didn’t invent things like react to write a password input, we did because as soon as you have more than one event trying to edit one part of the page you’re in hell with backbone. So you add marionette, and a store object, and then there is magic bindings with performance problems or thrashing, and you debug that, and then you…
That’s how we got here. This example is about 1/4th the minimum size needed to study the issue. You don't need hundreds of components, you need a single piece of state that is updated three ways to start seeing the pain.
This is tangential, but does anyone know more about what happened to Redwood JS? This post got me thinking about it, I went to search for it, and it seem to have taken a full 180
React scales. If you can predict the future, if you know your app’s complexity won’t grow, you can choose one of the “simpler” alternatives (and go against the ecosystem trend).
> 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.
> React looks cleaner. It reads better at first glance.
I've struggled to get past this. I don't find it easier to read, and the js and html mixed together is just icky. But I think this is an uncommon opinion, and that surprises me.
React/JSX reads better than other framework templating because
1. It's easy to differentiate the composed DOM from JS logic, since any logic is expressed in JS rather than mixed into the JSX DOM.
2. JSX maps directly to the JSDOM API.
If you know vanilla JS, JSX is a low overhead abstraction.
Interesting. Datastar, the front/back end framework, also has the concept of signals, allowing the backend to update them directly via HTTP responses or SSE events.
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.
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?"
> 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?
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.
Does react still mess up the DOM and, for example, using Google Translate?
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.
As somebody who picked up Backbone after Sammy and other earlier attempts, when React came along and took the world by storm, I more or less decided to nope out of JavaScript development and go back to Rails.
Every generation needs to learn the same lessons in their own time, but people often asked me why I’d go from speaking at national JavaScript conferences to essentially disappearing. The answer was the overwhelming popularity React and Webpack. Life is short and I don’t have time for this shit.
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.
Look for Imba (imba.io) which is being ignored for years. Predecessor of React with features of React and no flaws of React. Works great with just devtools - for debugging.
For something this simple that doesn't need to grow or interact with the rest of the system why would you need Backbone or React? And why would you expect any version to be shorter as it's mostly just the HTML and the data.
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.
> For massive apps with 1,000 components on the same page, maybe React's complexity is justified.
Something is wrong if you need a 1000 components. Not everything has to be exposed as a component. Build something in lower level library and expose it as a react component. There's a real reason something like ag-grid has such a dedicated following.
The reality is Reacts abstraction has always been thin, which begs the question is it truly valuable. It's basically an application pattern masquerading as an abstraction. In 2025, there's no reason any thoughtful organization shouldn't investigate alternatives.
We left Backbone for Vue in 2018, due to its simplicity and ease of component manufacturing. I'm surprised to learn that Backbone still exists. Maybe I should revisit it.
I remembered why we left, I hate handle 'this' in JavaScript :)
I totally agree - the example they give doesn't really need react OR backbone. You could just as easily show vanilla js as the 3rd example and wonder why you would ever even need a framework.
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.
> 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
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.
Angular v1 was absolutely the game-changer for sane UI patterns. Although it could choke on large datasets and models were iffy, it allowed us to worry less about the framework and more about the work at hand.
10 years back, every month there would be a new JS framework, backbone, ember, angular 1, 2, vue etc.
With React, I would argue that UI got standardized. At this point the ecosystem is so active and robust that choosing anything else has to be because you have hit a edge case not solved by react, next etc.,
I worked with Backbone, Angular 1, Ember, and then React.
The article overlooks the problems that made React popular:
- Composition: Composing components is easier and more efficient in React. Backbone’s render function assumes "this.$el" is mounted and available in the DOM. That makes composition difficult: you cannot simply nest one component inside another without managing the DOM lifecycle of subcomponents. You don’t need 1.000 components to feel the pain.
- Event handling: You can’t pass an event handler as a string, so the events object must be paired with the selector to locate the element. Any structural changes require updating selectors or managing unique IDs.
- State management: Re-rendering components when state changes becomes messy in Backbone fairly quickly. That mess is why Angular 1 gained popularity. React simplifies this further by enforcing a one-directional state flow.
- Efficient DOM updates: Even if you implement composition and state management ad hoc, you still must update the DOM efficiently to avoid layout thrashing and related issues. React isn’t immune, but these problems are typically easier to handle.
- Other features: Implementing useful capabilities from scratch, like lazy loading parts of components (for example, suspense) or building hybrid apps with server-side rendering, requires significant work.
I'll argue that nowadays, if you want to use vanilla JS with templating support, lit-html (not the full framework, just the template part) is a much better choice than Backbone.
The example is also unrepresentative of anything meaningful. TodoMVC[0] is the classic point of comparison, and the Backbone version is a nightmare to grok compared to React[2].
Who wants to maintain this nightmare? https://github.com/tastejs/todomvc/blob/gh-pages/examples/ba...
Devs love to invoke Chesterton's fence but somehow forget about it when looking back on "the good old days."
What's worse, there were never good old days for frontend. It always sucked, and now it still sucks--just far less.
[0]: https://todomvc.com/
[1]: https://github.com/tastejs/todomvc/tree/gh-pages/examples/ba...
[2]: https://github.com/tastejs/todomvc/tree/gh-pages/examples/re...
That's all true, but I think the article's point still stands: React trades one set of compromises for another, and regardless of the tool used, software engineers using that tool have to do a lot of lifting to get the tool to work. It's not a question of whether react is better than backbone or vise versa, it's a question of whether we software engineers, as a group, are emphasizing the correct compromises, and what takeaways we can make from examining the compromises of today's popular tools.
I definitely do a lot less lifting with React than with jquery or backbone; like OP I also used all three (and others) in production, and my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air. In particular, counter point to the article, i loved that i could do something relatively complex, relatively easily, but still pop open dev tools and understand what was happening. I think tis great new libraries and concepts are sprouting but imo looking back wont help; browser javascript has come a LONG way obviating a large chunk of the reason we were all using jquery in the first place. Basic CRUD does fine with server side rendering, and is easier to test and maintain. Using that until it hurts is a solid strategy for avoiding react if thats ones goals.
The reality is stateful UI is complex on its own. Then JS tooling is complex (byo typescript and std lib). Then UI is something everyone sees so the whole company has opinions about how it should look. Mush it all together and FE development is rough. React is a punching bag because its been dominant so long. Id welcome the next phase when it arrives. But building toy apps with aged technology imo wont bring to light any unturned stones. Id recommend researching the plethora of real code and discussions that have beaten this horse to death on the open internet instead.
> my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air.
This was exactly how I felt. I building a Backbone app around the time React was released. It was only around 2600 lines of JS at the time but event handling and state management already felt like a tangled mess.
Porting it to React was a huge improvement even at that scale and really paid off over the next 5 years of development.
The point would me much better served if the article compared react from 2014 to react today.
As others have noted working with react after having worked with backbone, jQuery and ember felt like a breath of fresh air.
It felt that was we were doing was same again, and I would argue understandable. 11ish years later cruft has pilled own to dev experience detriment.
Which is the case for every library ever written
The job is to deliver complex software with ever changing requirements with a fungible team of engineers.
I'd say React is doing swimmingly at that job description.
For small, artisanal projects, there are lots of other choices and priorities.
I'm merely reiterating the blog's thesis.
Agreed. You want to run htmx at a company where the business requirements change every month? Good luck but you’re going to end up rewriting it and have a much harder time hiring.
There's a world of options away from React today that have those features. We can't pretend only React has them.
Agree, but the article was about comparing React and Backbone.
There are a gazillion of options that resolve the same problems: Vue, Svelte, Solid, Lit, etc.
Backbone was born as better code organization on top of jQuery and CoffeeScript. It never attempted to solve these issues.
I think Backbone was a bit before Coffeescript.
Haha, coffeescript was so hot for a minute
Both (Backbone and CoffeeScript) were created by Jeremy Ashkenas.
He had a very prolific year.
The raw jquery version looks better to me: https://justpaste.it/3pz1n
There are essentially infinitely many JS frameworks. You’ll have to recommend one or two to be taken seriously.
Vue.js is better react without hooks bullshit and with actual reactivity. Very nice, stable and mature.
Even the jquery version looks better: https://justpaste.it/3pz1n
But to keep in the good graces of our thought leader overlords, let's start solid or svelte.
> 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 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.
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.
Look, I wrote one of the only published books on Backbone, and it will always have a special place in my heart, but ... the OP has no idea what he is talking about.
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.
I remember watching one of the first React demonstrations/talks, and the biggest selling point was literally "You have a web page with various elements, and some of them needs to keep in sync, at Facebook we have chat messages and notifications, and they need to be in sync regardless of where you are, even on the same page, how do you solve that?" and then outlined how having one place for the state to live solves that issue without resorting to two-way data-bindings, instead data only flows in one direction.
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.
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.
And now everyone has phantom unreads again because it is cyclical and a different team is in charge of every other div
Everything was so hard. Everything! Backbone was kinda fun to write though, I'll admit. But not fun at scale to manage.
You just need 2 components with bidirectional binding to enter a world of hurt.
As you say many people do not understand how important, vital and bizarrely _non-obvious_ uni directional data flow was.
Author here.
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.
Yes, applying compositional patterns and one-way data flow is most appropriate for all apps, independent of scale. Why? Because developer A (author of app x) leaves company. Developer B gets hired. Developer B is onboarded in an afternoon because things can be understood at a glance thanks to functional patterns and one-way data flow.
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.
Those problems of react are only react's problems. Other js framework like vue/svelte/solid do not suffer from them.
You can use other frameworks for the other 1% of apps
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.
At one point I also moved from Angular to React, after moving from Backbone to Angular, and from "just" jQuery + jQuery UI to Backbone. After moving to React, I haven't found the need to move to something else, most of the alternatives are marginal improvements, while the difference before and after React is pretty drastic.
> 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?
You're right about that, but that wasn't common practice at the time. We learned about side-effects from Elm and Flux.
The native DOM doesn’t have an idea of “data flow”, it’s just a big tree that you can modify in whatever way you see fit through its imperative API. For example you could add an event handler to a child node which directly modifies one of its ancestor nodes. With React, your “nodes” in the tree are functions. The child node has no idea about what its ancestors are, it only knows what it is passed as arguments (i.e. “props”). The only way implement a similar thing would be to raise the state/event handling code to the ancestor node, and passing relevant information down as props, thus giving the unidirectional data flow. Of course, if you really needed to, you could drop back down to the native DOM API, with React’s useRef and useEffect hooks, but the default behavior is this unidirectional data flow through function composition.
> Didn't they call it Flux rather than Flow?
Ah, you may be right. It's been a long time.
Flow was a type checker (used to be Typescript vs. Flow debates early on before Typescript ended up with more support), Flux was the unidirectional data flow architecture.
There is no notion of components in the DOM (or at least there wasn’t, until after React), so there’s no sense of data flow.
There is a DOM tree, but parents don’t pass data into or receive events from children.
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.
From what you're saying, it sounds like components in this framework (React?) are not simple at all. A major hurdle in evolving a program is capturing and maintaining simplicity. The proof of whether something is simple lies in its composability, readability, and so on. If someone claims to have found a method of writing simple components, do not believe them if the simplicity is not evident. A truly simple solution would not be so burdened, and a somewhat simpler solution would be less burdened. Of course, simple still doesn't mean easy, because the Fast Fourier Transform may be simple, but I can't teach it to a 5 year old (or anyone, really).
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.
You are mixing your terms. Complexity is another word for many. As such it is measurable objectively. The opposite, simplicity, means fewer.
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.
I did say that simple doesn't mean easy. I don't know how to judge whether something is many or few without a fixed norm, nor how to measure it without reference to the environment it exists within. Simplicity does not mean having so little to the point of unease.
"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/
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.
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
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.
React came to be because folks at Facabook couldn't get the label displaying unread notifications always to display correct value. This seems like ridiculously straightforward problem easily solved. Yet still many websites and applications today struggle with that.
I'm getting downvoted into oblivion but you can hear it from horse's mouth:
https://youtu.be/nYkdrAPrdcw?t=757
To be precise, React was the first (afaik) to apply that to web UI, but definitely not the first to apply that to UI in general.
The basic idea of a unidirectional loop is how video games were built for years before React.
>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 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.
You can, but it's harder, React will at least nudge you away from doing that.
> 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...
Maybe but it sounds like bad excuses.
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.
1000 component should be trivial for a framework in 2025 without virtualization.
Hmmh...
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...
That's because a webpage should render properly on __all__ browsers.
You don't have this problem with UI libraries because all users will run the same library.
?
1,000 is a lot, but not uncommon for a CRUD app. Especially when you start with a small one and the scope creeps. Users want one more feature, and one more field. Then it's time to replace some other CRUD app and you've already got this one going ...
> If have a 40X25 table on your page that's editable, that's your 1,000 components right there.
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.
Also can we stop pretending React is any more "complex" than any other rendering library. You can't get much simpler than () => <div>Hello, World</div>
What makes React complex is that your simple example pulls in 100KB of code and entire layers like the virtual DOM which increase the memory and CPU requirements while adding significant new concepts a developer has to learn to be productive.
That’s not to say that there aren’t benefits from that but it’s definitely extra complexity compared to using web standards.
A single picture is going to be more than 100kb.
Meanwhile, there simply aren’t web standards that match React’s capabilities.
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.
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.
Author here.
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.
> They do the same thing. They're roughly the same length
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.
> […] the backbone code has raw HTML strings. These are opaque for code editors and not type safe.
Try using a proper IDE, then, which can handle embedded HTML just fine.
Did you work on any big backbone apps professionally? We had a huge one at Airbnb where after a certain scale any change by anyone - from new grad to expert - could get stuck in 2 days of debugging pure incidental complexity. Change some ui dom structure? Oops you broke someone’s selector and their event won’t fire anymore. Send an update at the wrong time? Render loop.
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.
React (and Tailwind for that matter) are great for hiring and getting hired. The chances of someone screwing it up or being lost in their first week/month when parachute into a project are pretty low.
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.
Took the words out of mouth. Every thread about React people come piling in about how overly complex it is.
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.
Is it arrogance or is it experience combined with a different perspective? One developer may love React because of the component ecosystem and talent pool, and another developer may dislike it because they're writing custom HTML/CSS anyways and React requires them to write way more JS than their preferred approach. Would I ever choose backbone? No. But many developers may be surprised by how little vanilla JS that it takes to build modern web apps. More than ever the tradeoffs of different frontend stacks need to be evaluated on a project-by-project basis.
OTOH we are taking about the web, here. A domain notoriously defined by technical debt, the "when all you have is a hammer" mindset, NIH, and resume-driven development...
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.
There is some good food for thought here.
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.
100% agreed. If you’re making Gmail the extra bulk of React is an afterthought in the context of a giant web app. But when you’re building a mostly static marketing site and don’t consider what’s going to get the thing to load as quickly as possible you’re not prioritising the right things, IMO.
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
> 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.
If you're using my web app (I wouldn't have used React if it wasn't an application anyway, right?), you're very likely a returning visitor. Even if your first page load after signin in is a drag because you're on the subway and for some reason 100KB take five seconds—you're probably coming back anyway, because my app warrants recurring usage (and the industry heavily optimises towards that, but that's a different story).
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?
That 10% missing are event normalization and event bubbling (preact bubble through DOM, react follows vDOM). Choose yourself what you need, but 100% compat with 3rd party libs is why I stick with react over preact.
There is, I think, a sort of innocent arrogance that comes with people who boldly claim that eating McDonald’s is straight up bad or an obvious step down from “real food.”
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.
> ... 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.
The Blub Paradox is real, and you'll see it everywhere.
There should be a name for the fallacy: "You don't need React to do <simple thing> 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.
> 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.
Seems like your example isn't equivalent to op's because using multiple frameworks increases complexity while picking a different car to drive to local store doesn't.
Your comparison doesn't make any sense because React is just fine for small apps. You're yelling at someone over using their car instead of roller skates to get groceries.
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 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.
A little nostalgic for me, I wrote a bunch of backbone tutorials back in the day.
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)
Marionette took away much of the Backbone boilerplate, though.
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 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."
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.
They had them from day one.
Class component:
Functional component: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.
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:
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.
useState is the built-in way to manage state in React today. There were also similar mechanisms in class components before hooks came along. This is pretty integral to how React works.
People do add state managers to store state outside the component tree, but a lot of components don't need that.
I moved our team from Backbone to Angular almost 6 years ago. I treasured BB on the fact that the entire source code can be read and understood by a junior developer, which made it appealing to me from an adoption perspective in our org, because there was no “magic” to it and a developer inherently understands and accepts that BB solves a real problem in a direct way. Having an army of jQuery devs who still wrote their own XmlHttpRequest functions and handled the inverted IE event bubbling by hand, I needed to ease them into thinking about front-ends as applications.
But my sensibilities as a software developer led me to adopt TypeScript and a kitchen-sink framework as a more stringent way of composing pages rather than just having a Wild West of filling patterns around what BB didn’t offer out of the box. After doing side-by-side comparisons Angular seemed like the most “similar” to what BB looks like day-to-day. I don’t have anything against React/Vue they’re fine.
We are on NG20 now and it’s looking good. I don’t miss BB, we still have some old pages that use it but overall I am not going to get caught up on this code golf stuff. Eventually when browsers catch up and offer out of the box solutions maybe that will be a point where we can go back to implementing things in a simple more native way.
This illustrates greatly why React got so popular.
If you look at the React code, it's 99% "just" JavaScript and HTML. The only proprietary function is `useState`, and even the people who have never touched React probably understand what `useState` does in this code without having to open the docs.
Also, in the Backbone code, half of the application relies on the string selector `.space-y-2`. So if someone in your team changes this class (or add it on another element), and forgets to ctrl+F `space-y-2` and change the string everywhere else, half of the application is broken. Also the layout/style for the checks list is repeated twice (in `render` and `updatePassword`), so if someone forgets to change both, the UI will be inconsistent once the user enters their password. And this a 50 LOC app… imagine now the same problems in a 10k+ LOC app. Maintenance hell.
I don't understand how the author wrote those two examples, didn't see the problems with the Backbone version and conclude there is no differences between both frameworks. React solved the problems present in the Backbone version.
because they barely wrote the article, they just asked Claude to write a blog post
> 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.
You are ALWAYS programming in abstractions. The raw JS code is JIT'd into machine code, for example, which most wouldn't know how to read/debug. The JS functions called are built in the browser and are trusted to function properly.
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)
> These aren't edge cases. They're normal problems you hit building moderately complex apps
These aren’t real articles. They’re slopg diatribes generated by people who can’t even be bothered to communicate a thought.
I feel annoying for being this guy, but i think someone should point out the fact that it’s barely written by a human being. What’s the point in engaging with the point the “author” is trying to make when the author is Claude?
I can't help but notice your comment doesn't actually say anything of substance, either.
I've never used Backbone, so I can't speak to its ergonomics, but I've used React (a bit back in 2015, and now again this year I've been updating my knowledge and re-learning it), and absolutely agree with the author's frustrations with its "magic".
I'm working on both a backend (in Rust) and a frontend (Typescript, React). The backend makes sense; the code I write does what I expect it to, and there's no magic. The frontend... oh boy. I constantly run into infinite-loop re-renders, input elements that won't update or randomly lose state, etc. I ask Claude Code to help me fix it, and it ends up doing a bunch of the stuff mentioned in the article: adding useCallback, useMemo, tweaking dependency lists, restructuring things in useEffect, adding state variables, etc.
Fortunately I can read the changes and understand what Claude is doing and why, but all of these things feel like huge holes in the abstraction. They're arcane workarounds for problems that React itself creates. And despite learning via Claude's fixes, I still keep making similar mistakes, a phenomenon I've never encountered with any other framework or library I've ever used before.
Having said that, I'll keep using React: it has a huge community around it, answers to problems aren't hard to find, and Claude Code seems to be good at working with it when I screw up and can't be arsed to poke at it until it works. This unfortunately feels a lot like the old saying, "nobody gets fired for buying IBM", but... it is what it is.
I've come to the opinion that for the vast majority of apps I've built, it could all be built using HTML + CSS (all built server side). I can sprinkle in little bits of interactivity using something like HTMX. And I'll have a website that is very easy to optimise, has phenomenal backwards compatibility, and gets rid of a whole class of issues associated with SPAs.
I often regret in my career not pushing back more on "requirements" that ended up requiring a more complicated app, whereas the customer would have been happier with a simpler solution.
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.
Interestingly, this is the case in Chrome, but in Firefox both React and Backbone exhibit the same behaviour.
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.
Who says which behavior is the correct one?
Seems more like personal preference.
The one that acts the same as the rest of the system. React isn't replacing the input element, so you get native behavior by default.
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.
It feels to me that this specific toy example would be even simpler in vanilla JS. A comparison with a serious, large SPA would be more fair and more informative for comparing frameworks.
If doesn't even use a Backbone model, the main thing that framework was known for. IIRC that's even where the name came from - it was designed to be the core of the site's functionality, the models acting as a bridge between the frontend and backend instead of having to make ajax requests and handle responses manually.
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, useEffect, etc.
> Lots of people don't even know how JavaScript works despite using it every day.
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.
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
most web pages are about to be HTML/JS/CSS generated by LLMs directly for users. Truth is, pre-LLM web frameworks were designed for two things: save developer keystrokes and delay the spaghettification of the codebase. We just automated keystrokes, so that's largely irrelevant now. Users don't read code, so spaghettification is also a non-issue, as long as the framework defines clear containers for spaghettis, and provide clear ways to fork the spaghetti or start over when the user is frustrated with some bug. There's no framework designed with these requirements in mind, but I am working on one.
> spaghettification is also a non-issue, as long as the framework defines clear containers for spaghettis
Sorry, but I disagree strongly with this. When there is, inevitably, a bug that the LLM can't fix, someone's going to have to read all that spaghetti, and they'll curse whoever put it there. "clear containers for spaghetti" is a pipe dream, all abstractions leak, and the bug may very well be in the spaghetti. "Just start over" is unrealistic for large, complex apps.
Of course, if you really have a solution for this, that would be incredible.
I'm ready for all the "what about x" comments, because I'm going to check them all. I'm choosing React over anything else right now because of how well my DevEx has been.
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
> 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 actually kind of funny how React devs quite literally don't know how HTML or JavaScript actually works (let alone HTTP or TCP/IP). React is an absolute trash-heap of abstraction that just reinforces its dominance because of popularity, similar to Java in the early-mid 2000s.
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.
And the LLMs are better at React than other frameworks. You need less React devs now than other frameworks. And with greenfield project with the compiler, it seems like an easy path. We don't use React, and I would not choose to do so, but LLMs + Compiler make it a great default for shops starting new apps.
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.
???
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.
> "react's complexity isn't worth saving 5 lines of code" which people would agree with.
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.
Yeah. I don't follow react closely, but I do know Vue.js is still in very active development and releasing new features because of all the real use cases/bug fixes. Some of the use cases or issues didn't exist back in 2010 (e.g. interoperability with custom elements). "Look at how little progress we've made" only reveals author's ignorance instead of saying anything meaningful or true.
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.
It’s just slop, not worth engaging with this article
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.
> The main thing to know about Backbone is it’s not intended to be a fully fledged framework like React.
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).
For smaller projects I was very productive with Backbone + Backbone Stickit. With react the earliest projects I tried it with never really had satisfactory standardized data sourcing/binding. Now I've mostly been using the tanstack/react query library for the last few years and it's productive enough. I think I'll be more productive if/when I switch to something like svelte or live view, though. Modern react apps feel like building an app twice to build it once IMO.
I think some of the React vs Backbone debate misses how web projects often evolve in unpredictable ways. Most 'tiny' apps pick up complexity as features are added. So it's useful to build on a platform that scales smoothly and encourages best practices and grows with you.
React has become that platform that it is because teams can reliably ship, maintain the codebase and onboard new folks. Preference for 'right tool for the job' is good but real life means sticking to tools that won't bite you a year later.
I was part of a team building a complex web gui. We started the project in 2015. The GUI had a _lot_ of cascading business logic, an editable high-density grid, all kinds of fun.
In our tools evaluation, React just had too much overhead. changes would trigger a huge cascade of events that killed responsiveness. We went with Backbone and it served us very well.
I know React is king, but so far I have managed to live without it.
As long as React was the "View" and was marketed as such, being able to express declaratively what ui should render given a combination of state+props, it was great. Then... i don't now what happened with hooks sprecifically, but i still have hard time figuring out why they were needed other than making everything looks "more functional" I often read something like algebraic data types, I was astonished. React.createClass was all we needed, and some optimizations from there was possible. Today they market themselves as "don't use React without a framework" it's stupid
I think the broader point being made here isn’t “React is bad” it’s how far we haven’t come in all this time. The user experience on the web is still sorely lacking.
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?
They exist and being developed but the use case is so small when their users have internet.
I don’t really understand the argument either: local-first and offline modes are non trivial to get right, it’s not automatic even with a framework.
Every product I’ve built is able to make a bunch of assumptions: client is working on behalf of a company, on their desktop computer, with good internet. It’s often even more heterogeneous than that: we can often assume MacBook and chrome.
This is the primary use case for massive react web apps: apps behind a login for b2b
Why would anyone care about offline first in that scenario?
> Every product I’ve built is able to make a bunch of assumptions: client is working on behalf of a company, on their desktop computer, with good internet.
That’s your experience, it is not mine. A great many people are making consumer facing web sites that experience majority mobile traffic. It’s not even rare!
I don’t think this comparison is correct. You concluded that not much has changed in 15 years, but you are not comparing 15-year-old idiomatic Backbone code with modern React. Instead, you are comparing modern Backbone code with modern React.
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.
This is how Backbone looked back in the day. Not that I agree with him, but there's nothing new to this, it's essentially a basic View wrapper around a jQuery dom manipulator.
The example is a fun one-page TodoMVC alternative. Here’s Crank.js:
I wish it used an HTML form instead of divs and Tailwind, but implementation per framework shouldn’t be more than 100 lines.https://github.com/bikeshaving/crank/blob/main/examples/pass...
What's "for ({} of this)" about?
Weird to me when people describe React as overly complex. The fundamentals are very easy to grok. You don't need a the more complex APIs to get going.
I've worked around a medium-sized and storied backbone project that (for good reason) didn't have time to "get things right" and hoooooo boy can it get complex and spaghetti.[1]
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...
In terms of simplicity Mithril is pretty great. Personally don't love the hyperscript syntax but it can be used with jsx.
Also Preact but the mental model is closer to React.
And Vue can be used from a script tag without a build step too.
In fairness at the local level displayed here just vanilla JS is damn easy to implement. But when you have a larger app with various interactions that can happen at different levels of the tree, the react abstraction will be appreciated. I say this as someone who was around to see how we dealt with this in backbone and then switched to react for dealing with the same
The answer to the final question is Elm.
Shame the project governance has stalled its adoption.
Yeah no, we didn’t invent things like react to write a password input, we did because as soon as you have more than one event trying to edit one part of the page you’re in hell with backbone. So you add marionette, and a store object, and then there is magic bindings with performance problems or thrashing, and you debug that, and then you… That’s how we got here. This example is about 1/4th the minimum size needed to study the issue. You don't need hundreds of components, you need a single piece of state that is updated three ways to start seeing the pain.
This is tangential, but does anyone know more about what happened to Redwood JS? This post got me thinking about it, I went to search for it, and it seem to have taken a full 180
React scales. If you can predict the future, if you know your app’s complexity won’t grow, you can choose one of the “simpler” alternatives (and go against the ecosystem trend).
> 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.
> you're trading explicit simplicity for abstraction complexity.
Which is literally the entire reason any framework or abstraction is chosen (most of the time IMO).
> React looks cleaner. It reads better at first glance.
I've struggled to get past this. I don't find it easier to read, and the js and html mixed together is just icky. But I think this is an uncommon opinion, and that surprises me.
React/JSX reads better than other framework templating because
If you know vanilla JS, JSX is a low overhead abstraction.There is that something now... vanilla js (written seriously) and web components.
I'm never going back to heavy weight spa frameworks. The hidden costs are way too high.
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.
Interesting. Datastar, the front/back end framework, also has the concept of signals, allowing the backend to update them directly via HTTP responses or SSE events.
https://data-star.dev/guide/reactive_signals
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.
Author here.
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?"
> 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?
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.
Does react still mess up the DOM and, for example, using Google Translate?
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.
> Does react still mess up the DOM and, for example, using Google Translate?
One might argue that it is Google Translate that messes up the DOM for react :-)
Using something like react-router or TanStack router makes building an entire site a piece of cake.
Would've been helpful if they tried to make the code as close as possible, e.g. use the same struct (and var name) for the password requirements.
As somebody who picked up Backbone after Sammy and other earlier attempts, when React came along and took the world by storm, I more or less decided to nope out of JavaScript development and go back to Rails.
Every generation needs to learn the same lessons in their own time, but people often asked me why I’d go from speaking at national JavaScript conferences to essentially disappearing. The answer was the overwhelming popularity React and Webpack. Life is short and I don’t have time for this shit.
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.
in 2025 React is much much better then Backbone
Backbone still looks ugly
> For massive apps with 1,000 components on the same page, maybe React's complexity is justified.
React is very simple, shockingly so.
So simple that Preact implements essentially the entire API in 5kb.
That Backbone song, tho.
React has no song.
Look for Imba (imba.io) which is being ignored for years. Predecessor of React with features of React and no flaws of React. Works great with just devtools - for debugging.
It's great. I wish they released a JS/TS version though.
A custom language that basically depends on a single guy is a hard sell.
For something this simple that doesn't need to grow or interact with the rest of the system why would you need Backbone or React? And why would you expect any version to be shorter as it's mostly just the HTML and the data.
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.
> For massive apps with 1,000 components on the same page, maybe React's complexity is justified.
Something is wrong if you need a 1000 components. Not everything has to be exposed as a component. Build something in lower level library and expose it as a react component. There's a real reason something like ag-grid has such a dedicated following.
The reality is Reacts abstraction has always been thin, which begs the question is it truly valuable. It's basically an application pattern masquerading as an abstraction. In 2025, there's no reason any thoughtful organization shouldn't investigate alternatives.
It's like comparing Fortran to Rust.
We left Backbone for Vue in 2018, due to its simplicity and ease of component manufacturing. I'm surprised to learn that Backbone still exists. Maybe I should revisit it.
I remembered why we left, I hate handle 'this' in JavaScript :)
Components don't live in a vacuum. Which is why comparing one-offs like this make little practical sense in the long run.
I totally agree - the example they give doesn't really need react OR backbone. You could just as easily show vanilla js as the 3rd example and wonder why you would ever even need a framework.
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.
> 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
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.
Angular v1 was absolutely the game-changer for sane UI patterns. Although it could choke on large datasets and models were iffy, it allowed us to worry less about the framework and more about the work at hand.
Well said and I totally agree.
is there a better model???? Yeah its called svelte
I've used Svelte a bit and like it. Not really a suitable replacement for React in most of my work projects yet, though.
10 years back, every month there would be a new JS framework, backbone, ember, angular 1, 2, vue etc.
With React, I would argue that UI got standardized. At this point the ecosystem is so active and robust that choosing anything else has to be because you have hit a edge case not solved by react, next etc.,