HN Reader

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.

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.

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.

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

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.

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)

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)

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.

>> events: {

>> 'input input': 'updatePassword'

>> },

So this is no mystery?.

There is an 'events' object which has 'input input' string mapped to 'updatePassword' string. Why there is "input" written twice? Why do you have to reference functions by their name inside of a string? What if you have 100 event handlers and you make a typo in one of them? How will compiler understand there is a bug if you don't reference an actual function?

This whole "let's map string to string in this obect to make HTML element in one place fire an actual function in the third place" way of doing things must be a hell to maintain, bug-prone and frustrating. Why on earth you shouldn't do it with Element.addEventListener('input'), Element.on('input') or at least Element.oninput = ...?

What is this.$el, this.$('').html anyway?

$(() => {}) - wow this is VERY verbosely telling DOM is ready

I don't know, React really does look like a huge progress when directly compared to this hacky-looking backbone framework.

UI = fn(state), and it's beautiful. Yes, you need to understand side-effects and memoization, these are standard functional patterns, clearly described in the documentation. You need to understand the "stable identity" for the elements, because when recursing on the children of a DOM node, React just iterates over both lists of children at the same time and generates a mutation whenever there's a difference. There is an in-depth explanation for that in the documentation. There is nothing obscure or hard in React if you read the documentation once.

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.

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.

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.

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

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

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.

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 did a Ctrl+f of the thread and I'm sad no one mentioned my old favourites so I'll mention them...

https://spine.github.io https://flightjs.github.io

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

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

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

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

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

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.

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.

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

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.

Backbone still looks ugly

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.

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

in 2025 React is much much better then Backbone

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.

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

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.

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

That Backbone song, tho.

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?

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.

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.

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

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.

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

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

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.

The answer to the final question is Elm.

Shame the project governance has stalled its adoption.

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.

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.

Components don't live in a vacuum. Which is why comparing one-offs like this make little practical sense in the long run.

The example is a fun one-page TodoMVC alternative. Here’s Crank.js:

    // Adapted from https://backbonenotbad.hyperclay.com/
    // https://gist.github.com/panphora/8f4d620ae92e8b28dcb4f20152185749
    function* PasswordStrength() {
      const requirements = [
        {label: '8+ characters', check: (pwd) => pwd.length >= 8},
        {label: '12+ characters', check: (pwd) => pwd.length >= 12},
        {label: 'Lowercase letter', check: (pwd) => /[a-z]/.test(pwd)},
        {label: 'Uppercase letter', check: (pwd) => /[A-Z]/.test(pwd)},
        {label: 'Number', check: (pwd) => /\d/.test(pwd)},
        {label: 'Special character', check: (pwd) => /[^a-zA-Z0-9]/.test(pwd)},
      ];

      let password = '';

      for ({} of this) {
        yield (
          <div class="w-80 p-6 bg-white rounded-xl shadow-lg space-y-4">
            <input
              type="password"
              value={password}
              oninput={(e) => this.refresh(() => password = e.target.value)}
              placeholder="Enter password"
              class="w-full px-4 py-2 border rounded-lg focus:outline-none focus:ring-2"
            />
            <div class="space-y-2">
              {requirements.map((req, idx) => {
                const isMet = req.check(password);
                return (
                  <div key={idx} class="flex items-center gap-2">
                    <div class={`w-5 h-5 rounded-full flex items-center justify-center text-xs font-bold ${isMet ? 'bg-green-500 text-white' : 'bg-gray-200 text-gray-400'}`}>
                      {isMet ? '' : ''}
                    </div>
                    <span class={`text-sm ${isMet ? 'text-green-600 font-medium' : 'text-gray-500'}`}>
                      {req.label}
                    </span>
                  </div>
                );
              })}
            </div>
          </div>
        );
      }
    }

    renderer.render(<PasswordStrength />, document.body);

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

It's like comparing Fortran to Rust.

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

is there a better model???? Yeah its called svelte

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.

React has no song.