19 ms·

Been using Angular.js and 2+ exclusively for almost a decade now. Keep reading how the compiler allows static type checking and superior tree-shaking at build t

Been using Angular.js and 2+ exclusively for almost a decade now. Keep reading how the compiler allows static type checking and superior tree-shaking at build time but I'm just not seeing any sort of fruition after years of promises. Every ngconf there's talk of the magical 2kb hello-world and bundle improvements with every major, yet the only bundles getting reductions are the hello-worlds and monster projects. It seems we're in the medium bundle category and it's just disappointing that every version our bundle size hasn't moved or increased slightly. We're currently at 2mb main/vendor after spending A LOT of time optimising and making everything lazy and then a team of 1 at our sister company release a Next.JS/React app with a main bundle about 1.3mb than ours using zero effort. There's never anything obvious when it comes to analysing the bundle and it seems we're using everything we need: Angular, Material, RxJS, ApolloClient. Most of our forms use Formly (huge savings from repeated HTML) All of our competitors are running React and have bundles about 1mb smaller than ours. Every year I install the VSC Language Service plugin and have to disable it the same day due to it continuously crashing and killing the editor so it seems we'll never get to benefit from that. Then I see a continuous stream of core developers leaving the Angular project due to toxic behaviour from Igor and it feels hopeless and depressing. The one saving grace is that the entire ecosystem is written in TypeScript and it's nice seeing everything typed to perfection.

adamnemecek 6y ago
What sort of toxic behavior?
- intellix 6y ago
  There's this from Jeff and then countless "metoo" tweets about it: https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-team-and-community-5367934a16c9 https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-t...
mgechev 6y ago
Angular team member here :) >our bundle size hasn't moved or increased slightly Please make sure you are using the latest version of our compiler and runtime. Many developers observed significant improvements after the v9 release. Here's just one [example](https://news.ycombinator.com/item?id=22260864 https://news.ycombinator.com/item?id=22260864). >Every ngconf there's talk of the magical 2kb hello-world Currently, it's absolutely doable to get very small bundle size (<7-8KB) for a hello-world application. This, however, relies on private APIs. We haven't made them public yet, because not many folks are building hello world apps, but in the future we'll be exploring how to reduce the footprints of the framework even further for smaller apps. >We're currently at 2mb main/vendor after spending A LOT of time optimising and making everything lazy It is shocking for me that you're spending that much effort on optimizing your app, but you can't get your bundle below 2MB. I'm spending large chunk of my time looking into apps and thinking how to make them smaller & faster. I'll be more than happy to connect and brainstorm the same for your case. Please reach out to me on my hackernews username @google.com >Every year I install the VSC Language Service plugin and have to disable it the same day due to it continuously crashing and killing the editor so it seems we'll never get to benefit from that. Sorry to hear you had such an experience with the language service. If it keeps crashing, definitely report the problem here https://github.com/angular/angular/issues https://github.com/angular/angular/issues. We'll be very thankful if you share reproduction steps. >Then I see a continuous stream of core developers leaving the Angular project due to toxic behaviour from Igor and it feels hopeless and depressing. Folks leave and and others join. I can't comment on my co-workers experiences, but after 2 years working on Angular I haven't experienced any of the behavior you're referring to. >The one saving grace is that the entire ecosystem is written in TypeScript and it's nice seeing everything typed to perfection. Oh, I wish everything was that perfectly typed :). This is something the team and the community is constantly working on, but we still have a long way to go until we reach perfection.
- hitekker 6y ago
  For reference, a former maintainer wrote about toxicity in the Angular dev team. https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-team-and-community-5367934a16c9 https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-t...
  - mgechev 6y ago
    Yes, I've worked with Jeff and I'm familiar with the post. In fact, Jeff was the one who first invited me to apply for a role at Google after our collaboration on the Angular mobile toolkit and it was great working with him :) It's not easy to share such a personal story publicly. I'm sorry he had such experience and I'm not saying he does not have the right to be upset. He knows the best what he went through and how he feels. I'm just saying that it's not correct to generalize and gave myself as an example for someone who can't relate to his experience.
    - zepto 6y ago
      Very positive response! It sounds like you don’t think there is any truth to what he is saying. That seems interesting given that he is not the only one saying it.
      - mgechev 6y ago
        There's no way for me to know what happened without being part of the team back then. What I'm certain is that he had a bad experience which impacted him negatively and I'm sorry he had to go through this. The only thing I'm saying is that it is not correct to generalize, giving myself as an example for someone who haven't experienced anything similar.
        lmohseni 6y ago
        Yikes. Blink twice if you need someone to send help.
      - 6y ago
