Would've been helpful if they tried to make the code as close as possible, e.g. use the same struct (and var name) for the password requirements.
React vs. Backbone in 2025
71–80 of 245 posts
Re: React vs. Backbone in 2025
#72In terms of simplicity Mithril is pretty great. Personally don't love the hyperscript syntax but it can be used with jsx.
Also Preact but the mental model is closer to React.
And Vue can be used from a script tag without a build step too.
Re: React vs. Backbone in 2025
#73There 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…
Took the words out of mouth. Every thread about React people come piling in about how overly complex it is.
When people throw around words like "foolishness" to describe tools that millions of professionals use, its hard to take the rest of their comment seriously. It radiates a special blend of arrogance and ignorance.
Whether React is good or bad, there is a reason people use it. Outright dismissing it entirely seems a bit like chestertons fence.
Re: React vs. Backbone in 2025
#74Earlier quoted context omitted.
1,000 components is my standard test for trying out a new UI library. I recently tried it with Kotlin/Compose. Turned out that everything becomes noticeably slower with so many components, even if the components are in a scroll view and only a few of them are visible.
Displaying so many would require virtualization. No one is going to see a myriad of components all at once anyway. The slowing down part might be eager computations in partially optimized implementations. The same way we use pagination on the web, or lazy loading, etc... But I guess the question is whether that should be a default...
Maybe but it sounds like bad excuses.
There are a myriad of examples anyone can come up with that require a UI library to simply be fast. For example, perhaps someone wants to implement minesweeper with checkboxes. Or build an "infinite" feed, or a settings panel showing thousands of settings of a system where you can filter with a filter box, etc., etc. You can argue against all of these cases, or you can simply rely on a fast UI library and be done with it.
Re: React vs. Backbone in 2025
#75There 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…
React (and Tailwind for that matter) are great for hiring and getting hired. The chances of someone screwing it up or being lost in their first week/month when parachute into a project are pretty low.
It has very little to do with the right abstraction or the best technical solution to the problem.
The web has no default design pattern. It’s the Wild West for better and worse.
I made my peace with modern web stack once I understood this.
Re: React vs. Backbone in 2025
#76There 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.
Seems like your example isn't equivalent to op's because using multiple frameworks increases complexity while picking a different car to drive to local store doesn't.
Re: React vs. Backbone in 2025
#77There 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…
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…
There is some good food for thought here.
One thing I’ll also say: building static websites and building big interactive web apps are two points on a LONG spectrum. Yet for some reason online discourse ignores this.
This enormous spectrum gets compressed into just “modern web dev” or “JavaScript”. Not just in conversation, but in teaching materials, job postings, you name it. It leads to wild disconnects and disagreements between people who think they are peers but are actually building radically different things.
Re: React vs. Backbone in 2025
#78I 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?
Re: React vs. Backbone in 2025
#79Look 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.
Re: React vs. Backbone in 2025
#80I 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,…
> Lots of people don't even know how JavaScript works despite using it every day.
Imo every React course on the internet should start by having people implement a multi-step form wizard using solely Jquery. You don't appreciate where you are if you forget where you came.