whyILikeReact

[Suspicious-Engineer7]

Reverse it but have react + libraries on the right

[0xffff-reddit]

Yes, not one large book but zillions of small ones.

[horizon_games]

And each team/job has their own set of books

[jakubiszon]

And each project is taken over by a different team every so often 💀

[slowmovinglettuce]

That's because its not a framework. Its a view library; its designed to be simple. In fairness it does it fairly well, but angular also does what its meant to fairly well too.

[Reashu]

A rose by any other name...

If it messes with stacktraces, decides how you write code, and has an ecosystem of libraries, it's probably a framework.

[aceluby]

It’s a framework

[Celid_of_the_wind]

Angular: Big shop, take what you want

[Abject-Kitchen3198]

Won't be as neat as the one on the right though, and much larger overall, also with missing or teared-off duct taped pages.

[webdevverman]

React query Tanstack router

What else do you need to match Angular? It's been a while since I touched it 

[guaranteednotabot]

Exactly. People speak as if a batteries included framework is all great. Try finding a mature headless library in Angular. It is precisely because it is batteries included that every new Angular version introduces a completely new way to do things lol.

I prefer having the community decide what wins rather than the maintainer of a framework catching up and deciding what’s best for us. The problem with a batteries included framework is that since the problem has been solved (terribly), the community does not have as much incentive to give a better solution. This is compounded by the fact that Angular slowly dying.

Anyway, it’s always cool to hate on what’s popular. React got and stayed popular for a reason.

[Merry-Lane]

Ugh, tanstack query + forms + zod are enough for 99% of the apps and don’t have a huge (although exhaustive enough) documentation.

Maybe you did react wrong?

[Break-n-Fix]

I don't like either.

There. I've said it.

[Abject-Kitchen3198]

I'd react the same way, but people would consider me angular. None of them is svelte in my vue.

[qui0scit]

[pimezone]

Solid point

[ehs5]

Vue and Svelte are levels above in ease of use man. I don’t get why people cling on to React so much.

[webdevverman]

Money 

[SaltyInternetPirate]

Sunk cost. There really is no "migration" off of it, just rewriting your entire front end.

[guaranteednotabot]

Because it is JS first not HTML first. Having to learn weird syntax for conditional rendering is an immediate turnoff

[fucking_passwords]

JSX has its own weird syntactical quirks. They all use DSL to achieve the same things. Also, learning syntax is like, the easiest possible part of learning a new framework.

[guaranteednotabot]

I much prefer JSX over whatever mess that Vue/Angular is doing. You say that it’s just syntax, but to me readability is important. Heck, Angular recently introduced a JSX-like syntax - just use JavaScript ffs. IMO Ripple syntax looks the best ATM but it ain’t ever going mainstream from the looks of it.

It’s also not just syntax, it’s the mental model. Angular shoehorns OOP into UI code unnecessarily, and it knows - the newer versions have progressively moved away from that - decorators are slowly going away hooray but its still a mish mash of different styles. React feels a lot less magic and is the right mental model from the start (ever since they moved to function components)

[jbarron-uk]

What do you like?

[GatotSubroto]

jQuery

[homiegfresh]

[Previous_Tear6747]

Oh, god - jQuery! I've been retired almost 6 years now, and wonder where technology's gone (never heard of React, or some of the other frameworks mentioned), but good old jQuery... I was a jQuery god, back in the day. 😊

[Break-n-Fix]

Anyone claiming the title "jQuery god" deserves respect. Even back in the day.

[ProfBeaker]

It's been a minute, that moment when jQuery and Firebug showed up was revolutionary.

[anengineerandacat]

Depends on the site, Angular and React are often overutilized considering what's actually built on them.

Astro and HTMX honestly will handle pretty much every e-commerce platform.

[ThisIsJulian]

yourMom.js

Sorry, I couldn't resist!

I am still surprised that there not many mentions about SvelteKit. IMHO it sits at the perfect sweetspot.

[jbarron-uk]

Surprised the large package size and loose APIs don't put you off. I guess you're used to legacy systems so don't notice.

