[Cthulhu_]

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)

[Tade0]

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.

[elfly]

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.

[mikrotikker]

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.

[jamesfinlayson]

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

[paulryanrogers]

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

[rk06]

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

[frogulis]

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

[nicoburns]

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.

[burningChrome]

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

[hinkley]

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

[pjmlp]

Coping, unfortunately. I use React occasionally.

[azangru]

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

[WorldMaker]

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

[azangru]

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.

[WorldMaker]

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/

[hinkley]

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

[WorldMaker]

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.

[azangru]

> RXJS is also 18 MB

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

[pjmlp]

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

[jonathanlydall]

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.

[jamesfinlayson]

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.