deleted 6y ago
[deleted]
acoard 6y ago
This has largely been my experience too. I was development lead for an angular shop. We did all the government Ministry of Health forms in Angular, millions of residents would use our forms every year. Our frontend team I lead fluctuated from 5-8 people over the years. We had to work on basically every device, making sure it'd work on IE11 and for blind users running screen readers is something we'd do every single release. I say this not to brag, but just to say I lived and breathed angular for years, I was hired as the "angular guy", and I even wrote an npm-publiished library of re-usable components specifically to match Ministry of Health forms. My opinion of the Angular team and their stewardship of the project had ranged from mildly impressed, to disappointed, to alarmed. They frequently missed their own targets, the big one being Ivy, their compiler, which got pushed back 2 full releases and was constantly plagued by issues. (I left that job right as Ivy was released. Is anyone using it? Has it been a success?) Like you, I saw the Angular team constantly speaking to compiler optimizations, but never once saw those benefits manifest. To be honest, it just felt like they were using the typescript compiler (tsc). I never saw any performance benefits over tsc. In fact, now using React/tsc/webpack, I feel like the compiler is more configurable and powerful. In around 3 years of Angular updates the only feature we really used was the improved lazy loading of modules. I also used a bit of their codegen stuff ("Schematics"), which was promising but incomplete. Even though they were in release notes at the time, they lacked documentation and seemed like the team was bragging about features that weren't ready for light of day[0]. In the same timespan (~2016-Jan 2020), React got: server side rendering, pure components, hooks, profiling tools, improved lazy loading, and many _measurable performance increases that benefited projects across the board_[1]. Also, the Angular team began to increasingly focus on Material integration. We were a Bootstrap shop (ministry, at the time, required bootstrap styling). It was disappointing to see all those updates and know we couldn't use them. I will say that generally speaking Angular's opinionated, more enterprise-y approach to frontend absolutely has a place. For certain workplaces, like my former big corp one, having an opinionated enterprise-y language made onboarding easier and devs more consistent. The most disruptive devs we had were hotshot react devs who wanted to make our Angular code base look like their flavour of React. I use React now, and love it, but there are pros and cons to having an opinionated framework/library (not having that fight). And worst of all, the team itself seems to be imploding and toxic as you've alluded to. I left that job for other reasons, but I'm glad I'm working with React and Vue more heavily now. [0] https://medium.com/@lifenshades/difference-among-angular-8-7-6-5-4-3-2-breakdown-new-features-and-changes-811fb5f8e6f0 https://medium.com/@lifenshades/difference-among-angular-8-7... [1] https://en.wikipedia.org/wiki/React_(web_framework)#History https://en.wikipedia.org/wiki/React_(web_framework)#History edit: The other great part about the Angular community is it's TS first. I miss that about React/Vue.
vaccinator 6y ago
How do you like breaking the web one page at a time with angular?
8note 6y ago
How much of a differentiator is the bundle size for your customers? Do they notice this 1mb?
- intellix 6y ago
  Google's own lighthouse suite runs everything through network/cpu throttling for scoring so to download a bundle that started at 2mb and parse it really penalizes you compared to a 1mb bundle (even after gzip and you're getting screwed on parse performance of lower devices). Then you have the way universal replaces all content when it bootstraps and you get penalised for that. We're also seeing issues where the site isn't ready yet and clicking a link just opens a new tab cause the JS wasn't downloaded/parsed yet. You can use the preload library but guess what: doesn't work. As usual it was always: this'll get fixed with ivy and it wasn't. It seems all libraries we depend on were initially made by staff who were driven out of the team. - universal - animations - forms Our clients use the Google performance scores and ask why none of the performance improvements we're doing has had any effect and then point to a React competitor's lighthouse score
