[diegof79]

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.

[fny]

The example is also unrepresentative of anything meaningful. TodoMVC[0] is the classic point of comparison, and the Backbone version is a nightmare to grok compared to React[2].

Who wants to maintain this nightmare? https://github.com/tastejs/todomvc/blob/gh-pages/examples/ba...

Devs love to invoke Chesterton's fence but somehow forget about it when looking back on "the good old days."

What's worse, there were never good old days for frontend. It always sucked, and now it still sucks--just far less.

[0]: https://todomvc.com/

[1]: https://github.com/tastejs/todomvc/tree/gh-pages/examples/ba...

[2]: https://github.com/tastejs/todomvc/tree/gh-pages/examples/re...

[ricardobeat]

What you see as a nightmare is really straight-forward code from another perspective. It just looks very unfamiliar. Yes, it feels raw, it is verbose, it's imperative and not declarative, but the entire app lifecycle is there to see.

You can easily tell what every function is doing, including the library ones, and magical behaviour is kept to a minimum. It could be easily maintained 20 years from now, as you have a very thin layer over DOM manipulation and Backbone itself can be grasped and maintained by a single human.

One could argue that React leads to better development velocity, but from experience I can say that reality is not that simple. The initial speed boost quickly fades, instead a huge amount of time starts being allotted to maintenance, updates, workarounds, architecture and tooling as complexity compounds.

[ysavir]

That's all true, but I think the article's point still stands: React trades one set of compromises for another, and regardless of the tool used, software engineers using that tool have to do a lot of lifting to get the tool to work. It's not a question of whether react is better than backbone or vise versa, it's a question of whether we software engineers, as a group, are emphasizing the correct compromises, and what takeaways we can make from examining the compromises of today's popular tools.

[cloverich]

I definitely do a lot less lifting with React than with jquery or backbone; like OP I also used all three (and others) in production, and my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air. In particular, counter point to the article, i loved that i could do something relatively complex, relatively easily, but still pop open dev tools and understand what was happening. I think tis great new libraries and concepts are sprouting but imo looking back wont help; browser javascript has come a LONG way obviating a large chunk of the reason we were all using jquery in the first place. Basic CRUD does fine with server side rendering, and is easier to test and maintain. Using that until it hurts is a solid strategy for avoiding react if thats ones goals.

The reality is stateful UI is complex on its own. Then JS tooling is complex (byo typescript and std lib). Then UI is something everyone sees so the whole company has opinions about how it should look. Mush it all together and FE development is rough. React is a punching bag because its been dominant so long. Id welcome the next phase when it arrives. But building toy apps with aged technology imo wont bring to light any unturned stones. Id recommend researching the plethora of real code and discussions that have beaten this horse to death on the open internet instead.

[throwawayffffas]

The point would me much better served if the article compared react from 2014 to react today.

As others have noted working with react after having worked with backbone, jQuery and ember felt like a breath of fresh air.

It felt that was we were doing was same again, and I would argue understandable. 11ish years later cruft has pilled own to dev experience detriment.

[echelon]

The job is to deliver complex software with ever changing requirements with a fungible team of engineers.

I'd say React is doing swimmingly at that job description.

For small, artisanal projects, there are lots of other choices and priorities.

I'm merely reiterating the blog's thesis.

[flufluflufluffy]

Which is the case for every library ever written

[smrtinsert]

There's a world of options away from React today that have those features. We can't pretend only React has them.

[diegof79]

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.

[ironmagma]

There are essentially infinitely many JS frameworks. You’ll have to recommend one or two to be taken seriously.