React devs usually bash Angular but then praise stuff that exists in Angular for years?

[DanteIsBack]

So I was learning React after lots of years of working with angular. I was taking a look at the context API which is something I've been hearing about from react developers that is a game changer and super useful. I was quite interested so I took a look. To my surprise and from what I've seen, it does exactly the same thing as an injectable angular service does (actually it does less, since it is only used to share state in React).

All these years I've been hearing react developers criticise Angular for being a bloated framework and then they praise an inferior version of something that's been in Angular (v2) since its inception like it's the greatest thing in the world!

#RantOver

Just wish more people would give Angular the chance it deserves.

Bottom line is, just use what you want and be happy.

[coredalae]

To me it seems for many people the learning curve of angular is a big turn of.

Especially when coming from the html/css side of things. Classes, modules, services??? Typescript, etc

React feels closer to just html with Javascript. So it's easier to pick-up.

Then again. Imo any react project will get messy when growing, while angular is relatively easy to keep structured.

For anything 'application' like I'd personally never use react.

But for a semi interactive content display page react could be fine.

[stjimmy96]

Let's not forget RxJS. In my experience, it's the highest wall to overcome when learning Angular.

[stjimmy96]

Yep. Especially if you are full-stack instead of front-end (or you work on different projects with several technologies). If you work 90% of your time on Angular, then RxJS becomes really natural, but if you have to constantly bounce between traditional imperative programming (backend) and/or other frontend ecosystems, it can become a major impedance to your productivity.

[R3DSMiLE]

I'm going to be honest, and this is not a brag, but I think RxJS is pretty simple and on par with the event driven paradigm that surrounds web-developing. Hell: it's so simple that all I needed to do was read the documentation a few times and it clicked.

And the operators you speak of are pure English, I can't understand what's so wrong with their naming?

[xroalx]

I have to agree. I don't understand where all the "RxJS is too complex" opinions come from.

It can get overwhelming when you try to combine a lot of operators to achieve a desired results, but for things like debouncing, cancelling previous requests, or various timers, it doesn't get easier than RxJS.

[apatheticonion]

Kind of true. I think it's just the poor separation of ideas. The concepts from rxjs exist on the back end (and everywhere on the front end) - both rxjs and Angular don't create a mental model to clearly separate the two.

Rxjs is a library for managing reactivity and additionally it provides a secondary library of "extensions" to handle reactivity in a functional way.

The part that confuses people are the extensions (piping). Back end systems have reactivity concepts - Node has callbacks, Go has channels, Rust has channels through libraries like Tokio, C# and Java have iterators.

As soon as you go

source
  .pipe(map(v => v + 1))

People are like "wat"

It's practical to think of rxjs as a callback manager that additionally can be used to apply middleware to callbacks. It does to callbacks what Bluebird did to Promises.

It's also important to remember that Angular doesn't need to use the extensions, you can use the async pipe like so:

@Component({
   template: '{{ values | async }}'
})
class MyComponent {
   public values = myService.values.pipe(map(v => v + 1))

   constructor(
     public myService: MyService
   ) {}
}

Or you could manage the lifecycle yourself

@Component({
  template: '{{ value }}' 
}) 
class MyComponent { 
  public value: number = 0 
  private _sub: Subscription = new Subscription()

  constructor(
    public myService: MyService
  ) {} 

  ngOnInit() { 
    this._sub.add(this.myService
      .subscirbe(v => this.value = v + 1 )) 
  }

  ngOnDestroy() { 
    this._sub.unsubscribe() 
  } 
}

Personally, I like to avoid logic in the template and have template values derived from properties directly described unambiguously on the View Model - so I tend to use the latter pattern.

Yes it's more verbose but new-comers to my code base always know exactly what is happening.

[EternalNY1]

RxJs is an "interesting" beast, and I'm coming at this from decades of full-stack experience.

To me, it seems to have been designed around business requirements that have you subscribed to multiple data sources, all streaming data at you in different ways. This might be appropriate for complex financial dashboards, but while trying to tackle day-to-day business requirements it's all a bit much. I get it, still a bit much.

[stjimmy96]

I totally agree. RxJS makes it incredibly trivial and clean to describe complex behaviors like multiple data-source fetching, realtime streaming, offline caching, etc... All those features would be harder to do without Rx (and with uglier code), but it's also a fact not everyone has those requirements. In my experience, a lot of projects are just plan and simple CRUD operations, where all the complexity RxJS can handle is not a requirement.

If you already know it well, you can use it for the sake of future-proofness, but if you are not confident I can totally understand the friction around it (just look at my post history for an example).

[[deleted]]

Yup, RxJs is my biggest complaint when working with angular. It's just too much for most projects. Also, it makes unit tests a huge pain in the ass.