WorldMaker 6y ago
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.
stopyellingatme 6y ago
Came here to say that Formly is fantastic! It's pretty much the only thing left i like about Angular. Any future projects will be written in Svelte if my team has anything to do with it, though.

adamnemecek 6y ago

What sort of toxic behavior?

intellix 6y ago
There's this from Jeff and then countless "metoo" tweets about it: https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-team-and-community-5367934a16c9 https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-t...

mgechev 6y ago

Angular team member here :) >our bundle size hasn't moved or increased slightly Please make sure you are using the latest version of our compiler and runtime. Many developers observed significant improvements after the v9 release. Here's just one [example](https://news.ycombinator.com/item?id=22260864 https://news.ycombinator.com/item?id=22260864). >Every ngconf there's talk of the magical 2kb hello-world Currently, it's absolutely doable to get very small bundle size (<7-8KB) for a hello-world application. This, however, relies on private APIs. We haven't made them public yet, because not many folks are building hello world apps, but in the future we'll be exploring how to reduce the footprints of the framework even further for smaller apps. >We're currently at 2mb main/vendor after spending A LOT of time optimising and making everything lazy It is shocking for me that you're spending that much effort on optimizing your app, but you can't get your bundle below 2MB. I'm spending large chunk of my time looking into apps and thinking how to make them smaller & faster. I'll be more than happy to connect and brainstorm the same for your case. Please reach out to me on my hackernews username @google.com >Every year I install the VSC Language Service plugin and have to disable it the same day due to it continuously crashing and killing the editor so it seems we'll never get to benefit from that. Sorry to hear you had such an experience with the language service. If it keeps crashing, definitely report the problem here https://github.com/angular/angular/issues https://github.com/angular/angular/issues. We'll be very thankful if you share reproduction steps. >Then I see a continuous stream of core developers leaving the Angular project due to toxic behaviour from Igor and it feels hopeless and depressing. Folks leave and and others join. I can't comment on my co-workers experiences, but after 2 years working on Angular I haven't experienced any of the behavior you're referring to. >The one saving grace is that the entire ecosystem is written in TypeScript and it's nice seeing everything typed to perfection. Oh, I wish everything was that perfectly typed :). This is something the team and the community is constantly working on, but we still have a long way to go until we reach perfection.

hitekker 6y ago
For reference, a former maintainer wrote about toxicity in the Angular dev team. https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-team-and-community-5367934a16c9 https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-t...
- mgechev 6y ago
  Yes, I've worked with Jeff and I'm familiar with the post. In fact, Jeff was the one who first invited me to apply for a role at Google after our collaboration on the Angular mobile toolkit and it was great working with him :) It's not easy to share such a personal story publicly. I'm sorry he had such experience and I'm not saying he does not have the right to be upset. He knows the best what he went through and how he feels. I'm just saying that it's not correct to generalize and gave myself as an example for someone who can't relate to his experience.
  - zepto 6y ago
    Very positive response! It sounds like you don’t think there is any truth to what he is saying. That seems interesting given that he is not the only one saying it.
    - mgechev 6y ago
      There's no way for me to know what happened without being part of the team back then. What I'm certain is that he had a bad experience which impacted him negatively and I'm sorry he had to go through this. The only thing I'm saying is that it is not correct to generalize, giving myself as an example for someone who haven't experienced anything similar.
      - lmohseni 6y ago
        Yikes. Blink twice if you need someone to send help.
    - 6y ago