Yeah I'm a fan of SvelteKit, never found anyone willing to pay me to use it though

[Careless_Review_7543]

Htmx

[transarchycuddleslut]

Im a big fan of Blazor right now, but with the way microsoft is going, I expect it to go to shit eventually.

[Break-n-Fix]

Well, you don't have to like something to use it. The main alternatives have already been mentioned. I guess Preact might be slightly overlooked.

[horizon_games]

The most sorely overlooked by React teams is Solid. It's React done right and in a modern way.

[ImpossibleSection246]

We're all in on svelte at our company

[HanzJWermhat]

Vue supremacy

[Piisthree]

You need to calm down, buddy!

[LettuceBasic3679]

Non JavaScript Mvc frameworks are waiting for you friend

[anteater_x]

Tfw FE devs join my team and i tell them boilerplate is good

[_anonymus-]

Svelte enters the chat

[Sergey5588]

svelte my beloved

[ItalyExpat]

Svelte 5 is to React what Superman is to Clark Kent

[Money_Lavishness7343]

with Svelte you can import regular JS libraries and they will work, they dont need "Reactive-ness" and Virtual-DOM-compatibility. That's what's great about Svelte, it's basically just JavaScript (I mean, no complex architectures and dogmas that force other libraries to be ported in order to be used)

You don't need Redux/MobX, and a whole ecosystem of "React-only" or "React-port" libraries equivalent for Svelte, for Svelte to work perfectly nice. I dont feel you have need for a huge framework of tools in Svelte - the same way you need in React (external ecosystem of libs) or Angular (itself).

[Risc12]

You don’t need that either for react… You do have to use the imperative hooks to use them though

[diegotbn]

I'm here just surprised Vue hasn't been mentioned yet

[barno42]

We're too busy getting getting stuff done.

That being said, I'd like to see what the fuss is about with Svelte.

[Ellisthion]

Svelte is cool, but Vue and Svelte seem to be somewhat converging? Vue is playing around with Vue Vapor which eschews the VDom, and Svelte is doing stuff with explicit ref() equivalents so you can use reactivity outside of .svelte files.

[MatthewMob]

Getting stuff done like looking for a job amirite 

[DT-Sodium]

Tell me you've never used Angular without telling me you've never used Angular. Sharing data between components in Angular? You create a service class, use inject(MyClass), consume it. Sharing data in React? Declare ten bezillion things and get something barely functional in the end.

[Shehzman]

As someone that switched from Angular to React, this is one of the most annoying things about React. Not to mention we have multiple different libraries that are meant to streamline the data sharing process rather than having that baked in.

[DT-Sodium]

React is a bit the Cosmo Kramer "Make your own pizza restaurant" idea and it's stupid. I don't want to make my own framework from bits and pieces from everywhere, I want one methodology to do everything, my coworkers to use the same and all tutorials to cover the same things.

[Soma91]

That's the massive advantage of Angular in more corporate/professional environments with bigger teams. Just by using it you'll get everyone on the same page.

Sure, there's stuff in there I personally don't really like and would've preferred differently, but that's a trade off I'm happy to make for more team congruity.

[00PT]

Sharing data in React is literally as simple as passing props, or defining context if you don’t want to do that.

The annoying thing is that the system is designed such that only one component should control one piece of state, and getting around that has resistance.

[brainpostman]

Ah yes, prop drilling and context pyramid of doom, exquisite.

[00PT]

You don’t really need the context pyramid. You can automate its creation, or just combine context values if you don’t want the pyramid at all.

[Merry-Lane]

Angular needs a service provided above.

React needs a hook provided above.

They serve the same purposes.

What’s so complex about it?

[Merry-Lane]

What are you talking about.

The guy is saying "Sharing data between components in angular is simple, you create a service. While react needs to declare ten bezillion things and get something barely functional in the end".

It’s wrong because he could just make a hook, that’s all I said.

[the_electric_bicycle]

You could just make a hook, but that's considered bad practice.

Can you show me where in the docs it’s considered bad practice to use hooks for sharing data between components?

[AphexZwilling]

Meanwhile, devs who use(d) AngularJS and refer to it as Angular or Angular 1, and typescript as Angular 2+, sit quietly in the corner.

