16 ms·

React vs. Backbone in 2025

• t0rg 1y ago
  React has no song.
• t0rg 1y ago
  That Backbone song, tho.
• mexicocitinluez 1y ago
  Components don't live in a vacuum. Which is why comparing one-offs like this make little practical sense in the long run.
  • justbees 1y ago
    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.
    • mexicocitinluez 1y ago
      Well said and I totally agree.
    • dbattaglia 1y ago
      > 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.
      • itqwertz 1y ago
        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.
• timcobb 1y ago
  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.
  • thedelanyo 1y ago
    Does React have built-in state management?
    • sothatsit 1y ago
      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.
    • maxloh 1y ago
      They had them from day one. Class component: class Counter extends Component { state = { age: 42 }; handleAgeChange = () => { this.setState({ age: this.state.age + 1 }); }; render() { return ( <> <button onClick={this.handleAgeChange}>Increment age</button> <p>You are {this.state.age}.</p> </> ); } } Functional component: function Counter() { const [age, setAge] = useState(42); const handleAgeChange = () => setAge(age + 1); return ( <> <button onClick={handleAgeChange}>Increment age</button> <p>You are {age}.</p> </> ); }
      • ascagnel_ 1y ago
        You can actually further simplify the functional component by using setState's callback form. You don't always need to do this, but it makes setting state from within a useEffect much safer in that it won't need the current state value in its dependency array. const handleAgeChange = setAge((prevAge) => prevAge + 1);
• Kwpolska 1y ago
  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.
  • Izkata 1y ago
    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.
• almost 1y ago
  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.
  • deleted 1y ago
    [deleted]
• ramon156 1y ago
  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
  • huflungdung 1y ago
    [dead]
  • jgalt212 1y ago
    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.
  • azangru 1y ago
    > 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.
    • dvt 1y ago
      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.
• lelandfe 1y ago
  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)
  • croes 1y ago
    Who says which behavior is the correct one? Seems more like personal preference.
    • Izkata 1y ago
      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.
  • deleted 1y ago
    [deleted]
  • saxenaabhi 1y ago
    wait, why is undoing by word better? I like backbone's approach!
    • lelandfe 1y ago
      https://jsfiddle.net/pn6bzyhk/1/ 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 https://imgur.com/a/jKl5exU (Not your fault: most people misremember this...)
      • warpspin 1y ago
        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.
• preommr 1y ago
  ??? 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.
  • rs186 1y ago
    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.
  • gravity13 1y ago
    > "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.
• hamandcheese 1y ago
  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.
  • stevepotter 1y ago
    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
  • mexicocitinluez 1y ago
    > 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.
• tuhgdetzhh 1y ago
  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.
  • gravity13 1y ago
    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.
• madmaniak 1y ago
  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.
  • pier25 1y ago
    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.
    • madmaniak 1y ago
      Yes it's TS and types compatible. What about Rails or Redis or Linux? The most brilliant projects I know come from one person. Everything is hard to sell if you don't have corporate money stream for marketing :) No?
      • pier25 1y ago
        > What about Rails or Redis or Linux? Linux and Redis have funding and millions of users. So much depends on these projects. Rails is less popular these days but still a project with a long history, financial backing, and a huge ecosystem. Imba has some brilliant ideas and Sindre is extremely smart... but IMO the decision to go with a custom language has hurt the project more than it has helped. It won't work with any of the tooling around JS/TS. Development is also extremely slow. More than 4 years after announcing v2 here on HN[1], it still hasn't been released. The reality is that almost nobody is using Imba and it currently sits at about 2000 weekly downloads on NPM with no growth. Even Mithril which is also super niche has more downloads than Imba [2]. [1] https://news.ycombinator.com/item?id=28196158 https://news.ycombinator.com/item?id=28196158 [2] https://npmtrends.com/imba-vs-mithril https://npmtrends.com/imba-vs-mithril
• comrade1234 1y ago
  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.
  • azangru 1y ago
    > 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 :-)
  • DangitBobby 1y ago
    Using something like react-router or TanStack router makes building an entire site a piece of cake.
• dlisboa 1y ago
  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.
  • kaoD 1y ago
    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.
• picardo 1y ago
  > 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.
  • jgalt212 1y ago
    > 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.
    • amelius 1y ago
      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.
      • aatd86 1y ago
        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...
• nu11ptr 1y ago
  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)
• hmokiguess 1y ago
  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
• joduplessis 1y ago
  > 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).
• patcon 1y ago
  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-participation/js https://github.com/compdemocracy/polis/tree/edge/client-part...
  • deleted 1y ago
    [deleted]
• cj 1y ago
  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.
  • Izkata 1y ago
    > 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 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).
• ZvG_Bonjwa 1y ago
  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.
  • afavour 1y ago
    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.
    • rkomorn 1y ago
      > 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.
      • afavour 1y ago
        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.
• tonyhart7 1y ago
  is there a better model???? Yeah its called svelte
  • DangitBobby 1y ago
    I've used Svelte a bit and like it. Not really a suitable replacement for React in most of my work projects yet, though.
