4 ms·

To join in the gripe session because Angular has been hurting me for months: I'm in a consulting firm and generally we have a lot flexibility on project stacks.

To join in the gripe session because Angular has been hurting me for months: I'm in a consulting firm and generally we have a lot flexibility on project stacks. I've been really happy with React on the projects I've done with it. I've recommended React on every following project. Lately I've been getting a lot of pushback from some clients that it "has to be" Angular because "they know it", and got a lot more pushback from colleagues that they wanted it to be Angular because "they know it". Find out a few months later that everyone "knows it" only in the Stockholm Syndrome bare minimum "checkbox on a resume" fashion and suddenly I've become the expert on Angular in the company because I have problems to solve and know one else that supposedly "knows Angular" actually knows how to solve them. The more I become an expert on Angular the more I hate Angular and would rather be back in React. (But of course it is too late to switch stacks now, given project deadlines, etc.) > There's never anything obvious when it comes to analysing the bundle and it seems we're using everything we need: Angular, Material, RxJS Yeah, that's exactly the major sources of bloat in Angular. Angular's runtime and core components are extremely fat despite how much they keep claiming is compile-time optimized. I'm terrified to look at the source for HttpClient because I cannot imagine how it possibly is big enough to explain its huge {minimized, gzipped} bundle size. That's just one Angular component in the vendor chunk that "has to be there". Angular Material is another huge source of bloat and a lot of what I've been doing is removing it as much as possible. It seems like everyone throws in Angular Material feeling like it is a "best practice", but "no one" seems to like its styling or behaviors out of the box, put a ton of work into redoing its styling/behaviors in a complicated and bespoke way in nearly every usage and end up burying the already extremely bloated Angular Material components under whole new onion layers of their own bloat. Every time I dig into one of these bloat onions I seem to find it easier to write a fresh component from scratch and get rid of the Material dependency altogether. RxJS is also huge, and it's a grand source of continuing disappointment with Angular how wishy-washy it has been with respect to Observables. If you are going to require a giant library like that, at least commit to it. Of course if Angular actually committed to Observables that might lead to using a lighter library instead of bundling the kitchen sink that is RxJS. (For several years I worked in an Observable focused React-like called CycleJS and one of the big moves CycleJS did primarily for bundle size reasons was switch to an "RxJS-lite" library named xstream.) As someone that actually understands (and heavily uses Observables) it just absolutely floors me at how bad Angular is with them, almost like it is designed to encourage the worst practices for RxJS/Observable code. I see so many components manually (and badly) subscribing and unsubscribing from Observables that should never need to, sometimes simply because the authors weren't aware of the "| async" Async Pipe. (And why should they be, pipe documentation is almost hidden and yet another twisted part of Angular's template syntax with no relation to Typescript syntax despite appearing in places designed to look like Typescript?) Async Pipe is mentioned like a footnote in the Observable documentation that nearly everyone skips past. It should have been the default (or better yet the only way) in the template language: you have Observables, change detection, even "AOT compiled" change detection shouldn't be necessary! Observables should easily replace change detection. Zone.js is nearly entirely bloated redundant nonsense that shouldn't ever exist side-by-side RxJS, and would never be necessary if everything were Observables. It's almost a painful joke at this point how badly Angular makes use of Observables, how it works twice as hard to do half as well if it merely committed to Observables and only Observables instead of this half-Observable slash old school template change detection beast that it is today. Pick one and commit to it and so much bloat in Angular would just go away.