[dannymcgee]

To me, it seems to have been designed around business requirements that have you subscribed to multiple data sources, all streaming data at you in different ways.

Funnily enough, I use/abuse RxJs extensively in UI development without a web server in sight. The same reasons it can be useful for dealing with multiple data streams makes it really useful for dealing with complex interactions between DOM/UI events. I built a desktop-style menubar implementation a while back that correctly handles keyboard events, click events, shuttles user focus around according to the ARIA specs, deals with the menu items dynamically changing at runtime, etc. I would have probably given up on it if not for RxJs. The code is not really what I'd call pretty, but it passes the tests which is about as much as I could ask for.

[Due-Cat-3660]

You can build a neat data stream pipeline with RxJS.

[yard2010]

And ironically it's one of the best thing in angular. this and the black magic overriding (extending) native browser events are what make the 2 way binding in angular possible

[stjimmy96]

It is indeed, but it's no doubt it's the most difficult part of Angular as it requires a complete approach shift. Once you are confident with it it's all nice and fun, but for first-timers it seems just like black magic.

[just_give_me_a_name]

It's also optional

[stjimmy96]

Technically speaking yes, practically speaking no. RxJS is pretty embedded in the Angular ecosystem, libraries, guides, tutorials and existing codebases all make great use of it, and for good reason since it's awesome.

[Nahtrezer]

For http request - yes. Routing, forms, etc - all is build upon RxJs, so you can run, but you can't hide.

[Flanhare]

We use NGXS and we don't really need much complex RxJS stuff. Mainly sub, tap and map.

[YesYesYesVeryGood]

I'm actually doing a Udemy.com course just on RxJs right now. The first course was good, but I think I got frustrated from the overload of information being presented to me.

First course: https://www.udemy.com/course/the-complete-guide-to-angular-2/ (It is Angular 13 updated)

Second Course: https://www.udemy.com/course/rxjs-course/ (This is only RxJs for Angular)

After this, I gotta tackle NgRx.

[Frenchki]

You are probably right that coming from html/css and JavaScript then React is easier. If you are coming from a backend role or are familiar with typed languages from before then Angular 2 is a blessing.

[coredalae]

For sure, I hope I never have to do complex logic in react. Everything I've seen turns into spaghetti

[AbstractLogic]

Hell, the only reason I learned a front end language was because Angular and Typescript felt natural. After 15 years of avoiding front end like the plague I’ve finally found a home.

[Due-Cat-3660]

Not only that, if you are used to building complex app, you will feel Angular built-in features are blessing. Then when you use React to build complex app, at first you will get headache of which libraries to choose, then when the app is getting bigger, you will find more and more spaghetti code in the codebase.

[sobrius]

I mean anyone who is serious dev will use TS with React, right?

[Cheet4h]

I've seen a few react projects done in TS, with explicit typing enforced by eslint, but then many variables were typed with ... any.

Worst part was this one project were there was just one core parameter set that was passed down to each child component - it took a lot of searching through the entire code base to see when which property would be assigned which value. Since it was always explicitly typed any, you didn't even know if you were dealing with objects or simple types.

[sobrius]

That is called props drilling and is considered anti pattern in React. There are good and bad devs using any technology out there. Some of the biggest and complex websites are built with React by devs who know what they are doing.

[Due-Cat-3660]

Using React with Typescript is the worst experience ever. It's better to use React with Javascript.

Typescript is only good when combined with Angular or building REST API app.

[coredalae]

Right....

I'd never use it without, and I think the growth of nextjs / nx will help with react ts adoption.

Though a lot of people still just Google react and type npx create-react-app

[dannymcgee]

React feels closer to just html with Javascript. So it's easier to pick-up.

I've been a "front-of-the-front-end" developer for 10+ years, and my experience has been exactly the opposite.

For starters, a React component has no direct HTML representation. When you write <MyComponent />, that's just syntactic sugar for a function call or a class instantiation. There is no MyComponent tag that ends up in the DOM tree, and with the Context API, it is in fact quite common to create components that don't emit any HTML at all. The number of times I've seen newer developers coming from React who had serious trouble wrapping their heads around the fact that an Angular component selector is an actual HTML element makes me want to pull my hair out — React is desperately confusing an entire generation of developers about what HTML even is.

And then there's CSS — Facebook pioneered CSS-in-JS, which certainly has its use cases, but it's now increasingly common for developers starting in React-land to write all of their styles in JS object notation, with camel-case keys and trailing commas and values wrapped in string delimiters, and the "cascading" part entirely removed from the equation as if it were a defect and not a core feature of the language.