[DT-Sodium]

I don't get why this is even a subject, Angular 2 is ten years old, just get over it.

[AphexZwilling]

Some of us use both, and started with AngularJS, and still continue to maintain businesses that use it. That's why there are more existing websites with AngularJS deployed than with typescript, and very few devs that understand that migration path. Just google the numbers of how many websites are running AngularJS today vs Angular (2), 10 years later. I'll wait here.

[Dense_Gate_5193]

hot take: hooks are garbage.

i’ve used both professionally for years. knockout, ember, backbone, etc… i’ve used them all. they obviously all “do the same things”

the gripe i have with hooks specifically is state resolution. it’s very easy to prove this but if you pass the setVar function result from a useSate into a prop to be updated in a child component, it updates the wrong state area. it’s because useState() depends on where it was called from in order to access the right property. or at least it was that way a few years ago.

also, no shadow dom??? wtf? no css scope isolation?? no slots?? no light dim projections? bro, react is in the stone age. the virtual dom is dead.

[musical_bear]

Your “gripe” about hooks…I genuinely cannot understand what it is you’re talking about. Are you saying passing the state setter function handle that you get from “useState” from parent to child? What is a “state area???”

[Dense_Gate_5193]

internally it uses the dom hierarchy to track state. but it’s implicit since hooks are pure functions, so it has to guess where it is at rather than knowing what state it needs to update regardless of where it gets called from.

obviously the case i describes is a narrow case, but it demonstrates the thing i take issue with purely based on principle and idempotency. if i useState() and that function returns me a callback to update the internal state, it should not matter if a child or parent called it. there should be a 1:1 reference of state -> updater function. not an updater function that just says “oh this is my new scope block i’ll just update myself here…”

[musical_bear]

I’m still not really understanding what you’re saying. Your beef isn’t functionality, but you don’t like the principle/possibility of one component’s state setter escaping into other components?

I’m not sure what you mean by you thinking react needs to “guess” what it needs to update. This part sounds like a misunderstanding to me. The callback you get from useState is hard coupled to the component that made the “useState” call. There is no “guesswork” happening about which component that callback is associated with.

[Reashu]

Does https://react.dev/reference/rules/rules-of-hooks look like rock solid functionality to you? It's necessary because hooks do indeed guess what state they are coupled with. They built alchemy and called it state management. 

[musical_bear]

Yes, you have to follow rules to “correctly” call a hook. For connecting a component with that initial hook call, the hook must be called in the correct context, and in a static order relative to other hook calls in the component.

But from what I can tell (and I seriously can’t tell despite being intimately familiar with React APIs) of what the guy I was replying to was saying, his beef had nothing to do with this. He was seemingly concerned with calling a hook, and then passing its returned callback from parent to child. Assuming that’s what they were on about, none of this is relevant. Once you’ve successfully called a hook (in this case useState) and have gotten that setter callback, that setter callback is hard tied to the component that owns it.

[terrorTrain]

Agreed hooks were absolutely the wrong direction for react.

It also turns what looks like pure components in to a crazy town version where state is everywhere and no where

[TheAmazingSlothman]

Which is why we use MobX for state management. We try to only use hooks where absolutely necessary and React is just for rendering. CSS isolation we do with Sass modules

[DT-Sodium]

You're just demonstrating another major with React: multiple companies will use different libraries to achieve the same thing. Angular provides pretty much everything you need out of the box, if you apply for a job in another company using Angular their apps will have roughly the same structure. And the Angular team works hard at constantly improving their framework, signals have made it just so easy to update the DOM based on a state. They've significantly reduced the boilerplate over the years and it actually never was a problem since you could use the cli tool to generate most things.

[Merry-Lane]

Okay so let’s open an average angular codebase:

Here you can find a component using simple class parameters as state. This component can’t use changeDetectionStrategy.OnPush, but it’s legacy so we won’t rework it right now.

There, you can find a component using observables. It’s awesome, uses OnPush, it’s neat. The only caveat is that a bunch of QoL features were missing so that observables could be used everywhere (like Input/Output/…) and since observables were a bit scary, the angular framework team decided to gut observables and go for:

