Comment by hinkley
8 days ago
The reason I'm a backend dev at the moment is that I looked at the React model and decided I didn't want anything to do with this insanity.
I've been appalled by how long and how broadly the mass hysteria lasted.
8 days ago
The reason I'm a backend dev at the moment is that I looked at the React model and decided I didn't want anything to do with this insanity.
I've been appalled by how long and how broadly the mass hysteria lasted.
And what's crazy is with ai the percentage of apps developed using react in comparison to all other frameworks has INCREASED over the last 3 years.
It is truly mass hysteria, I would say that 95% of developers, project managers, and CTOs do not truly understand how these systems work under the hood, or at the very least are too scared and comfortable to try other systems. They just repeat the same things they hear and tell each other "react has a big ecosystem" "react is industry standard" "everyone uses react" "react was developed by facebook" "we will use react" "Developers only know react, how could we hire for a different framework?"
In my mind its clear that the alternatives are massively better. When i visit certain websites I often get a random tingle that it uses svelte because its way faster and has better loading and navigation than other sites and when i check the devtools I'm almost always correct.
I also get the same feeling sometimes when I hit a laggy slow webapp and I open the devtools and clearly see its a nextjs app.
A dev team could be trained on svelte or vue in literally 3 days, and so long as they actually understand how HTML, JS, and css work under the hood they would increase their speed massively. People just don't want to take the risk.
To add, the other dominant force is Angular, very popular in enterprise settings. I don't understand why per se, it's very... verbose, every component needing a number of files. It (and also React) gets worse if you add a state system like RxJS.
My theory is that it's popular with back-end / OOP / Java / C# developers, because they're used to that kind of boilerplate and the boilerplate / number of files / separation of concerns gives them comfort and makes it "feel" good.
But also, like React, it's easier to find developers for it, and on a higher level this is more important than runtime performance etc. And continuity beats performance.
(I can't speak of its runtime performance or bundle size though)
Angular has been my main framework for the past 9 years, so I guess I can shed some light on this:
AngularJS came before React and being a Google product, gained enough inertia in large organizations that given the choice, the decision makers preferred to migrate to Angular 2+, which at the very least had a passing similarity to the previous iteration, instead of jumping to a wholly new framework like React.
The very last AngularJS to Angular 2+ migration I participated in happened in 2020, when it was already known that the former would reach end of life by the end of 2021. That is how reluctant corporations are to rewriting the entire frontend codebase.
Mind you, I've used other frameworks like Vue in an Angular-oriented company, but the project was: greenfield, small and underfunded, so we had some more liberty in choosing what to use.
5 replies →
My current company uses Angular, and uses it reasonably well. Prior to working there, I'd never used Angular, so I feel well-equipped to comment on this.
We've also recently absorbed a vanilla(-ish) JS codebase largely developed by one dev which provides a point of comparison.
Angular has plenty of boilerplate and idiosyncrasy, but it being opinionated and "pattern-y" has advantages when you want devs who infrequently touch it to be able to jump in and make changes with some level of consistency.
Additionally -- and this is anecdotal, but I suspect it's a common part of working with a plain JS codebase -- tracking the flow of data through the Angular application is usually soooo much more straightforward, even when it involves navigating through many layers and files. The Angular codebase only has N types of things, and they tend to relate to each other in the same ways, and they're often quite explicit (such as explicitly defined component element names in HTML templates). In contrast the JS app has whatever it has built up with very few constraints keeping it consistent. Obviously that could be improved with discipline and structure, but reducing that requirement is one of the things a framework gets you.
I can't comment too much on React as my one experience working in a proper React codebase was in a team who were largely as clueless as me :)
1 reply →
>> To add, the other dominant force is Angular, very popular in enterprise settings.
I work at a fortune 200 company. Worked in development for 5 years before moving into accessibility. I still have good friends who are still working on dev teams here. When I left, people were saying how shitty Angular was and how React was the way of the future.
5 years later and they're rebuilding several enterprise apps that were built with React and going back to Angular. I guess one of the directors, in an all hands team meeting basically said, "The ReactJS experiment is officially OVER."
Its anecdotal evidence, but it seems large projects and teams are going back to Angular for familiarity, ease of debugging and maintainability - not necessarily speed and performance. Which when I was still in dev circles, that was all that mattered.
It kind of feels like another changing of the guard in the industry right now.
2 replies →
> It (and also React) gets worse if you add a state system like RxJS.
I don't understand this sentiment.
Client-side applications often have a need for global state. It could be as simple as whether the user is logged in, or as complex as, say, the shapes that you have drawn in excalidraw canvas, and the drawing tool that you have selected. State changes over time, and so it seemed plausible to model it as a stream of states over time (hence rxjs). There are more robust ways to deal with the state, which is why angular has now moved to signals; but what is so bad about the state?
6 replies →
That is one of the reasons, the other is everything is in the box, hence why Next.js is also the React approach the same enterprises will reach for.
Also why enterprises love Java with Java/Jakarta EE, .NET with VS Studio full install, Rails, Django,...
Like all languages, C#, Java, etc have cargo-cultist developers who use them badly, and in the case OOP languages, doing things like overdoing the separation of concerns.
However, speaking as someone who actually uses C# day in and day out and understands the trade-offs of different levels of (or even no) separation of concerns, it's not done for us to "feel" good.
On very large projects running for a very long time with many developers coming and going with varying levels of competency, an appropriate amount of separation of concerns and decent "plumbing" can be the difference between a code base enduring decades or becoming essentially unmaintainable due to unchecked entropy and complexity.
1 reply →
There's 3x more React libraries and code out there to reference. AI agents do _a lot_ better with React than, say, SolidJS. So productivity > performance is a tradeoff that many companies seem to happily take.
There's so many React libraries because the framew... I mean library is extremely barebones.
That is, in my view, the main issue with React (rendering model notwithstanding): every React application is composed of tens of tiny dependencies and since there are several competing libraries for even basic things like routing, no two projects are the same.
Umm, are we really taking "being AI friendly" as an account to choose framework now? I’ve seen this mentioned often enough lately that it’s making me uncomfortable. I fear if this will becomes epidemic. This will literally hault progress in improving and adopting better frameworks.
2 replies →
And the end users pay the price!
> AI agents do _a lot_ better with React
Do you really think this is a solid argument in this particular discussion (about it being slow and introducing a mass of unnecessary complexity)?
1 reply →
It is very hard to avoid when you have Vercel doing partnerships with SaaS cloud providers that end up supporting only React and Next.js on their SDKs.
Even if other programming stacks are supported, they tend to be 2nd or 3rd class versus anything React.
Look into the ecosystem of headless products that have jumped into the whole MACH architecture hype cycle.
Then you have to justify to upper management, and partner support when problems arise why you are not using their SDK.
Why on earth would your cloud provider dictate your front end stack? My mind is in tatters trying to understand this thought process.
4 replies →
People have no idea who they are hiring, so they hire people who have no idea what they are doing.
> they actually understand how HTML, JS, and css work under the hood they would increase their speed massively.
Indeed, Svelte is built directly on web standards so knowing it strengthens your command of core JS and the web-platform itself - not just a silo-specific layer like React.
Also Svelte acts as a compiler: it outputs just clean, highly optimized JavaScript with no virtual DOM, that uses native web-APIs and results in minimal runtime overhead, smaller bundle sizes and overall excellent performance and DX.
React is slower than the alternatives, but next.js is really really slow.
I managed to avoid learning React long enough to become a manager.
I'm not saying I won't ever end up in engineering and won't ever have to learn it, but at least right now, it feels kinda like I got away with something.
I remained unemployed after I was laid off until a change of career happened. I refused to back to Angular/React/Vue. I was not going to shovel shit anymore for people who were clearly incompetent and really entitled about it.
Where did you career change take you instead?
Enterprise API management
It lasted because React genuinely did introduce a useful new paradigm - of UI being a (mostly) pure function of state. This has actual benefits. Unfortunately the way this was implemented was (very) suboptimal, and now they're locked in.
I agree that this stubborn clutching to that original idea, despite better options that acheive the same paradigm having arisen in the meantime.
Unfortunely it is hard to avoid when doing backed development with SaaS, iPaaS products, where JavaScript is in many cases the only extension language for backend widgets.
I am kind of alright with Next.js, as it is quite similar to using SSR with more tradicionla backend stacks.
Also at least node's C++ AddOns give me an excuse to occasionally throw C++ into the mix.