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.
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.
It was clear to us from day one that performance would be an area of concern, as well as the overall complexity of the framework. But those can be addressed. I don't agree that using another framework would magically prevent developers from thinking about performance issues. And many modules of angular we just don't use, and it doesn't impose those on us.
On a regular basis we re-evaluate alternatives: React, knockout, backbone, and so on. I expect those might involve tradeoffs that end up being positive or neutral for us, even it just forces a re-thinking of the app architecture. But this article doesn't make any recommendation or even mention the initial problem of rich, single-page apps that create user interactivity without page reloads. And the painting of the framework as Java and Enterprise do not match our experience or use case. I'm the first in line for recommendations on how we can improve what we do, but my impression is his bias is throw away frameworks and bring back our mass of raw javascript.
Angular does have its annoyances and compromises, and in some areas, it's kind of a pig (i.e., ng-repeat).
Our projects aren't massive in scope (they're targeted towards small enterprise implementations), however, so I don't think Angular's limitations will really hit us hard except in certain use cases.
It's when you get controllers such as ng-repeat that Angular's digest cycle makes some difference. But ultimately you could write a component like ng-repeat yourself. As for where you place the directives -- the tag name or attributes, inside the class -- who cares? Only the {{}} in the text nodes matters strongly.
As for alternatives, check out http://platform.qbix.com . It is compatible with angular, ember, jquery etc. But it is much more straightforward, like react. You only have two concepts - pages and tools (components). And you can not only re-use a whole lot of tools from a marketplace but they all can work with a standard opensource platform of user accounts, realtime streams of data, which can distribute the social layer the same way bitcoin distributes money and contracts.
Prior to this contract I had no experience with it, now I've been using it nearly every day for the past month and a half, have run through the tutorials and implemented it on a side project of mine.
All that said, I will be stripping Angular out of my side project. It is something I am glad I learned for clients that demand it, but I wouldn't recommend it.
IMO Backbone with underscore templates are much cleaner and seem to perform much faster for my needs (no benchmarks performed on my end, but as a user my site certainly felt snappier prior to implementing Angular).
From the article:
"Unfortunately they aren’t trained to recognise Angular’s performance problems." ... "The problem is that there is no way for Angular to discover these instructions except by parsing the entire DOM, including all text nodes and attribute values — a very expensive process if there ever was one, especially on mobile."
The author is arguing that it is bad for performance.
In fact, a few years ago there was an obvious tide toward experimenting with alternatives to string based templating noticeable in several some high profile efforts in the client side templating space.
See http://modernweb.com/2014/03/24/string-templating-considered... for a recent overview that is pretty decent. Boris Moore did a lot of publishing about it, as I recall.
Most templates will typically live in separate files and be loaded and compiled when needed, of course - so not so much of a performance hit up front. But Angular still needs to know where to dump the stuff, so it needs to parse the DOM to find a node with the ng-app directive.
Also, I'm not aware of anything like handlebars's offline pre-compilation for Angular, although such a thing may well exist. There's a lot of stuff in there...
This.
I honestly think most front end devs don't test with anything except a fast PC (or Mac). They sure don't test with last year's phones. Web pages are getting more and more sluggish (generally speaking) all the time.
It's one thing to always want to work with new technology, but devs really need to spend some time in their customers' shoes.
Agreed. I'd go even further: presentation logic, including templating, is the job of the browser. The server is the database. And I include "mobile" front-ends in this, which do all not equate to "low-powered" these days.
This persistent idea that one should compile templates on the server is so mindbogglingly inefficient - compared to delegating to clients whose computing power is idling 99% of the time. Not to mention separation of UI from the core functionality and other benefits.
JS in browsers is incredibly fast nowadays. I can't remember the last time I ran into performance issues. Angular my not be the most efficient but it's a stepping stone in the direction of client-side apps + RESTful APIs which I think will be the rule rather than exception in the future.
Lots of features are in the pipeline which will make client-side apps even faster and more elegant (shadow DOM, Object.observer).
s/idling/conserving battery life/
much of the original article's criticism was aimed at angular apps on mobile devices.
It is indeed stupid and wasteful to deliver 40 KB of framework and 8 KB of templates and 14 KB of data and 20 KB of business logic and 15 KB of CSS to the client and then make the client do all the rest of the work to "make page happen"--especially on an open platform with so few reliable guarantees about the client's capabilities and resources.
But to say templating is only the job of the server is equally myopic. Web applications--high functionality, low content (as opposed to web sites--low functionality, high content) have struggled with the limitations of the static, stateless document paradigm for years and is the real use-case for client side templating as an answer to one of the many resulting challenges.
When a page is highly dynamic in response to interaction, it is equally stupid and wasteful to perform full page refreshes. Request, server compile, download, flow, paint. Bad. Slow, discontinuous.
Someone else mentioned UX being ignored in the quest for client side templates: no, wrong. Client side templates are at least 50% about UX. We have a DOM already there, let's use it. But that is also exactly the problem with the all-client mode: it delivers something several extra steps removed from being a useful (to the user) DOM when it could do otherwise and when doing otherwise would result in a better and more universally performant user experience.
Right now, truly smart isomorphic templates are what we need. (But, then again, by the time we get them, we probably won't need them--because the goalposts will have shifted and/or we'll have a better answer.)
Dang should we not flag this stuff?
"This code reminds me of a simple server-side scripting language such as JSP or ASP that’s used to fill HTML templates with database content. These languages have their place in the web development stack — but on the server, not in the browser."
Says who? What's the rationale for where a language belongs?
"Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server."
Again, based on what?
"My point is that I expected far more front-enders to embrace Angular. I have the feeling their number is surprisingly low — see also the problems my clients had with finding good front-end Angular consultants. "
More stuff based on feeling rather than empirical evidence. And clients have trouble finding good front-end developers these days no matter what the technology is.
"A more important reason may be pushback from the JavaScript community. Angular has evoked some serious criticism."
Find me a framework that hasn't evoked serious criticism from some corner of the Internet.
Look, I'm no fan of Angular. In fact I've never written a thing in it. It doesn't really fit my style of front-end development (and I'm a Java programmer!). I'm more of a libraries-over-frameworks guy. But this article is not very well-reasoned.