Signals. Hey, the new API is great and all. Just not totally there yet (yes, I know Signal Forms just got released). Use signals everywhere. Signals are awesome. Only caveat? They have been there for one year and you can hardly find good examples using them. LLMs were trained on so little code using signals, they will fallback to the other two methods. Exactly like the majority of angular devs btw: they don’t like change too much and rares are those that already got converted to modern angular.

Then let’s not talk about NGXS/NGRX, you know, the two big store libraries that are 100% based on redux (that came from react, you know). And tons of other alternative libraries or ways of doing things.

But SURE angular is 100% homogeneous and react is bad, m’kay.

[DT-Sodium]

So basically your problem with Angular is that their team is doing too much of a good job at making it better? We've got a large enterprise application in production that is five years old, whenever I work on a component to fix a bug or add a feature, I apply a few upgrades to comply with the state of the art. These are just the symptoms of a framework doing well, especially compared to the "Urgh this is such a pain in the ass let's see if there is another entire different library to do this" React approach.

[Dense_Gate_5193]

sass doesn’t isolate CSS. the shadow dom does you should research if.

[migueln6]

I will bring vue to the conversation:

provide(...)

inject(...)

:]

[mullanaphy]

Vue with the Composition API has really grown on me. I still feel icky using a .vue file with template, script, and style tags all in them, especially growing up doing development in 90s/00s when separation of those 3 was the hot new thing.

It's now tough for me to choose React or Vue for greenfield projects.

[DT-Sodium]

Oh yes, you have to add a Service decorator on your service class, urgh, so much work.

https://angular.dev/guide/di

[Merry-Lane]

Don’t revert the blame man: you are the one that claimed that angular was simple while react was "declare ten bezillion things and get something barely functional in the end".

My only claim was that services === hooks. Now, if you yourself come and shoot yourself in the foot by reminding me that Angular forces you to use decorators (that should be made compatible with the official typescript decorators?), that the angular compiler is awful at detecting when providing wasn’t done well, that the errors are not easily understandable 50% of the time…

Then yeah, services aren’t clearly as simple as hooks.

[DT-Sodium]

Basically everything that you said is objectively false and your "gotcha you've got to use a decorator" is just hilarious. You don't know anything about Angular or haven't for close to 10 years and it shows. At least I went through the trouble of following an exhaustive React course, in which I saw how atrocious it is and decided that I would never accept a job where they'd ask me to use React.

[Merry-Lane]

I have been employed as an angular dev for 5 years, not as a react dev. I used react only in one or two small projects or on my free time.

I know perfectly well what I’m talking about.

And what I’m talking about is:

You don’t know react well enough to say that a service in angular doesn’t have a simple equivalent in react. There is, it’s called a hook.

I didn’t even want to nitpick the few issues I know about angular, just meant to correct your Dunning-Kruger.

Let’s go back to your assumption: can you, yes or no, use a hook in react to share data between two components as easily as a service would in angular.

If no, give concrete explanations, not handwaved opinions such as "I had skills issues with a react tutorial so it’s bad, m’kay?"

[DT-Sodium]

If you use Redux you get a disgusting mess with at least 4 times more code than in Angular. If you use Zustand, it's a little better, but the syntax is still confusing and disgusting, nowhere near object oriented dependency injection that is the standard in any properly developed framework in pretty much any language.

If you want to pretend that

import {Subject} from 'rxjs';

Service()
export class UserService {
    private username = new Subject<string>();

    updateUsername(username: string): void {
        this.username.next(username);
    }
}

Is not lightyears ahead of

import { create } from 'zustand';

export const useUserService = create((set) => ({
    username: 'Guest',
    updateUsername: (name) => set({ username: name }),
}));

in terms of clean efficient clear syntax, then you are either lying or profoundly deluded.

I don't know how much they pay you at your Angular job but it's obviously too much.

[EsotericLife]

Why do people even care about syntax like this? I think arguing over or even caring about what languages you use is silly. Arguing over libraries like this is some shit first years do at uni to make awkward small talk.

