3 ms·

Angular has great support. It is the front end to some absolutely huge apps like Google AdWords, Google Cloud Platform etc. Angular shines when you have 10+ dev

Angular has great support. It is the front end to some absolutely huge apps like Google AdWords, Google Cloud Platform etc. Angular shines when you have 10+ devs working on the project. It's not slow, flexible and the boilerplate module code will be removed in the next version. Basically you just have to give it a go, so many people trash technology without giving it a unbiased go.

steve_adams_86 4y ago
Having used Angular 1 then migrating to 2, and then trying it again very recently I wonder if a lot of people were burned by early Angular and unwilling to try it again. It’s leaps and bounds ahead of what it was in terms of end user and developer experience. The tooling is dramatically improved. If you asked me 6 months ago what my position on Angular was, I probably would have said something like “I haven’t used it recently, but older version were pretty awful. Bad DX, incredibly slow builds, huge bundle size, etc”. Today I think it’s pretty compelling for the right projects. Like anything that doesn’t just fade away, there’s a reason people still use it. There are some talented and intelligent people driving it forward. I’m not eager to use it, but I was really glad to see how much it has improved.
- wdb 4y ago
  Yes, Angular 1 wasn't great and I haven't looked back
- zdragnar 4y ago
  The code quality of angular 4/5/6 and the add-on packages was so bad, I wouldn't want to lock myself into that ecosystem ever again. I don't remember exact numbers, but I'm pretty sure that about half the bugs that project had were due to angular, poorly designed Rxjs interactions, or angular flex-layout.
  - steve_adams_86 4y ago
    I love RxJS and the testing story is not bad, but it does manage to find ways to be buggy when I encounter it. It seems like both a strength and a weakness of the Angular ecosystem. Maybe the testing story needs to improve? I can’t recall how exhaustive marbles are, and maybe fuzzing might help catch gotchas? Honestly I thought RxJS would benefit a ton from a visual builder. They have this decision tree tool for helping figure out which operators you need to use, but you could go further and actually build out entire observables in a similar way, plotting out the system and behaviours visually along the way. When you have such excellent boundaries and well defined behaviours, but observables can become complex so easily, it seems like a great opportunity to visualize and constrain things with tools which generate the code you need. I know some might find that gets in the way of programming, but I have a feeling it would help those who struggle with RxJS produce far more stable observables. This is actually why I began using XState for a lot of things. Although I can write out all of the logic myself easily enough, their tooling seems like it’s on a very promising path to making complex state management far more approachable to people with less experience. Having well defined state, transitions, and a great testing story is huge in avoiding the kind of buggy mess I’ve seen and you seem to be describing around Angular.
    - zdragnar 4y ago
      Both RxJS and XState have some really seductive tooling and promises. It has been my personal experience (from 4+years ago for both libraries) that both will quickly swamp you in accidental complexity. Point of fact, I just started a new job and am already being thrown into fixing their state machine code (not javascript / ts though). I can't say that what they're doing requires fewer lines, tests or has fewer bugs than if they'd just written it out without the whole state machine concept. I can say that it would certainly be a lot simpler and more flexible, though.
      - steve_adams_86 4y ago
        That's really interesting. I've been hesitant to use state machines for anything complex... I find they work great for small-ish things like an image uploading component in the front end, where the states are very well defined, there is a sort of flow, predictable actions need to be taken, etc. I've wondered a lot about composing machines. It seems like it could be extremely useful and powerful. The actor model is the approach the XState team is taking and it seems promising, but some things holds me back. The API is certainly one reason, but it's the mounding complexity that scares me more. Like you say, it seems like it could get really messy. I have a feeling with a good enough API this problem could be reduced, but that's not a trivial thing to figure out at all. I'd love to see it happen, though.
wdb 4y ago
Google Cloud Platform Console is really slow for me. Always painful experience to use especially switching products. Wouldn't say that's a good advertisement for Angular
- Alex3917 4y ago
  > Google Cloud Platform Console is really slow for me. While this definitely isn't because of Angular, I will note that it's currently deployed in development mode.

steve_adams_86 4y ago

Having used Angular 1 then migrating to 2, and then trying it again very recently I wonder if a lot of people were burned by early Angular and unwilling to try it again. It’s leaps and bounds ahead of what it was in terms of end user and developer experience. The tooling is dramatically improved. If you asked me 6 months ago what my position on Angular was, I probably would have said something like “I haven’t used it recently, but older version were pretty awful. Bad DX, incredibly slow builds, huge bundle size, etc”. Today I think it’s pretty compelling for the right projects. Like anything that doesn’t just fade away, there’s a reason people still use it. There are some talented and intelligent people driving it forward. I’m not eager to use it, but I was really glad to see how much it has improved.

wdb 4y ago
Yes, Angular 1 wasn't great and I haven't looked back
zdragnar 4y ago
The code quality of angular 4/5/6 and the add-on packages was so bad, I wouldn't want to lock myself into that ecosystem ever again. I don't remember exact numbers, but I'm pretty sure that about half the bugs that project had were due to angular, poorly designed Rxjs interactions, or angular flex-layout.
- steve_adams_86 4y ago
  I love RxJS and the testing story is not bad, but it does manage to find ways to be buggy when I encounter it. It seems like both a strength and a weakness of the Angular ecosystem. Maybe the testing story needs to improve? I can’t recall how exhaustive marbles are, and maybe fuzzing might help catch gotchas? Honestly I thought RxJS would benefit a ton from a visual builder. They have this decision tree tool for helping figure out which operators you need to use, but you could go further and actually build out entire observables in a similar way, plotting out the system and behaviours visually along the way. When you have such excellent boundaries and well defined behaviours, but observables can become complex so easily, it seems like a great opportunity to visualize and constrain things with tools which generate the code you need. I know some might find that gets in the way of programming, but I have a feeling it would help those who struggle with RxJS produce far more stable observables. This is actually why I began using XState for a lot of things. Although I can write out all of the logic myself easily enough, their tooling seems like it’s on a very promising path to making complex state management far more approachable to people with less experience. Having well defined state, transitions, and a great testing story is huge in avoiding the kind of buggy mess I’ve seen and you seem to be describing around Angular.
  - zdragnar 4y ago
    Both RxJS and XState have some really seductive tooling and promises. It has been my personal experience (from 4+years ago for both libraries) that both will quickly swamp you in accidental complexity. Point of fact, I just started a new job and am already being thrown into fixing their state machine code (not javascript / ts though). I can't say that what they're doing requires fewer lines, tests or has fewer bugs than if they'd just written it out without the whole state machine concept. I can say that it would certainly be a lot simpler and more flexible, though.
    - steve_adams_86 4y ago
      That's really interesting. I've been hesitant to use state machines for anything complex... I find they work great for small-ish things like an image uploading component in the front end, where the states are very well defined, there is a sort of flow, predictable actions need to be taken, etc. I've wondered a lot about composing machines. It seems like it could be extremely useful and powerful. The actor model is the approach the XState team is taking and it seems promising, but some things holds me back. The API is certainly one reason, but it's the mounding complexity that scares me more. Like you say, it seems like it could get really messy. I have a feeling with a good enough API this problem could be reduced, but that's not a trivial thing to figure out at all. I'd love to see it happen, though.

wdb 4y ago

Google Cloud Platform Console is really slow for me. Always painful experience to use especially switching products. Wouldn't say that's a good advertisement for Angular

Alex3917 4y ago
> Google Cloud Platform Console is really slow for me. While this definitely isn't because of Angular, I will note that it's currently deployed in development mode.