deleted 6y ago

[deleted]

acoard 6y ago

This has largely been my experience too. I was development lead for an angular shop. We did all the government Ministry of Health forms in Angular, millions of residents would use our forms every year. Our frontend team I lead fluctuated from 5-8 people over the years. We had to work on basically every device, making sure it'd work on IE11 and for blind users running screen readers is something we'd do every single release. I say this not to brag, but just to say I lived and breathed angular for years, I was hired as the "angular guy", and I even wrote an npm-publiished library of re-usable components specifically to match Ministry of Health forms. My opinion of the Angular team and their stewardship of the project had ranged from mildly impressed, to disappointed, to alarmed. They frequently missed their own targets, the big one being Ivy, their compiler, which got pushed back 2 full releases and was constantly plagued by issues. (I left that job right as Ivy was released. Is anyone using it? Has it been a success?) Like you, I saw the Angular team constantly speaking to compiler optimizations, but never once saw those benefits manifest. To be honest, it just felt like they were using the typescript compiler (tsc). I never saw any performance benefits over tsc. In fact, now using React/tsc/webpack, I feel like the compiler is more configurable and powerful. In around 3 years of Angular updates the only feature we really used was the improved lazy loading of modules. I also used a bit of their codegen stuff ("Schematics"), which was promising but incomplete. Even though they were in release notes at the time, they lacked documentation and seemed like the team was bragging about features that weren't ready for light of day[0]. In the same timespan (~2016-Jan 2020), React got: server side rendering, pure components, hooks, profiling tools, improved lazy loading, and many _measurable performance increases that benefited projects across the board_[1]. Also, the Angular team began to increasingly focus on Material integration. We were a Bootstrap shop (ministry, at the time, required bootstrap styling). It was disappointing to see all those updates and know we couldn't use them. I will say that generally speaking Angular's opinionated, more enterprise-y approach to frontend absolutely has a place. For certain workplaces, like my former big corp one, having an opinionated enterprise-y language made onboarding easier and devs more consistent. The most disruptive devs we had were hotshot react devs who wanted to make our Angular code base look like their flavour of React. I use React now, and love it, but there are pros and cons to having an opinionated framework/library (not having that fight). And worst of all, the team itself seems to be imploding and toxic as you've alluded to. I left that job for other reasons, but I'm glad I'm working with React and Vue more heavily now. [0] https://medium.com/@lifenshades/difference-among-angular-8-7-6-5-4-3-2-breakdown-new-features-and-changes-811fb5f8e6f0 https://medium.com/@lifenshades/difference-among-angular-8-7... [1] https://en.wikipedia.org/wiki/React_(web_framework)#History https://en.wikipedia.org/wiki/React_(web_framework)#History edit: The other great part about the Angular community is it's TS first. I miss that about React/Vue.

vaccinator 6y ago

How do you like breaking the web one page at a time with angular?

8note 6y ago

How much of a differentiator is the bundle size for your customers? Do they notice this 1mb?

intellix 6y ago
Google's own lighthouse suite runs everything through network/cpu throttling for scoring so to download a bundle that started at 2mb and parse it really penalizes you compared to a 1mb bundle (even after gzip and you're getting screwed on parse performance of lower devices). Then you have the way universal replaces all content when it bootstraps and you get penalised for that. We're also seeing issues where the site isn't ready yet and clicking a link just opens a new tab cause the JS wasn't downloaded/parsed yet. You can use the preload library but guess what: doesn't work. As usual it was always: this'll get fixed with ivy and it wasn't. It seems all libraries we depend on were initially made by staff who were driven out of the team. - universal - animations - forms Our clients use the Google performance scores and ask why none of the performance improvements we're doing has had any effect and then point to a React competitor's lighthouse score

WorldMaker 6y ago

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.

stopyellingatme 6y ago

Came here to say that Formly is fantastic! It's pretty much the only thing left i like about Angular. Any future projects will be written in Svelte if my team has anything to do with it, though.