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.
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.
We're calling design patterns prevalent in Angular/Java "Computer Science"?
I'm not even sure they're worthy of the original terminology design patterns, and there's a pretty strong argument they're not foundational computer science at all (you can really see this by working in several different language paradigms and seeing how some problems patterns solve in some languages fall out without the pattern in others). They're aspects of industrial practice and a subset of software engineering. This isn't to say they're not useful (and some more broadly than others), but their usefulness arises in the context of the tools applied and concerns/constraints present rather than CS fundamentals.
And one doesn't have to be a jQuery hack to think that the concerns involved in dynamic single-page apps don't necessarily imply the utility of all Angular's abstractions (as I'm sure many devs who've embraced other front-end frameworks would agree).
> The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author.
New and shiny ways are not always the best. I'm still not seeing people writing kernels and device drivers in JavaScript.
> SPA architectures certainly have their places
And what areas those might be and why?
You can build heavily dynamic apps without trying to do everything in the browser.
Problem with the web nowadays is that a lot of decisions are being made for political reasons rather UX considerations. SPA architectures are appealing to front-end developers who just can't be bothered to learn how to do routing and templating on the backend or they just want to have those things in their territory.
For me UX matters more than shiny architecture. I did the experiment in Chrome where I had HTML and applied some stylings to it via the raw DOM API as soon as possible. There was a noticeable delay before the stylings got applied and this was the highly optimized DOM code with no Angular, no jQuery, no nothing. The moral of the story is: browsers are still faster at displaying HTML and CSS.
Aside from the performance failures, Angular has huge problems when it comes to writing maintainable Angular code like the scope hell, but you can find many others here: http://ihateangular.com/
> I think the point is that Angular criticism is much more prominent (and sometimes vitriolic) than other frameworks.
That always happens to frameworks that get widespread usage. If your framework doesn't have vocal groups of haters, it is not successful.
I suspect this happens when frameworks start to be mandatory by decree in organizations.
PPK has a very strong background in cross browser testing and high level technology evaluation for non-techie audiences, but (from my impression of reading this article, at least), it doesn't seem like he has much experience w/ Angular per se and sounds like he is writing his opinions more based on blogosphere echo than personal time spent with the framework (clue: lack of Angular-specific terminology criticism)
Some of the criticism is valid, I think: hiring "Angular" devs is hard, partly because of the over-engineered-Java-like feel. I've seen a few times overconfident frontenders think they could pick up Angular through Google-Fu just as they picked up jQuery, and then hitting a brick wall face first, with a looming deadline to add insult to the injury. The reality is that a lot of people (especially frontend people) don't have the CS foundation to understand why and when the design patterns prevalent in Angular/Java are useful (or even what patterns exist to begin with).
@jasonwocky The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author. SPA architectures certainly have their places, and it does feel like the author hasn't had experience w/ building heavily dynamic UI apps.
>> Find me a framework that hasn't evoked serious criticism from some corner of the Internet.
I think the point is that Angular criticism is much more prominent (and sometimes vitriolic) than other frameworks.