• zarzavat 1y ago
  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.
  • codingdave 1y ago
    > 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.
    • alcaide-mor 1y ago
      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.
      • albuic 1y ago
        Using multiple vehicles also increase maintenance. It totally makes sense to use the right tool. You might not want to learn how to use a screw driver instead of a hammer but both have their use.
    • DangitBobby 1y ago
      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.
• Jcampuzano2 1y ago
  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.
  • panphora 1y ago
    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?"
• thr0w 1y ago
  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.
• pier25 1y ago
  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.
• afavour 1y ago
  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?
  • qudat 1y ago
    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?
    • afavour 1y ago
      > 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!
  • nymanjon 1y ago
    I build most of my personal websites with service workers. No need for the framework, I just build it for the specific use case I have at the moment. Here's an offline-first soccer app: https://github.com/jon49/Soccer https://github.com/jon49/Soccer And here's an MPA that caches the pages and save the updates for later when you are back online. So, you can navigate around and see the old data even if you are offline: https://github.com/jon49/cash https://github.com/jon49/cash
• scotty79 1y ago
  It's like comparing Fortran to Rust.
• Vipsy 1y ago
  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.
• igtztorrero 1y ago
  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 :)
• _fat_santa 1y ago
  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.
• nop_slide 1y ago
  > 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://overreacted.io/a-complete-guide-to-useeffect/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a- 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.
• debarshri 1y ago
  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.,
• politelemon 1y ago
  > 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.
  • WiseWeasel 1y ago
    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.
• sksksk 1y ago
  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.
  • nymanjon 1y ago
    No need for HTMX, HTMZ can get you most of the way there if it is going from simple MPA to slightly more complicated. I used a variation of HTMZ to make a offline-first soccer app I use for myself. I thought I would need to use a front end for the match play page, but, nope, I used Morphdom with HTMZ and I was able to keep the simplicity of templating and a back end. [1]: https://github.com/jon49/htmz-be https://github.com/jon49/htmz-be [2]: https://github.com/jon49/Soccer https://github.com/jon49/Soccer
• marcelr 1y ago
  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.
  • kitd 1y ago
    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 https://data-star.dev/guide/reactive_signals
    • sudodevnull 1y ago
      Yep, we are BY FAR the fastest signal approach and built in. Datastar is just a set of tools to ture data-* attributes into fine grain reactive expressions. Everything else is a plugin.
• slmjkdbtl 1y ago
  > 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.
• talkingtab 1y ago
  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.
• inflames123 1y ago
  [dead]
• puskuruk 1y ago
  Backbone still looks ugly
• darepublic 1y ago
  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
• diegof79 1y ago
  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.
  • smrtinsert 1y ago
    There's a world of options away from React today that have those features. We can't pretend only React has them.
    • diegof79 1y ago
      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.
      • kdazzle 1y ago
        I think Backbone was a bit before Coffeescript. Haha, coffeescript was so hot for a minute
• ggregoire 1y ago
  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.
  • tefkah 1y ago
    because they barely wrote the article, they just asked Claude to write a blog post
• pyrale 1y ago
  The answer to the final question is Elm. Shame the project governance has stalled its adoption.
• iainctduncan 1y ago
  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.
• smrtinsert 1y ago
  > 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.
• mattnewton 1y ago
  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.
• xixixao 1y ago
  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).
• tefkah 1y ago
  > 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?
  • krona 1y ago
    I can't help but notice your comment doesn't actually say anything of substance, either.
• hollowturtle 1y ago
  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
• paulddraper 1y ago
  > 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.
• OldGreenYodaGPT 1y ago
  in 2025 React is much much better then Backbone
• samjones33 1y ago
  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.
• bikeshaving 1y ago
  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/password-strength.js https://github.com/bikeshaving/crank/blob/main/examples/pass...
  • wk_end 1y ago
    What's "for ({} of this)" about?
    • bikeshaving 1y ago
      Crank.js uses generator functions for stateful components, where you yield instead of returning, and the scope is preserved for the lifetime of the component. You could technically use `while (true)`, but `for (props of this)` is the idiomatic way to get new props. The `this` object is an iterable of the latest props, and if the component doesn’t have props, `for ({} of this)` is the idiomatic way to loop over props without needing another variable assignment.
• searls 1y ago
  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.
• Glyptodon 1y ago
  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.
• doradoblank 1y ago
  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.
• kelnos 1y ago
  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.
• uvaursi 1y ago
  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.
• ppqqrr 1y ago
  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.
  • pyridines 1y ago
    > 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.
    • ppqqrr 1y ago
      nothing lives forever. software comes into life out of necessity, develops complexities, eventually becomes incomprehensible, obsolete and dead. it’s a natural cycle that we should work into the user experience, instead of defining it as a failure state that we need to “solve for”.
• jaitaiwan 1y ago
  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://spine.github.io https://flightjs.github.io https://flightjs.github.io
• gloosx 1y ago
  >> 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.
• sudodevnull 1y ago
  Just Datastar and my new WC framework (which is 6kb). Was the shortest, valid HTML, no build step https://gist.github.com/delaneyj/8c55b6a9768a38c873750afdebde9105 https://gist.github.com/delaneyj/8c55b6a9768a38c873750afdebd... Backbone was a pain as you make more, React is a husk of its original intent. Both of these can be true while still having better modern alternatives
• JimmaDaRustla 1y ago
  Now show me SolidJS and Svelte