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.
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.
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.
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 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.
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.
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.
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.
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.
> 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.
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)
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
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?
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.
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.
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.
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 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?
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
69 comments
[ 3.4 ms ] story [ 67.9 ms ] threadBackbone 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.
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.
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
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 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.
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.
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 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 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.
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)
Which is literally the entire reason any framework or abstraction is chosen (most of the time IMO).
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...
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.
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.
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.
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.
Also Preact but the mental model is closer to React.
And Vue can be used from a script tag without a build step too.
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?
Here's an offline-first soccer app: 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