If one's coding experience is limited to jQuery et al, it does introduce a lot and very fast: you can't really get very far in Angular before stumbling upon IoC and services/factories, for starters. Just look at the comments for any article that talks about Angular service/factory/provider/etc to see that even the most basics of patterns are not exactly universal knowledge.
A lot of the complexity you talk about originates from other patterns. More advanced tools like parsers/formatters, interceptors, decorators are there specifically to be alternatives to procedural spaghetti code and it's hard for a lot of people to even guess that these tools exist, let alone figure out why they should (or not) use them.
To be fair, it's true that a lot of complexity is very much Angular's fault and not a lack of preparedness from developers (the directives API and the digest system come to mind).
But my point was that it's hard to find Angular devs. Around where I live, a typical non-angular frontend job pays between 60-70k (generous extrapolation from salaries of people I know) and might involve a job interview that talks about responsive design. An Angular job easily pays 90k-110k (from job interviews I've been to) and might have a job interview that talks about algorithms. Even though both are considered "frontend" jobs, the former is more likely to be filled by a self-taught person that reads html5rocks or whatever, while the latter is more likely to be filled by someone w/ a CS degree and backend experience (which, here, usually means either Java or .NET). I think we can agree that the skill sets for the two jobs don't overlap much, and the dissonance in qualifications is not merely because of the level of complexity in a tool.
> Also, this is somewhat tangential, but I'm not sure software design patterns are part of computer science
If we're going to be nitpicky and pedantic, I said knowing when and why to use them is part of a CS foundation. s/CS/software engineering/, as long you get the main idea.
It may be the case that only people with deeper engineering experience can wrangle it because they have the necessary background. It could also be that people who are used to working with friendlier tools just aren't willing to put up with Angular's crap.
A lot of the stuff I wrote there is still relevant.
The stuff you wrote is valid. I'm just not sure that dev ability is the major factor making it harder to hire Angular devs. Maybe I'm wrong. I'm thankfully not hiring Angular devs.
That's hardly fair. Design patterns are not that difficult conceptually and in my (admittedly limited) experience Angular doesn't really introduce anything new. It's not hard to pick up because devs are lacking foundational skills. It's hard to pick up because it's overcomplex and difficult to adopt in pieces. Despite claims that it's easy to "add as much or as little of AngularJS to an existing page as you like", there seem to be no examples of piecemeal adoption in the docs. I'm sure someone with Angular experience could plug in a bit of Angular to an existing app, but someone just starting apparently has to choose to 1) go all in, 2) spend a lot of time learning Angular, or 3) use something else. If many competent devs are "hitting a brick wall face first", that seems to be indicative of problems with the framework.
Also, this is somewhat tangential, but I'm not sure software design patterns are part of computer science anyway. They belong to software engineering, which is really not the same thing.