Hacker News Reader

Comment by hinkley | Hacker News Reader

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.

View on HN

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.

This whole thing is the problem. AngularJS was released in 2010. If in 2010 I'd know that the damn thing would die in 2021, and that I would have to rewrite it all by that date, I would not have used the damn thing in the first place.

I also at some point inherited an app written in Vue 2. By the time I got it, Vue 3 was already out and a couple of years later, Vue 4, completely different to Vue 2, was out. Rewriting was not an option, so I had to create a docker image that can compile the damn thing offline, cause if some part of the supply chain breaks, well, that's it.

Ten or eleven years is not a super long time in enterprise software. Having to keep upgrading and changing libraries just cause the devs of the libraries get bored should not be a thing.

This is why I struggled and struggled to omit JS at all costs on a greenfield project - many apps from even 5 years ago by now fired teams fail to build with cryptic npm messages. And if you get past that you have to deal with webpack or some such junk. We settled with go fyne which compiles to wasm to handle both local and remotely accessible use cases. Trade off is not as much freedom and a fixed feature set but I know it's gonna work after 5 godamn years.

> If in 2010 I'd know that the damn thing would die in 2021

Was it obvious back then? I had to work on an AngularJS site for a while and it was the most confusing thing ever. Having come from React I couldn't understand the complexity but maybe it was still better than callback hell in jQuery?

React--for all its warts--hasn't had a major backward compatibility break. Microsoft Windows selling point for a long time was backward compatibility.

what?? vue 4 is not out yet. it is not even planned

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 :)

My experience of working with Angular (admittedly several years ago when Angular versions 2-4 were current) was that it was pretty close to the React model (which was a huge improvement over the old angular.js), but also slightly worse than it in pretty much every area.

Most of the problems were the framework being too opinionated and not getting out of your way, whereas it is generally easy to "break out" of the abstraction when needed with React.

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

> ease of debugging

I had thought to start trying to contribute to the Grafana project and it turns out the whole frontend is React and some completely impenetrable flavor of it to boot. How do people work like this? It’s insane.

Coping, unfortunately. I use React occasionally.

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

RxJS is far more robust than signals (things like backpressure operators, scheduling operators, and more). Angular's move to signals is just another sign of what Angular was doing wrong with RxJS all along: Angular could have used the robustness of RxJS to make a better framework but at many decisions along the way chose to not trust RxJS to do its jobs, skipped operators for the sake of leaking imperative state back out into the world and/or treating RxJS like heavyweight Promises (which indeed they are heavy and unweildy in that context). Signals enshrine the imperative leaks as the preferred and final path forward, further crippling the robustness RxJS could have offered and yet also doesn't entirely eliminate RxJS as a dependency.

Angular was born broken in how it made use of RxJS. A lot of developers have a bad impression of RxJS simply because Angular led them to so many RxJS worst practices, bad performance, and taught them that RxJS was just "heavy Promises".

RxJS has an intrinsic diamond problem (multiple events fired when several sources update simultaneously), which led to occasional glitches. Signals are guaranteed not to have that problem. This is a strong argument in their favor.

But yeah; I am amazed and amused by how, during the past couple of years, the interest to rxjs has plummeted. No more conference talks on this topic. And even though Observables have been released natively, there is no activity in the rxjs repo to update the library accordingly.

As with most RxJS problems the diamond dependency problem can often be fixed/solved with the right combination of even more advanced operators/combinators. Often the easiest solution is `combineLatest`, but as mention that will over-fire depending on your update patterns. Sometimes a simple `throttle` is all the backpressure fix you need on that to reduce diamond over-firing, especially in combination with a cool scheduler such as `animationFrameScheduler` [0]. However there are also other domain-specific replacement options for `combineLatest` if you know the general event firing pattern such as `withLatestFrom`, `zip` [1], `join` [2], or `and/thenDo/when` [3] (in increasing complexity). (ETA: Not to mention that many diamond dependency problems are just fan out problems that can be solved by refactoring computations to an earlier point in the pipeline before the fan out rather than trying to fan back in.)

> And even though Observables have been released natively, there is no activity in the rxjs repo to update the library accordingly.

I believe this is still reversed: "native" Observables, the WICG Observables Proposal [4] is still marked as a Draft Group Report (not even officially a Proposal, still, ouch). The Issues of the RxJS repo still seem to indicate that everything is still in a holding pattern waiting for that to move.

I still cynically think this is yet another case of WICG holding the football in front of RxJS and just as likely as Lucy would do to Charlie Brown, will pull that football again right as they try to kick it, again. The WICG has acted like there is renewed interest in Native Observables but my cynicism thinks they are just rehearing drafts on it to appease the Observables crowd just long enough to claim more interest/easier implementation in Native Signals and try to get a Native Signals Proposal passed without good Observables interop. (But again, I'm a cynic here.)

[0] https://rxjs.dev/api/index/const/animationFrameScheduler

[1] https://reactivex.io/documentation/operators/zip.html

[2] https://reactivex.io/documentation/operators/join.html

[3] https://reactivex.io/documentation/operators/and-then-when.h...

[4] https://wicg.github.io/observable/

RXJS is also 18 MB which is irritating in a backend but completely bonkers in a frontend.

The entire npm package is 4.5 MBs uncompressed, and that includes a lot of files that won't be included in a modern bundle. A simple `npx esbuild --bundle ./node_modules/rxjs/dist/esm/index.js --outfile=./vendor/rxjs.js --format=esm` gives me a 141 kb file before compression.

If you are seeing 18 MBs in your bundle from npm you may have more than copy or something else wrong.

I will complain that RxJS still doesn't have a proper ESM build in 2026 for even better tree-shaking because that is apparently waiting on the WICG Observables "Proposal" to complete, and cynically I still don't think it is going to happen and I would love real ESM from RxJS someday like yesterday.

> RXJS is also 18 MB

This is impossible. I think you are off by about a factor of 1000.

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.

Yep, agreed. I worked on two PHP codebases at a company many years ago - the "old" and the "new". The old was just frameworkless PHP with three different ways of doing controllers, partial templates with no closing tags so that they could be inserted anywhere without breaking the page, inline SQL in the templates etc. The new was hugely complicated with long inheritance chains and multiple classes with the same name but in different directories... but it was structured and you couldn't easily do anything wild.

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.

As a solo dev who picked SolidJS, yes, it is a big factor. Things like tldraw, node editors, wysiwyg editors, etc. Having to reimplement them is a huge time sink.

I also second this.

Some point last year I dropped solidjs in favour of React.

Purely because of libraries and ai assisted dev velocity for my own projects.

Actually started working on the features instead of wrestling with framework.

Sometimes taking the path of least resistance just makes sense.

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)?

Some people need ways to cope with the drawbacks of what they use, even if irrelevant to the conversation.

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.

Because they have these things called SDKs to extend their product, for specific programing languages.

Here is an example, https://www.sanity.io/studio

Want to extend the SaaS product for your backoffice users?

Learn React or make Studio from scratch.

Frontend stacks are also backend stacks in cloud products.

This looks like a SaaS vendor not a cloud provider?

I wrote "SaaS cloud providers", I am yet to see a Saas solution on-prem.

Because with Next.js, Vercel was able to turn the frontend stack into also a really shitty backend stack. And it's particularly shitty at being deployed, so they're in the business of doing that for you.

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.

Reply on news.ycombinator.com