Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React vs. Backbone in 2025

backbonenotbad.hyperclay.com

Post reply on HN
Print view View original

211–220 of 245 posts

Re: React vs. Backbone in 2025

#211

Post by austin-cheney »

scotty79 wrote: post #204
scotty79 wrote: post #121

Earlier quoted context omitted.

React came to be because folks at Facabook couldn't get the label displaying unread notifications always to display correct value. This seems like ridiculously straightforward problem easily solved. Yet still many websites and applications today struggle with that.

I'm getting downvoted into oblivion but you can hear it from horse's mouth: https://youtu.be/nYkdrAPrdcw?t=757

I stopped watching the moment the speaker correlated imperative code to fragility. All code is inherently fragile. The only thing that makes code durable is not failing. Failure can be minimized by separating code into portable units that do nothing more than achieve a singular purpose.

Secondly, they kept talking about this creeping complexity in their code base of about 8 lines of code. 8 lines is still ridiculously tiny. I suspect their actual concern is that the code did multiple things like decrementing a number and modifying a state. I understand this was before TypeScript where execution can be planned against an interface, but I still would have created an object that stores all the relevant data they need to modify on each interaction.

Re: React vs. Backbone in 2025

#212

Post by theflyinghorse »

ZvG_Bonjwa wrote: post #58

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 subversiv…

Let's be brutally honest. Big part of choosing tech has to do with the fact that I want to be able to be paid. If react is popular and has some potential for earning me money, then react it is.

Re: React vs. Backbone in 2025

#213

Post by bdangubic »

theflyinghorse wrote: post #212
ZvG_Bonjwa wrote: post #58

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 subversiv…

Let's be brutally honest. Big part of choosing tech has to do with the fact that I want to be able to be paid. If react is popular and has some potential for earning me money, then react it is.

if you are the one that gets to pick you are already making bank and don’t need to make tech decisions based on that

Re: React vs. Backbone in 2025

#214

Post by aniforprez »

ricardobeat wrote: post #210
fny wrote: post #201

Earlier quoted context omitted.

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…

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 v…

I do not want to work with all the untyped strings and random class selectors. I'd say the code is easy enough to read but nigh on unmaintainable.

Re: React vs. Backbone in 2025

#216

Post by gloosx »

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

Re: React vs. Backbone in 2025

#217

Post by scotty79 »

austin-cheney wrote: post #211
scotty79 wrote: post #204

Earlier quoted context omitted.

I'm getting downvoted into oblivion but you can hear it from horse's mouth: https://youtu.be/nYkdrAPrdcw?t=757

I stopped watching the moment the speaker correlated imperative code to fragility. All code is inherently fragile. The only thing that makes code durable is not failing. Failure can be minimized by separating code into portable units that do nothing more than achieve a singular purpose. Secondly, they kept talking about this creeping complexity in their code base of about 8 lines of code. 8 lines is still ridiculousl…

Apparently you are smarter than the team that created the library that spontaneously taken over nearly entire field of front-end development. Good for you!

Re: React vs. Backbone in 2025

#218

Post by simantel »

diegof79 wrote: post #185
kdazzle wrote: post #157

Earlier quoted context omitted.

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.

Don't forget Underscore!

Re: React vs. Backbone in 2025

#219

Post by madmaniak »

pier25 wrote: post #79
madmaniak wrote: post #16

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.

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.

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?

Re: React vs. Backbone in 2025

#220

Post by austin-cheney »

scotty79 wrote: post #217
austin-cheney wrote: post #211

Earlier quoted context omitted.

I stopped watching the moment the speaker correlated imperative code to fragility. All code is inherently fragile. The only thing that makes code durable is not failing. Failure can be minimized by separating code into portable units that do nothing more than achieve a singular purpose. Secondly, they kept talking about this creeping complexity in their code base of about 8 lines of code. 8 lines is still ridiculousl…

Apparently you are smarter than the team that created the library that spontaneously taken over nearly entire field of front-end development. Good for you!

Probably. I have been doing this for a while.

Its like comparing your car to a Kia Soul as opposed to a Bugatti or McLaren. It not a comparison of what's awesome. Its a comparison against that thing in common use. It doesn't take much to be better than that.

Post reply on HN