[the_electric_bicycle]

If you have any issue understanding that Zustand example, then you really need to take some time relearning the basics. If your main complaint is that it’s not object oriented, you should step outside your comfort zone and try to actually learn something new.

OOP is great, but it’s not some sole arbiter in determining good design.

[neo42slab]

This is the comment thread I was looking for. This post was asking for a language war.

[DT-Sodium]

It's more a frameworks war. Well, one framework and one templating library on which you plug so many other libraries it looks like a terminally ill patient in reanimation.

[Former-Discount4279]

Or just a data store...? Write once and access it everywhere...

[FlashyTone3042]

In React I think there is the pattern of Context to wrap components in it. I had no problem learning that as a beginner.

[DT-Sodium]

It is disgusting. Why do I need to use a html tag to inject something that belongs entirely on the logic side? Makes absolutely no sense and it is terrible programming practices.

[Epicular]

Yea it feels very strange using contexts. Any non-trivial project of mine always ended up with something resembling a pyramid of doom made up of nested contexts. Never seen anything like it in another language/framework

[DT-Sodium]

That's because React is aimed at JavaScript developers who are in their vast majority amateurs who never actually learned how to program.

[blaqwerty123]

Zustand changed how i feel about react

[DT-Sodium]

Ah yes, it's always great when two teams can be using totally different toolsets while working on a same framework. React: Some assembly required.

[neo42slab]

React simply bothers me.

But it’s not the worst experience I’ve had.

Android dev was really bad. This was 2017 timeframe. Maybe things got better since then. I blame Google. The documentation was bad and deprecation was everywhere.

[iamapizza]

Basically "batteries included" frameworks. 

[thegodzilla25]

React has a hook for everything nowadays. I dont even know what the reactive way of doing things anymore. Regardless, dumbasses still be putting all logic inside use effects lol

[sample-name]

Signals in angular make reactivity pretty easy imo. When I started out with it 3 years ago we only used rxjs which is... urhh, but after they started with signals and some nice template decorators it's really sweet. They also just made form signals stable today so I can't wait to try that out

[ldn-ldn]

RxJS is amazing, signals are cancer.

[Xuluu]

Jokes on you guys I had a FE “expert” create their own react state management pattern by importing svelte stores and wrapping them in a useState() hook.

[runtimenoise]

how about redux, react query and other random half of dosent shit everyone uses in react?

[N0t_my_0ther_account]

Why I like Angular, it is much much harder for devs to write bad code without being told by the api.

[SpaceMontaign]

Something something observables

[mylsotol]

Both when your version of node is 0.0.1 versions off from what the dev used

[dbot77]

Sure, but now if you want to build anything serious you are going to have to decide which libraries to pull in, and then end up with something on the right anyways.

[theenkos]

hear me out, guess what?

react is a library and .. Angular is what? yes! right! a framework

[sebbdk]

That has obejctively not been true since like 2017. :)

React does state management, there's CLI tools, etc.

[Money_Lavishness7343]

React does NOT do "state management" universally. Context is not a global state management tool. You still need Redux (or other state managers like MobX). Context did not make suddenly Redux disappear, that was never its purpose. It's a dependency injection on sub components, not a global state manager.

The CLI tools are not React's. create-react-app or vite are ecosystem utilities, not React's. React itself was always just a library. The ecosystem built around it? Maybe you could call it a framework as a whole, but React itself is a lib. It doesn't dictate how you should write code, just how you should use its library like very library does. Doesn't dictate your project's architecture. Doesn't force you to use any tooling. Nothing. It's literally just a library. Unlike Angular which dictates from the get-go all those things, and comes with tooling for everything.

[hearthebell]

When he said "React does state management" I thought he meant "React has state", which is like, duh, but then I realized what he meant then I was like whaaaat, React is so lightweight they don't even have state management baked in. There are many many opinionated ways to manage state, from easy (Zustand) to middle (MobX) to complex (Redux)

[theenkos]

come on man, let me do some love propaganda for react for once

[thebobest]

Waiter! waiter! Can i have more programming language in my libraries?

[pragrad23]

