in 2025 React is much much better then Backbone
React vs. Backbone in 2025
181–190 of 245 posts
Re: React vs. Backbone in 2025
#182> 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 frustratio…
> 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.
> If have a 40X25 table on your page that's editable, that's your 1,000 components right there.
Why would you do it like that?! Just have a normal component for a table, and when the clicks on a cell, spawn (and teleport) an edit component over that cell.
Re: React vs. Backbone in 2025
#183Earlier quoted context omitted.
> They do the same thing. They're roughly the same length But they arent the same, the backbone code has raw HTML strings. These are opaque for code editors and not type safe. React code is using typed objects to construct the html (if you used typescript like is standard in 2025 for react projects). The backbone app is disconnected in the rendering flow. the space-y-2 selector is ambiguous and causes unnecessary sea…
> […] the backbone code has raw HTML strings. These are opaque for code editors and not type safe. Try using a proper IDE, then, which can handle embedded HTML just fine.
[deleted]
Re: React vs. Backbone in 2025
#184I 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.
Re: React vs. Backbone in 2025
#185Earlier quoted context omitted.
Agree, but the article was about comparing React and Backbone. There are a gazillion of options that resolve the same problems: Vue, Svelte, Solid, Lit, etc. Backbone was born as better code organization on top of jQuery and CoffeeScript. It never attempted to solve these issues.
I think Backbone was a bit before Coffeescript. Haha, coffeescript was so hot for a minute
Both (Backbone and CoffeeScript) were created by Jeremy Ashkenas.
He had a very prolific year.
Re: React vs. Backbone in 2025
#186The 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 (
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"
/>
{requirements.map((req, idx) => {
const isMet = req.check(password);
return (
{isMet ? '' : ''}
{req.label}
);
})}
);
}
}
renderer.render(, document.body);
https://github.com/bikeshaving/crank/blob/main/examples/pass...
Re: React vs. Backbone in 2025
#187I 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 th…
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?
Re: React vs. Backbone in 2025
#188As 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.
Re: React vs. Backbone in 2025
#189For 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.
Re: React vs. Backbone in 2025
#190Weird 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.