I think the top issue in React-land these days is definitely that reactivity is not provided as a built-in. I agree that lots of libraries have achieved pretty decent DX in that regard, because the hooks API is actually very powerful and reusable, but I wish the React team wanted this for us all.
Congrats to Angular team for delivering what sounds like a pretty thorough reactivity implementation. I think their opinionated and provided-by-Angular strategies make it a tempting option more and more over time, even though I enjoy my React stack.
How many apps actually benefit from reactivity, i.e. 1,000 people can post to a feed realtime and the app fetches data from 200 other backend services? I believe for vast majority apps, a basic HTML/JS/CSS is all one needs. It's fairly trivial to make your own SPA in ES7.
If you don't know the use-case for reactivity and are going to advocate for "vast majority apps" being authored in "HTML/JS/CSS", I don't really understand why you're debating me.
Frontends - that are clearly more complex than the ones you use - are state machines managing asynchronously-accessible state stored in external services. Due to the nature of how many resources an application might use, it quickly becomes cumbersome to map out that state machine manually, and it is more beneficial to just write declarative display logic that will automatically execute when the necessary preconditions are present and a change has occurred within the state management.
Now, mind you, nothing I've said really involves reactivity yet; and, even worse, most solutions - especially your custom SPA - will rerender the entire tree of objects relying on each changed resource in order to accomplish what I listed.
The beauty of reactivity is that you as a developer simply write modular code - whether it's state or view, the more modular the better - and then your system ensures changes to the underlying state tree flush updates to the view modules attached exactly to the parts of the state tree what changed. It's optimal performance by default, you run the least amount of your own code each time a change happens.
Of course, it brings its own challenges and issues, but it really means that your general answer to "how can I scale this UI" is just "write it in smaller chunks", and that scales pretty dang finely across a team.
Unlike a hand-rolled ball of JS. Come on folks, it's 2023, put your tired arguments away.
Maybe you can consider that on HN you are talking to experts who in their lives experienced dozens different UI paradigms and frameworks including deep experience with React, its ecosystem, its benefits and its warts. I am pointing out that the problem of "how can I scale this UI" is experienced by a very small percentage of apps. For Meta or Uber it makes sense as they need to coordinate overlapping real-time feeds where dependency graph is insane; why should however most apps bother jumping on this paradigm? There are complex yet performant apps like draw.io that never touched anything reactive and aren't missing it in the slightest.
> Maybe you can consider that on HN you are talking to experts who in their lives experienced dozens different UI paradigms and frameworks
Maybe you can consider that on HN you are talking to people who spend their working lives answering the question of "how can I scale this UI" and think that reactivity is a good approach.
> why should however most apps bother jumping on this paradigm
I stated pretty clearly the benefits above - it has great performance in general due to minimal redraws, and those minimal redraws are accomplished "automatically" / via runtime construction so you don't even need to think about optimizing accesses, it's already the least possible.
More to the point, I don't see why we shouldn't laud Angular for delivering an opinionated reactivity implementation when their opinionated, batteries-included approach has enabled a lot of teams to hop in and build apps.
I also don't think you have any fucking clue what goes into UI development if you propose rolling your own SPA, so there's also that.
That might be true but React has the same issue with larger teams and everyone using a different part of it; the pace of development drops rapidly and apps become complex monsters for little reason.
Congrats to Angular team for delivering what sounds like a pretty thorough reactivity implementation. I think their opinionated and provided-by-Angular strategies make it a tempting option more and more over time, even though I enjoy my React stack.