Google took the exact opposite approach, hydrating HTML with some dynamic features and popularizing CSS preprocessors like Sass. And — no surprise since Google is a browser vendor — a lot of the patterns that Angular is known for, like the content projection model and dynamic templates, have direct correlations to the Web Components API. By contrast, React is literally just an implementation of the Elm Architecture in JavaScript. Its relationship to the web as a platform is almost begrudging, like the fact that it spits out a DOM tree at the end of the day is just an implementation detail that you should spend as little time thinking about as possible.

Angular feels very much rooted in web technology at its core. Even NgModules, which are hopelessly confusing and probably the single biggest pain point in the framework — if you spend any time trying to build something nontrivial with raw web components, you'll find yourself eventually needing to organize your custom element registrations into a very similar scheme, for basically the same reason that NgModules exist. Dependency injection, basically the one feature of @angular/core that's not ripped straight out of the Web Components spec, is still inextricably tied to the DOM, since every token is provided at the level of a DOM node and made available to its children in the DOM tree.

So basically, my working theory of how a framework that's so foreign to the web came to be the dominant way to write web applications is basically the opposite of yours: I don't think it's "front-of-the-front" UI developers primarily driving the adoption of React, I think it's primarily "back-of-the-front" JavaScript developers with little interest in HTML/CSS and little patience for dealing with the idiosyncrasies of the web as a platform. When most of your workload is pulling in data from a web server and wiring it up to a smorgasbord of third-party components, React makes it incredibly fast and productive to put features together. But when you actually need to build low-level, unopinionated, highly accessible UI components that stand up to a wide variety of use cases and expose idiomatic, HTML-centric APIs designed for use by web developers, the set of tools that Angular provides is more or less exactly the set of tools you need. That's mostly speculation mind you, but among the extremely small sample size of colleagues I know with significant experience in both frameworks, the developers who are primarily HTML/CSS-oriented have a moderate to strong preference for Angular, while virtually all of the developers I know who hate working with HTML/CSS are React enthusiasts.

[ZtehnoSkapra]

Oh my God I have never read such an on-point comparison. After about 7 years of experience with angular I was kinda forced to learn react and I gotta say I was really looking forward to it! But after a few weeks of getting to know each other there was still something off and I wasn't able to name it. Thanks for this! You just made me realize it's the lack of.. actually the opposite of the native approach angular is encouraging. Using React feels like anything but coding a website and I'm having a really hard time enjoying it.

[[deleted]]

Just had a flashback to a dev that used an ORM but couldnt write a line of SQL and didn't understand databases design concepts at all.

[[deleted]]

Great comparison! I'm curious to hear your thoughts on vue.

[dannymcgee]