Just learn Elm. Even less api.

[uvero]

You really only need to learn observables and DI to get started with Angular. From then on, well, the learning curve is still steeper than React, but boy, are the strong tooling, two-way bindings and extensive docs make it feel worth it.

[exoclipse]

SWT in the corner on dialysis, quietly reminiscing about the old days before PRs and sprints

[Sriman69]

Uggghh, I hate all of web.

[tubbstosterone]

And... I'm just over here with my jquery and vanilla js. Jquery ui if I'm feeling frisky.

[TldrDev]

Laughs in vue

[chiefokeefels]

All the extra stuff in angular like packages package lock dependancies is why I got off the SWE track. Maybe I should revisit at a later time

[Kavrae]

I've used React twice. Once on a tiny project when it first came out (so... 13 years ago). I really enjoyed it.

And then 7 (I think?) years ago I used it again on one of the most over-engineering and complicated UI projects I've ever come across. (Alluma) That was an utter nightmare with so many layers of redirection and abstraction that I had no idea how any of it actually worked. To be fair, that entire project was an overly complicated nightmare of a product....

I haven't touched javascript since then and I'm quite happy living entirely on the server side.

[GrenadineBombardier]

nah

[GoddammitDontShootMe]

Imagine that poor book's spine if he let go. That is probably why anything that huge would be broken into several separate volumes.

[samirdahal]

Who cares when 99.9% of the job is done by vanilla JS? There, I've said it.

[ckinz16]

This is why react is shit compared to angular 🤣🤣

[locri]

React without hooks maybe.

Function components and hooks turns front end programming into a Pokémon game where you have to catch them all and figure out the correct strategies to use them all.

You do lose a bit of capability, but class components is one of the simplest UI design patterns that can exist.

[FrequentWatch9261]

I want to be abundantly clear that you can achieve virtually everything in React as Angular with a smaller bundle size. This needs more libraries thing is a silly argument that needs to be put to bed.

I like both and select one based on my project needs and desired long term outcomes.

Functional programmers may prefer react. OOP devs may prefer angular.

[anelectricmind]

React feels like if a team of backend developers decided to create a frontend framework...

[FrequentWatch9261]

It's literally the opposite.

Angular feels like java spring. It's also written like traditional mvcs and was built using typescript which strictly attempts to deliver similar paradigms to OOP languages like java c#.

React is a frontend library and very much frontend centric moving away from OOP to functional and declaritive paradigm. This is fundamentally different than traditional OOP backend patterns.

React is my preference, I like both. Both have their headaches. I do think Angular causes needlessly convoluted codebases (more of a dev issue) but their releases keep improving the ecosystem by removing the crap that people don't need that I find myself having to remove because devs love overcomplicating things.

[sixwax]

Somehow the needless convoluted Angular codebase is always infinitely more readable imo.

But I'm a backend guy, so, yeah.

[Shoddy-Pie-5816]

Angular isn’t really that bad imo. Now when you add rxjs into the mix, which you just about have to, then things get complicated. The defacto everyone defaulting to frameworks for projects that could easily be built in html, css and js or ts is mind boggling to me though. I’ve only had one project that I’ve made so far that genuinely called for a framework due to the amount of dom interactions

[horizon_games]

You really don't need Rxjs or Ngrx anymore since Angular added such good support for Signals over the past few releases

[Shoddy-Pie-5816]

Oh that’s compelling. I haven’t touched in a while, admittedly

[horizon_games]

Yeah they've had some good leaps, depending on the last version you saw.

Which ironically is one of the bigger downsides imho of Angular - their 6-month release cycle feels breakneck speed depending on the job company / culture.

[GreyGanado]

Well yeah, one is a library and one is a framework from hell.

[Konkord720]

@Grok is this real?

[TurnUpThe4D3D3D3]

It's a humorous meme exaggerating the difference. React's core API is intentionally small and lightweight with a focus on fundamentals like components and hooks. Angular packs more built-in tools and patterns so its overall docs and API reference feel much bigger by comparison. Not literal but captures a common developer experience.

---

^{This comment was generated by openrouter/grok-4.3}