intellix 6y ago
My gripe with RxJS is how difficult it is. I've put thousands of hours into learning it and I just know the rest of the team don't understand the long chains I've written with it. I have the same problem where people are doing backflips to do simple things and I'll come in afterwards like... What ARE you trying to do here? And why are you not cleaning these up? Originally I was trying to stay away from behaviour subjects as recommended by the RxJS purists but now I just want to use them everywhere so its easier for everyone else to get values out of a stream
- WorldMaker 6y ago
  Sure, and that's pretty much exactly why Angular seems to refuse to commit. The EventEmitter in Angular's core is a really odd BehaviorSubject duck, and it shows. That says everything about their commitment to RxJS purity, and that behavior "from the top" leads to how much Angular pushes everyone to want to abuse BehaviorSubject, to do a lot of bad RxJS and never learn to do it right, because it's that rotten to the core. That impression that RxJS is too difficult for mortals becomes the self-fulfilling prophecy that Angular is right not to do RxJS right or commit to it, because it makes doing RxJS right in Angular harder. Half the component examples I see in the wild use RxJS wrong or badly, and of course that stuff gets copied and pasted everywhere. I've already sent patches to at least a few documentation examples that are supposed to be "best practice" that failed to actually live up to best practices because Angular failed them in setting a good example to live by. Angular has created the worst of both worlds that makes RxJS harder than it should be by failing to use it properly (providing too many bad habit escape hatches and failing to commit to it), but also making it almost impossible to avoid and subsequently polluting the entire ecosystem with bad examples, worse documentation, and terrible habits (all of which goes right back up to the top and terrible design decisions such as Angular core's EventEmitter). If Angular committed to being an AOT change detection only system it would probably be much more like Svelte. If Angular committed fully to RxJS it would be something different entirely [0] and maybe sure it would be harder for a lot of devs to grasp at first, but instead of the pit of failure that currently awaits devs trying to learn RxJS in place in Angular, maybe they'd have a pit of success that a lot more devs would learn RxJS given a safe place to do it with fewer papercuts and bad examples to learn from. [0] It probably wouldn't be CycleJS either, as they'd still probably avoid Virtual DOM techniques. This thread has me picturing what you could do with a compile-time template Observable pipeline and I'm almost curious enough now to build a prototype of it just to show Angular how dumb it is and what it could be.

intellix 6y ago

My gripe with RxJS is how difficult it is. I've put thousands of hours into learning it and I just know the rest of the team don't understand the long chains I've written with it. I have the same problem where people are doing backflips to do simple things and I'll come in afterwards like... What ARE you trying to do here? And why are you not cleaning these up? Originally I was trying to stay away from behaviour subjects as recommended by the RxJS purists but now I just want to use them everywhere so its easier for everyone else to get values out of a stream

WorldMaker 6y ago
Sure, and that's pretty much exactly why Angular seems to refuse to commit. The EventEmitter in Angular's core is a really odd BehaviorSubject duck, and it shows. That says everything about their commitment to RxJS purity, and that behavior "from the top" leads to how much Angular pushes everyone to want to abuse BehaviorSubject, to do a lot of bad RxJS and never learn to do it right, because it's that rotten to the core. That impression that RxJS is too difficult for mortals becomes the self-fulfilling prophecy that Angular is right not to do RxJS right or commit to it, because it makes doing RxJS right in Angular harder. Half the component examples I see in the wild use RxJS wrong or badly, and of course that stuff gets copied and pasted everywhere. I've already sent patches to at least a few documentation examples that are supposed to be "best practice" that failed to actually live up to best practices because Angular failed them in setting a good example to live by. Angular has created the worst of both worlds that makes RxJS harder than it should be by failing to use it properly (providing too many bad habit escape hatches and failing to commit to it), but also making it almost impossible to avoid and subsequently polluting the entire ecosystem with bad examples, worse documentation, and terrible habits (all of which goes right back up to the top and terrible design decisions such as Angular core's EventEmitter). If Angular committed to being an AOT change detection only system it would probably be much more like Svelte. If Angular committed fully to RxJS it would be something different entirely [0] and maybe sure it would be harder for a lot of devs to grasp at first, but instead of the pit of failure that currently awaits devs trying to learn RxJS in place in Angular, maybe they'd have a pit of success that a lot more devs would learn RxJS given a safe place to do it with fewer papercuts and bad examples to learn from. [0] It probably wouldn't be CycleJS either, as they'd still probably avoid Virtual DOM techniques. This thread has me picturing what you could do with a compile-time template Observable pipeline and I'm almost curious enough now to build a prototype of it just to show Angular how dumb it is and what it could be.