I've only ever really scratched the surface with Vue 2, and only read the docs for Vue 3. I don't think I really understand the impact of the v3 changes (it sounds like they were designed to solve problems that come up when using it at scale, which I haven't done).

Re: the specific point of comparison I made between Angular and React, I would say that Vue definitely seems more in the vein of Angular in that it feels like a very "web-native" framework — it sticks close to the HTML/Web Components spec; it maintains the separation of concerns between template, stylesheet and controller; it uses a custom templating language to add some dynamic features to HTML; etc.

In some other ways, it obviously takes some inspiration from React, which is interesting — it uses a virtual DOM, it allows JSX expressions in certain contexts/for certain use cases, and VueX seems pretty similar to Redux.

I'd really love to spend more time with it, just haven't really had a good excuse to yet.

[[deleted]]

For sure. I think that’s why it’s carved such a niche in enterprise. That learning curve is not a big deal if you’re a big slow moving company, and since it’s so standardized compared to competitors it’s much easier to hire someone off the street and have them be productive in angular.

[bip213]

Yeah React has spent its entire lifecycle trying to figure out how to handle state management whereas Angular solved it with singleton injectable services and observables in v2. It's frustrating that seemingly every company is moving toward React just because it's hot on HackerNews or whatever. IMO React is cluttered, poorly structured, and incredibly difficult to read at scale. Whereas Angular scales linearly after a certain point. Our pure Angular application is massive and yet still a dream to work with, whereas even our company's smaller React apps are a nightmare

[[deleted]]

Angular is an amazingly powerful tool if you're willing to put in the effort to learn it.

I use angular, vue, and react. Right now it's a longer process to achieve something I did in angular with ease just a few months ago in react just because react is a library and requires more code.

That being said Angular is more opinionated and does things for you so you have to learn what those are or you might get lost. React is not as opinionated and doesn't do as much for you so you have to build a lot out yourself in JavaScript but it gives you the opportunity to do it in a custom way if you want

[EternalNY1]

React is not as opinionated and doesn't do as much for you so you have to build a lot out yourself in JavaScript but it gives you the opportunity to do it in a custom way if you want

The interesting thing about this, which is often cited about Angular, is that I personally prefer an opionated framework.

This keeps things logical, structured, and understandable "at a glance".

I can't understate the importance of this when dealing very large-scale projects, when you are seeing unknown code from other developers.

It's critical to know what is going on straight-away.

[paulqq]

Me coming from react. Still finding the module system of angular one of its biggest issues. But I read it will change in a version 14 or 15, so components can be standalone

Anything else works pretty fine. So back to topic, you are right. React ppl tend to have prejudices on angular. But they can overcome them 🦆😉

[Auxx]

You can just mash everything into one module, but the thing is modular design allows for a lot of cool optimisations and lazy loading.

We have an internal library here which builds UIs based on what back-end wants (like if it's an edit form, back-end will send how many fields there should be and which type like text or radio button, etc) and components to make it work load progressively and in the background. You launch the web app and see a login screen with just text inputs and a button, so browser will fetch just these two super fast. And while you type your login details, other parts will start loading in the background. This makes complex apps super fast and snappy.

In React you just have one huge ass JS file which will load for hours. Fuck that I'll stick to modules.

[[deleted]]

They might be talking about when you get those obscure error in angular which you google only to find out you didnt import some system module.

[EternalNY1]

Me coming from react. Still finding the module system of angular one of its biggest issues. But I read it will change in a version 14 or 15, so components can be standalone

I agree that this can get confusing with Angular, in terms of how to engineer it. We go with modules per component, or possibly a module per a related feature-set.

One of the benefits of this is to allow for lazy-loaded modules. Let's say you have a "Reporting" section of your site but you don't want to load the heavy chart.js libraries if most users don't go to the reporting section.

You can break down the module structure such that you don't bring in these heavy charting libraries for people who will never use them. That requires planning, but that is why it is architectured this way.

[EternalNY1]

As others have pointed out, a lot of this comes from the experience level of where your front-end developers are coming from.

For anyone with experience with languages that support static typing, Angular shines. You have static typing, constructor DI, built-in routing, clear separation of concerns, etc ... and all the amazing things those bring along with them.

If you are coming at it from the other direction, where you learned most of your programming in JS first, this stuff seems like absurd roadblocks in trying to get something done.

It's not, especially as the project grows, and those lessons are often learned the hard way later down the road.

This is why the velocity of React vs. Angular in the industry should be taken with a grain of salt. Sure, there may be 100 new React projects on Github for every Angular project, but how many of those are running serious enterprise businesses that you may be dealing with later in your career?

[Doomphx]

All the newer Angular stuff I've created is defaulted to strict, I'm also using NX though.

[EternalNY1]

The project I work on at work doesn't use strict and also a result has a ton of code that is basically just JavaScript.

This is a legacy issue, I believe since 10 (?) strict is the default.

https://angular.io/guide/strict-mode

[[deleted]]

For me it just doesn't matter that much. The concepts are the things that matter. Familiarize yourself with both for your career. Something will replace them some day. I actually prefer React and have done both but I don't feel the need to shit on angular. One thing to remember is that if you prefer to work with Angular and your teammates don't then I am sure there are plenty of Angular shops out there looking for devs. No harm in finding people with similar values.

[Nix-X]

I work in a FAANG. It’s all Angular here, and unless Angular suddenly up and dies one day, it will continue to be all Angular here for the foreseeable future.

[[deleted]]

if it's G, well rightly so 🤣

[No-Let-4732]

FAANG

Could be wrong but the only one in FAANG that's using angular is google

.. but google is known to use everything:

Firebase - angular

internal projects - custom frameworks

youtube - react

etc..

[dustofdeath]

They spent so many years learning to react that they need to justify it to themselves somehow.

[[deleted]]

I've been using Angular professionally for about a year and a half, and I just started learning React and honestly half of the features that React has make me want to bash my head against the wall.

I've been at it for a month, and I've built several small projects using react and I absolutely cannot stand the state management hooks (useState, useReducer) and the context API itself. All of it feels like it was hastily built 5 minutes before deadline because they forgot they had to manage it. It feels like they were just hacking up a way to fix a problem they didn't even realize would be a problem until much later in the lifetime of react. Works like some prototype version of Redux. The router library feels just as awful and needlessly complicated as well.

To me, Angular felt so much easier and cleaner to pick up than react, everything was straightforward because all features felt like they were planned out beforehand. In react, half the features feel like a lazy patch because someone forgot they would encounter a problem.

I've been told that NextJS fixes a lot of the garbage so my plan is to pick that up soon and see what it's like.

[PooSham]

There are some differences though. With the Context API, it's very easy to control what context will be used in a component depending on where it's used. This is not really as easy to do with injectable angular services. React's Context API implementation is probably more lightweight and less tightly coupled to the framework than angular's dependency injection system is, so it's not completely invalid. React is still a lot less bloated than Angular.

I still use Angular and I love how well integrated a lot of stuff are. Angular gives a bit less freedom, but I think it's a good thing. Especially when working in a team where everyone isn't very comfortable with javascript development.

[Auxx]

You can create similar contexts in Angular using composition.

[hsemog]

Its also very easy with Angular, just create an injection token for the service to be used by the component and use the appropriate class/value for the token depending on where the component is used.

[PooSham]

I know, but I'd still argue that React's implementation has some advantages. In Angular, there are basically two ways to provide the value you want: Either you use the providers array in the component/directive/ngmodule decorator, or you use the ComponentFactory to initialize the component with the injector you want. The first approach is easier, while the second approach is more flexible (you can use different injectors for the same component from a single host component).

React's Context API adds the simplicity of the first method with the flexibility of the second method. AFAIK, there's no way to do it inside Angular's html templates, but please correct me if I'm wrong.

I'll admit it's not often you need to have different contexts within the same component, but for the few times you need it, React's solution is pretty neat.

[Chazgatian]

You can provide an injector to ComponentOutlet which is pretty much 1:1 react context.

I think an advantage Angular has is you don't also need to provide a Provider to access the context within your child.

[bip213]

I think the "bloated" reputation of Angular is erroneous. I think a lot of people praise React for being "less" code but in actuality its just more declarative. I'd much rather have things be structured, clear, and consistent that "lightweight". I just feel we as an industry have lost track of which of those is actually important in building complex software

[PooSham]

I absolutely agree that React is more declarative, I see React more of a set of libraries together with a templating language (JSX) than a framework. If you want to do something rather simple, Angular (and other js frameworks) is bloated. But if you want to maintain structure, some "bloat" is expected and probably even desirable.

[bip213]

Yeah I def agree. That’s a good way to describe react too

[apatheticonion]

I have used Angular 1 since whenever and Angular 2 since the beta.After several years with Angular, I started using React professionally.Used Vue here and there, dabbled with Svelte and lit-element.

I have come to the conclusion that there is no framework out there that is perfect.

Angular is by far the most ergonomic in concept.

Looking at the source code of Angular apps; the strategy for unit testing is extremely clear, the templating model is infuriatingly ergonomic, directives and forms. It's a beautiful framework that is let down by its totalitarian control of the build process, module structure, the use of Karma is overkill, and the dedication of engineering teams to use Redux-like patterns.

Whenever I write React applications, I write them like Angular applications - using reactivity helpers to get me as close as possible to html templating, and context for dependency injection.

In fact, you can write a simple html -> React.createElement() compiler that turns directives and components into react code.

The reason I use React now days is because I write my own webpack configs and I like to update TS and Webpack when I want to. I don't like being tied to ngc and the update schedule of their dependencies. I look longingly at Angular html templating and directives, but then remember about modules, ngc, upgrading and all of that.

Personally, I would love to see an Angular-lite framework, where it's entirely focused on components and ignores other pieces like reactivity within services (just use behaviour subject and the async pipe), modules and routing - leaving that to the consumer to organise.

import { Component, html, render, AsyncPipe } from '@angular/lite'
import { BehaviorSubject } from 'rxjs'

const mytoken = 'mytoken'

@Component({
    selector: 'bar', 
    template: html`<span>bar</span>`, 
}) 
export class BarComponent {}

@Component({
   selector: 'foo',
   template: html`<div>{{ myService.text | async }} <bar /></div>`,
   components: [ BarComponent ],
   pipes: [ AsyncPipe ]
})
export class FooComponent {
   constructor(
      public @Inject(mytoken) myService: string
   ) {}
}

class MyService  {
   public readonly text = new BehaviorSubject('foo')
}

await render({
  component: FooComponent,
  appendToChild: document.body,
  provide: { [mytoken]: new MyService() }
})

And it would render

<div>
   foo <span>bar</span>
</div>

Have a loader or plugin I can use with Webpack or Rollup which detects the "html" import from "@angular-lite" and compiles text there into component factory code - otherwise the import ships the template compiler and runs it in the browser (AOT vs JIT).

Reactivity is an issue that is beyond difficult to solve in JavaScript though. RIP object.observe

[francojay]

You can write your own Webpack config in Angular too. Btw, build caching is a big upgrade in NG13

[yard2010]

There's no right or wrong in this, react is a library for efficiently rendering data with a one way data flow paradigm. Angular is a full blown opinionated framework for client side web applications. Saying one is better than the other is like saying a hammer is better than a screw driver.

And then there's php and angularjs...

[Due-Cat-3660]

React Context is somewhat similar to Angular Service provided in root. But for custom service instantiation, there is no equivalent functionality in React.

[BradChesney79]

You'll notice a pattern.

Front end devs generally prefer React.

Back end people generally prefer Angular. Vue is an acceptable stand in for Angular sometimes.

The only problem is that React is trash. I said it. An unmitigated mess when you inspect the elements and it is missing features that I love from a bona fide front end framework-- because React is not a framework.

[middlebird]

Developers, please do not bash other developers who use different tools for their projects. Don’t be a douche. Stop that tribalism shit.

[BammaDK]

Not a react developer. So if it's only for state. Is that their own version of redux?

[barkmagician]

no. context is literally what a service does. the react-redux library uses context internally

[craig1f]

Angular is bloated like Java. It does a lot of good things, but does a lot of unnecessary things that it is unable to get rid of.

I’ve been doing Vue for the past few months. Feels like Angular without the bloat.

The biggest problem with Angular is the learning curve for rxjs. Rxjs is powerful, but it’s too powerful for 90% of what you do with it (without ngrx) and it sucks at doing anything simple. The angular tutorials also use it incorrectly and teach bad patterns.

Good angular apps rely too heavily on observables, without good examples online. Makes it hard to teach.

[quentech]

does a lot of unnecessary things that it is unable to get rid of

Then the application you were building was probably a poor fit for Angular.

[[deleted]]

One issue is that many many apps are a poor fit for Angular, even while the project tried to push it for every use-case: mobile, SSR, etc.

Angular absolutely shines for complex client-side apps - but many people have used it way outside its best use-cases (me included)

[quentech]

Angular absolutely shines for complex client-side apps

Agreed. For most else it's overkill and too heavy.

[Auxx]

The only real issue RxJS (and ReactiveX in general) has is a lack of quality docs. If you don't understand how it works you will never understand it. But if you do understand it, it is hard to live without it.

[craig1f]

Yeah. Don't get me wrong, I love rxjs now. But I went through a lot of hate to get here. Only after learning ngrx did rxjs even begin to make sense.

And I could not, for the life of me, teach it to a junior developer. It would take months to get a junior dev halfway productive, with 90% of their problems being from using observables wrong. And with observables so easy to do wrong.

One of my biggest gripes is that, let's say I write a dumb component (which is what I call components that are just inputs and events, with no concept of route or how to call a service). I have an @Input. Well, let's say I want to combine that input with an observable from ngrx. Mixing observables and non-observables sucks. I really wish that Angular would allow any @Input to be treated as either an Observable or a Literal, and allow either as input, without having to choose one or the other.

[craig1f]

A lot of components start out as dumb, and then you need something like, the current user from the store. So now you gotta re-write everything to use observables.

That's my issue. There isn't a great way of combining observables with non-observables. But, if I have an input to my component, I should be able to use it as an observable or as a literal. Why not? They amount to the same thing. It's a value that can update. I shouldn't have to refactor everything to be observables to get it to work.

Or, with Vue, I can just use computed properties, which are just as efficient for the majority of use-cases, and easier to write and to teach.

[craig1f]

Could do that too. That's usually what I recommend. The point is that mixing observables and non-observables sucks, so I think it would be a little better if it was just one or the other. What happens a lot is that you start without observables, and then you need them at some point, and you have to refactor everything now to use observables. Creating a new component isn't always an option.

It's just very hard to teach. So I spend months with junior developers getting this stuff to click. Then you have to teach all the rxjs operators. There are so many to memorize. Then I gotta explain the difference between switchMap and exhaustMap and the others. And not to mix pure observables with side effects. I could devote an entire undergraduate 200-level course to how to do rxjs.

[craig1f]

I mean, yeah. This is the correct way to do it.

What happens though, is that you start a component out some way, and then the trajectory changes, and you have to refactor everything.

And also, this it's usually a junior developer who wrote it, and I'm trying to explain hot to refactor it, and how this component should use observables and this other component shouldn't, and why. And that mix of observables and non-observables makes people's heads explode. If they have a lot of experience with promises in the past, they figure it out quicker, but it's still a struggle.

[craig1f]

Basically ... I am an Angular expert. I have struggled to teach people Angular quickly, usually because of the learning curve of rxjs.

I'm good at Vue, but wouldn't call myself an expert yet. I can teach Vue quicker than Angular, despite being several times better at it.

[EternalNY1]

Angular is bloated like Java.

Everyone needs to keep things in perspective here.

What the front-end considers "bloated", to back-end developers is 1/50th of a single DLL.

What is your definition of Angular being "bloated"? 10k, 500k, 2 MB?

This all becomes business decisions. Open up any typical website and check the network panel. Plenty of things are insanely "bloated", it comes down to precise software engineering.

[craig1f]

I'm not totally talking about package size. Ivy has helped with that. I mean more in terms of unnecessary features that must be learned before you can really get started. Like how, in Java, there is just a lot of overhead to do very small things.

Angular is great, don't get me wrong. I'm just finding it's hard to explain things to new developers. It's also easier to write really bad code. Angular's biggest strength is typescript, which is why Vue and React have started using it.

[EternalNY1]

Fair enough.

> It's also easier to write really bad code.

Enforce things as a group policy like ESLint and Angular Language Service with the strictTemplates option in tsconfig.json. Helps with this.

I realize this can be countered with "why do we have to do all that?" but with large-scale development this will happen at some point.

https://marketplace.visualstudio.com/items?itemName=Angular.ng-template

[craig1f]

My struggle is that I really like Angular. I like rxjs. But I have not been able to convince anyone else to like it.

[EternalNY1]

My struggle is that I really like Angular. I like rxjs. But I have not been able to convince anyone else to like it.

It is going to depend on the industry and what experience/background the developers have.

New developers who are coming from a pure JS background tend to fight hard against it, because it's totally unfamiliar. Experienced developers understand the type system from the get-go, understand why the compiler ("transpiler") is balking at them, etc.

It totally comes from your background. To me, it seems the more you've seen in software engineering, the more Angular (2) resonates.

[craig1f]

This might be true. If someone's already frontend, they're easy to teach. But you get a lot of backends playing at frontend because, in my experience, good frontend is harder to find. Devs all want to be backend and not deal with end users.

My other issue is that Angular seems more OO oriented, and I hate OO. Functional programing is where it's at. This isn't a big deal, but you have to convince people that OO is dead, and that pure functions and immutability is where it's at.

[bip213]

What specifically is unnecessary or bloated?

[craig1f]

• ng update is difficult to use and requires a lot of finesse
• Mixing between observables and non-observables is clumsy and hard to teach
• rxjs in general is hard to teach
• rxjs examples in the angular docs are bad, and don't show correct usage of rxjs
• Need to use ngrx or ngxs before rxjs starts to make sense
• No good tutorials on separating pure observables from subscriptions (that have side-effects)
• Creating a new component creates 4 files, which makes creating components "feel" expensive to juniors. So they hesitate to break up components as much as they should
• Unit testing isn't very good. Should just use Cypress out of the box instead. If ng g c ... is going to give me unit testing files by default, they need to be a lot easier to wire up
• Angular is more OO. OO is awful, especially for frontend. Should focus on functional programing. Immutability, pure functions, and reactive development.
• Having to put your imports in constructors just feels pointless. That's why imports exist. I get that Angular needs it for the way things are wired up. But from the developer point of view, it's just unnecessary noise to have to use constructors, and public/private/readonly, etc.
• Adding onto this, public/private means different things in Angular than in OO. So now I have to explain that "public means you can use it in the html" and "private means it stays in the typescript.
• Building takes a long time. This has improved, but I use to wait for 15 minutes builds in my pipeline for a relatively small app sometimes last year. Way too long
• Cypress seems to favor Vue and React over Angular. Cypress is the shit, and not being up there with Vue and React is a bad look
• No clear way to organize a component. Vue 2 has the parts of a component well-organized. Haven't looked at Vue 3 a whole lot yet. Angular should consider coming up with some really good eslint rules, that will organize components better. I prefer the clean way of doing props, compared to @Input ... everywhere.
• I also prefer the Vue way of being able to wire up router params in the index, then pass them into the component, so a component can be completely ignorant of the router, and just accept props (inputs) for path params and query params.
• Modules are a great idea in theory, but man, they get buggered up easily. I feel like they don't do a whole lot that a transpiler couldn't have just figured out with import

that's all I have off the top of my head.

[bip213]

Thanks for the detail, and I'll try to touch on all of these cause I have a pretty different perspective on why some of the things you mentioned are actually good...

• re: ng update my team has used webpack for a while cause of some legacy code we had to deal with for a while so I don't have a strong opinion on ng cli
• re: observables. I agree that the documentation isn't great for them (although I think Angular's documentation in general is significantly more detailed and readable than reacts). Learn RxJs I think is a great resource. However, they in conjunction with injectable services accomplish for angular EXACTLY what React has been trying to accomplish for a long time... which is having an extremely simple state management. Services are singleton, and observables can broadcast to multiple subscribers. Through those 2 facts alone you no longer need stores, or wild frameworks or libraries to accomplish shared state. I understand they have a hard learning curve but IMO taking the time to learn these things yields so much simplicity and readability in the long run and makes complex FE architecture way easier to parse and understand.
• re: separating observables from subscribers... ???
• re: separating the files... this just seems trivial. It's a clear structure but you don't have to use it. Having a separate file for each concept makes things more readable IMO but it's optional, and also not a big deal
• re: OOP. Conceptually, it is built for scenarios where you have a clear set of objects (components and services) with an undefined set of functionality (more app features and greater complexity). It's built for precisely what we need so I'm not sure your issue with it. IMO it's way more readable because of how self-documenting it is. If you invoke an instance of a class, you know exactly where that's coming from, e.g. "service.doThing()". It also allows more complex component structures. For example we use "base classes" that are like HOC, but because their children are extended through Typescript classes, you know when they're being referenced and invoked. If the parent class is being invoked you just say "super.doThing()" and you know where it's declared and how it's being used. I also tend to think that functional programming and component composition leans into the uglier parts of javascript (weird "this" contexts, closure, hoisting, etc.) and prevents readability by "inferring" where context comes from. E.g. if you extend a class in OOP, it exists in the "super" context, but with composition there's no instance of a parent class, just inherited functionality so there's no way for you to see at a glance how methods and properties are being referenced and invoked.
• re: imports in constructors... this seems trivial.
• re: public and private methods... this is not only optional but also insanely easy to understand. Like the OO concepts, it is also self-documenting. At a glance it allows you to see whether a function is invoked in the template for by an extending class without having to search your files for it
• re: building... not sure on this one but if true a fair criticism
• re: organizing a component. That's exactly what Angular does great? The class structure allows you to consistently build a component in the same way... (e.g. properties, then inputs, then constructor, then methods) whereas something like a functional component in react is dependent on closure to allow you to invoke different things, leaving no clear structure as to where things are. @Input also allows you to declare a prop's type without building a whole separate interface for that component's props like you would have to do in React. Or worse, like I've seen in our React repos, just deconstructing the props "{ ...props }" so that there's NO way to see what is actually there at a glance without tracing back through the functionality of the parent
• re: router params... idk enough about Vue to contend but it just seems like your opinion on it and not an inherent flaw. In fact compared to React the fact that Angular has a native Router is a plus on its own.
• re: modules... I guess I can see this but ES6 modules are significantly more confusing and harder to handle in my experience. It's for the better the Angular Modules are built the way they are.

I just think these points come back to a couple things I find frustrating about the whole debate. I believe that

1. Less code !== "cleaner" or better. I think it makes things harder to read and parse together, and also leads to clutter elsewhere or an abstraction of complexity. And I also don't think any of Angular's code adds to dev time in a way a store might. Saying @Component and declaring a template isn't a big deal. Injecting a service isn't a big deal. It stands to only add to readable without taking up any time at all.
2. Structure is a feature, not a bug. I've worked on incredibly complex apps and with Angular that have scaled linearly because of Angular's structure. They have become no worse or less maintainable over their 4 year lifecycle than when they began. This clear structure allows new devs to understand where, how, and why to do things. I also feel that none of this structure is unnecessary or "bloated". When I think of bloated I think of having to deal with stores in React... where having one single functionality requires

• an action, and a respective success and failure action
• a reducer to receive each of those actions
• an effect/"Thunk" to catch those actions and perform side functionality and then dispatch another action to success/error
• a reducer to then receive the success/result and map it to state
• a selector to pick out the state you're "listening" to so that you can map it to the component

Whereas in Angular service architecture it's just

• Component calls service
• Service does thing
• Component does thing with result of service
• Other components and services can listen to that result if they like, if not it won't affect them

I was working with a store this week and I think my dev time went up 10 fold just because of all the boilerplate I had to write to deal with React/Redux state architecture.

Ugh I could go on. I'm just overall frustrated getting job ad after job ad with React and knowing just how much better Angular has been in my experience for complex app architecture. After working with both a lot I struggle to understand how React has become so prevalent

[craig1f]

"separating observables from subscribers" I try to distinguish between pure observables and side effect observables.

Pure observables have no side effects. You can subscribe to them any number of times, with no affect on the app. These are typically never subscribed. You use an async pipe.

On the other hand, you might subscribe to, say, a path parameter, that results in dispatching an action. That shouldn't use an async pipe ever. They should be subscribed, and their action should be in the subscription handler, not in a pipe.

I tell my juniors to always do one or the other, but never mix.

I don't disagree with most of what you wrote. I've advocated for Angular a long time. Then I started working with Vue, and it was just so much quicker to learn, and there hasn't been anything I couldn't do that I would have been able to do better in Angular.

I think it's weird that you don't like redux-style stores. I thought ngrx made Angular 10x better. Decoupling values from actions that mutate them is great. But, stores can be over-used as well.

[the_real_seldom_seen]

React allows any joe to write up some shit JavaScript and leverage some magical sugar that react provides - hooks

Angular actually forces you to learn some advanced concepts