A low total cost of ownership compared to other frameworks because:
- The code for every Angular project is structured the same way
- The code for components (and directives, services, etc.) is generally very readable
- Everything is easy(ish) to test
- 280k Stack Overflow questions, vs 95k for Vue and 19k for Next
And ease of hiring due to 170k Angular developers in the US (per Sales Navigator), as opposed to 50k for Vue.js and 48k for Next.js
And in general Angular seems much easier to learn. If you spend 20 hours watching the Udemy course then you pretty much know it, whereas I regularly see job ads looking for folks with 6+ years of React experience. Now obviously you always hear about job ads looking for folks with 10 years of experience with some technology that's been around for two years, and yet I rarely come across Angular job ads that implicitly assume it takes multiple years to learn how to use the framework correctly.
> And ease of hiring due to 170k Angular developers in the US (per Sales Navigator), as opposed to 50k for Vue.js and 48k for Next.js
Listing large numbers without commentary is a bit of a red flag unless you can point to how you analyzed the raw data — e.g. does more questions mean more happy users or more problems which people can't figure out on their own? Does that developer figure exclude the people who said “I used Angular 1, hated it, and switched to React”? That last is related to the conspicuous absence of React, which has higher numbers in both categories.
You just described every frontend framework. None of these are unique to Angular. Any developer with an understanding of JS can learn and use any framework in the exact same way.
> 280k Stack Overflow questions, vs 95k for Vue and 19k for Next. And ease of hiring due to 170k Angular developers in the US (per Sales Navigator), as opposed to 50k for Vue.js and 48k for Next.js
These are false comparisons, and you're conveniently leaving out the largest competitor. A higher SO question count isn't necessarily a positive metric, and may even imply substantial confusion about the framework. More importantly, all of the surveys[1] show that both developer and hiring interest for Angular is waning.
> whereas I regularly see job ads looking for folks with 6+ years of React experience. Now obviously you always hear about job ads looking for folks with 10 years of experience with some technology that's been around for two years, and yet I rarely come across
You're using a popular meme about some notoriously bizarre job listings written by HR managers (or interns) to suggest that developers have a harder time learning frameworks other than Angular. There is no correlation whatsoever between these two things. When "you always hear" and "yet rarely come across," you are experiencing the effects of confirmation bias.
> Angular job ads that implicitly assume it takes multiple years to learn how to use the framework correctly.
If a job lists multiple years of experience as a requirement, why would that automagically mean the employer is "implicitly assuming" multiple years of training is required to accomplish a bare minimum? In reality, it means they're looking for someone who didn't spend last weekend watching a 20 hour Udemy course to obtain a cursory understanding.
They're requiring real-world experience in a similar work/project environment, and they are paying handsomely for that experience. If it were junior development jobs with these requirements, you'd maybe have an argument, but 100% of senior positions have minimum work history requirements, because that is the definition of senior.
[1] https://gist.github.com/tkrotoff/b1caa4c3a185629299ec234d231...
You just summed up, why he said Angular is better in this regard. Yes any developer with experience CAN lean how to write good structured React apps. In Angular it is basically enforced.
Coming from the React/Next.js world, I was really puzzled with that decision as I still had in mind the trauma of the Angular.js -> Angular migration and the breath of fresh air that React had represented at the time.
As most engineers out there, I had an urge to stick to what I knew would work, but I resisted that urge and gave Angular a chance. I do not regret it; Angular and the structure the framework provides is a game changer for a large project; the conventions make the code and the architecture predictable/testable/scalable. Our time is spent on delivering value for our users. This is, in my opinion, the best quality a technology can have when working on a fairly large project.
That being said, I think the ergonomics in React development (JSX) are SOO much better than Angular that I still prefer it.
I never use Angular for personal projects, and I have been using TypeScript exclusively for years. I.e. other libraries work really well with TypeScript as well (sometimes actually better than Angular, in my experience)
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.
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.
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.
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.
While this definitely isn't because of Angular, I will note that it's currently deployed in development mode.
Another set of advantages comes from how declarative Angular is. With React and JSX, everything is super imperative (setState, loops to generate dom, etc). In Angular, RxJS gives you a really powerful reactive model for your state, directives give you a much more declarative way of describing application behavior, and the limited template microsyntax encourages you to put the complexity in your typescript, not in templates.
I don't know how much people have changed, but generally people don't change very fast so this is probably still relevant: If the HTML doesn't look like HTML and the CSS doesn't look like CSS, you end up with a bunch of problems that can only be solved by the people who aren't invested in it.
Designers and UX specialists end up being hobbled if they are expected to make heads or tails of the Turing Complete parts of the code. And once they feel hobbled they tend to shut down even more, and it's just pain getting any improvements in.
Mostly HTML with a little code is already at the very edge of their comfort levels. JSX and things like JSX have been abandoned more times than I can count, and there's always some necromancer who brings it back.