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

221–230 of 245 posts

Re: React vs. Backbone in 2025

#221

Post by pier25 »

madmaniak wrote: post #219
pier25 wrote: post #79

Earlier quoted context omitted.

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?

> 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

[2] https://npmtrends.com/imba-vs-mithril

Re: React vs. Backbone in 2025

#222

Post by nchmy »

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…

So what you're saying is that people should be taking ozempic rather than just getting some self discipline and eating some salad?

Re: React vs. Backbone in 2025

#223

Post by nchmy »

hansonkd wrote: post #149
panphora wrote: post #127

Earlier quoted context omitted.

Author here. The "paleo influencer" comparison is interesting, but I think it actually works both ways here. Yes, there's a temptation to romanticize the past and dismiss modern tools. But there's an equally strong tendency to assume that newer, more popular, and more widely-adopted automatically means better. React didn't just win on pure technical merit. It has Facebook's marketing muscle behind it, it became a hir…

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

Just wait til you discover hypermedia, the actual language of the web...

Re: React vs. Backbone in 2025

#224

Post by nchmy »

AstroBen wrote: post #120
afavour wrote: post #61

Earlier quoted context omitted.

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…

Preact adds, among other things.. 1. Potential compatibility issues. Their preact/compat package doesn't cover 100% of cases (of course it doesn't, otherwise it'd just be React) 2. Risk. Will this thing be maintained long term? I mean sure a potential migration to React probably wouldn't be too painful but.. why? So, starting from "The average speed for 4G LTE is typically between 10 and 30 Mbps for downloads" Saving…

The average speed/connection is not 4G LTE.

And react usually is not just 100kb.

SSR html is vastly faster for all parties involved. So much so that all spa frameworks have introduced some sort of server rendering, astro is growing a lot, and things like htmx, datastar, hotwire etc are all getting a lot of fawning attention.

Re: React vs. Backbone in 2025

#225

Post by nchmy »

9dev wrote: post #175
afavour wrote: post #68

Earlier quoted context omitted.

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…

If you're using my web app (I wouldn't have used React if it wasn't an application anyway, right?), you're very likely a returning visitor. Even if your first page load after signin in is a drag because you're on the subway and for some reason 100KB take five seconds—you're probably coming back anyway, because my app warrants recurring usage (and the industry heavily optimises towards that, but that's a different sto…

If Html and browser APIs might be abandonned in a few years, We've got bigger issues to worry about than react vs backbone

Re: React vs. Backbone in 2025

#226

Post by nchmy »

littlecranky67 wrote: post #135
afavour wrote: post #68

Earlier quoted context omitted.

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…

That 10% missing are event normalization and event bubbling (preact bubble through DOM, react follows vDOM). Choose yourself what you need, but 100% compat with 3rd party libs is why I stick with react over preact.

The browser bubbles events natively...

https://developer.mozilla.org/en-US/docs/Learn_web_developme...

Re: React vs. Backbone in 2025

#227

Post by nchmy »

zarzavat wrote: post #62

There should be a name for the fallacy: "You don't need React to do 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), a…

Pray tell, what is it that only react can do that makes you "require" it?

Re: React vs. Backbone in 2025

#228

Post by nchmy »

codingdave wrote: post #70
zarzavat wrote: post #62

There should be a name for the fallacy: "You don't need React to do 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), a…

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

Contrary to those woo are downvoting you, I'll say that what's wrong with your analogy is that react would be like driving the 18 wheeler across the country with the handbrake on. There's better ways to do anything.

Re: React vs. Backbone in 2025

#229

Post by acdha »

robertoandred wrote: post #165
acdha wrote: post #141

Earlier quoted context omitted.

What makes React complex is that your simple example pulls in 100KB of code and entire layers like the virtual DOM which increase the memory and CPU requirements while adding significant new concepts a developer has to learn to be productive. That’s not to say that there aren’t benefits from that but it’s definitely extra complexity compared to using web standards.

A single picture is going to be more than 100kb. Meanwhile, there simply aren’t web standards that match React’s capabilities.

You don’t need to know how JPEG or AVIF work internally to use an tag.

> Meanwhile, there simply aren’t web standards that match React’s capabilities.

This isn't true for much of the web but it’s more deeply missing the point: if you’re building a web app, you need to learn the web APIs because those are what all web apps actually use. Adding intermediaries means that you have more things to learn, troubleshoot, and optimize. React’s value comes from managing the complexity of the code you write, which can be a real benefit for some projects but it doesn’t remove the need for you to know how browsers work.

Re: React vs. Backbone in 2025

#230

Post by ppqqrr »

pyridines wrote: post #203
ppqqrr wrote: post #198

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

> 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. "Ju…

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”.
Post reply on HN