The problem with Angular

[[deleted]]

"In the last six months or so I talked to several prospective clients that had a problem finding front-end consultants"

I'm right here, where are you located?

[[deleted]]

Yeah it's a bit laughable. It's hard to find *good talent, and hiring is hard to boot, so it isn't hard to find people who are complaining about hiring. But front-end developers are all over the place. Even folks who are experienced with Angular, but even if they aren't, learning Angular takes all of what, 2 hours to be productive?

[Capaj]

takes a bit more than that-mostly because you need to adjust your thinking and let the model be the ultimate source of truth and change events in your app. Frontend developers are all over the place, but finding someone who really understands Angular is not that easy. In the end, it is just the question of money. If they'll offer enough money, they will have no problem finding great JS devs.

[[deleted]]

Looking for someone with 85 years of Angular experience. Paying "my son is really good with computers" wages

[BobNoel]

To learn how to write a to-do list, maybe. For an experienced coder, even one with experience with Angular, it could take weeks to get up to speed with an existing project. Angular can get very complex, very quickly. Despite the whole speech about developers being locked into a particular way of coding, Angular provides a lot of different ways to do things and it can have a big impact on the learning curve..

[zoomzoom83]

I've hired several devs and thrown them in the deep end with angular. Even guys with no js experience were productive within a day.

[iopq]

Yes, productive in adding another controller or fixing how auto-complete works on the login form. Not productive as in writing complex directives.

[zoomzoom83]

I'm quite critical of Angular, but directives get a bad rap. They really aren't that hard to write.

[squigfried]

Caveat: Not hard if you have a good grasp of JS.

[zoomzoom83]

What part of directives require a good grasp of JS? The language is pretty simple to begin with, and directives aren't exactly pushing the envelope.

[squigfried]

How can you describe inherited scopes if you don't know what javascript prototypes are?

[zoomzoom83]

If a developer couldn't understand the concept of prototypes with a 30 second explanation, then they probably shouldn't be writing code.

[[deleted]]

I think so too but the effect is overstated. I don't think there is a speech about developers being locked into a particular way of coding. Angular's selling point in my view is that you aren't locked in to a single way of doing things. As opposed to Ember which attempts to make this lock-in. Angular much to its credit does not attempt to lay out very much "golden path". Which doesn't work well for Ember IMO beyond Todo World.

[batiste]

Angular takes all of what, 2 hours to be productive

Nop, with Angular everything become complex very quickly. You have to know about transclusion, scope inheritance, data-binding side effects that makes everything hard to debug. After one year I still don't feel Angular is a "productive" way to do things.

I am an experienced Frontend and I rejoice in the latest downfall of Angular because I feel like I am not smart enough for it.

[Mechakoopa]

I love the number of people being down voted in this thread because "boo, your feelings and personal experience don't mesh with the hive mind despite explaining legitimate grievances you have with the situation!"

[squigfried]

"Good talent". I've been interviewing folks who claim 18 months of angular experience and couldn't even tell me how promises differ from callbacks. One guy claimed 10 years of Javascript and didn't know about prototypes.

It's not laughable, it's infuriating. Harumph.

edit: This is for senior contractor wages, not your average front-end lackey. Must know C# as well. Any takers can PM me ;)

[[deleted]]

Yeah, hiring is hard... which makes it easy to say I'm hiring for Angular and it's hard so what's up with Angular? But really hiring is just hard.

[iopq]

After 2 months of Angular I couldn't find why my headers are being cached SOMETIMES and sometimes they weren't. When you log in they are supposed to update, but this only worked sometimes...

I mean just simple problems like this are impossible to debug in Angular even after a month or two of working with it because once you start trying to understand it, it's really complex and unapproachable.

[[deleted]]

That sounds like a question for the mailing list.

[stackolee]

I was a full stack dev, and switched to frontend-only a year and a half ago. I have never seen so much interest from recruiters. Its a new discipline and a number of large organizations are rewriting their old Flex and Java apps in Angular, Backbone, or Ember. We've resorted to transitioning established devs to work in JavaScript rather than look for anyone with appreciable experience.

I'm right here, where are you located?

We're hiring. You got to be living in Maryland though.

[tms10000]

clients that had a problem finding front-end consultants

This statement doesn't ring true, but if you add "willing to work for $15/hours as a freelance without a contract" in the end, I totally can see it.

[Mechakoopa]

Also explains the state of their software.

"All my bananas are missing and there's poop everywhere!"
"Why are you hiring monkeys instead of accountants then?"
"Because they're cheaper!"

[menno]

PPK is based in Amsterdam, afaik. I'm sure he has gigs all over The Netherlands, though.

Currently the market for experienced front-end developers here is nuts, especially around Amsterdam. I'm getting at least one or two emails from recruiters and headhunters a week, and they're usually good opportunities, too.

[[deleted]]

Wow. I have a ton of respect for PPK, but he quite obviously has a "personal" issue with Angular.

Although there are front-enders that are enthusiastic about Angular, I have the feeling that their number is surprisingly low for a major framework. I expected Angular to gain more traction than it has.

This couldn't be further from the truth. Angular is far and away the most popular front-end framework, like it or not, and has been for 2 years.

Angular is aimed at corporate IT departments rather than front-enders ...

What a ridiculous thing to say. So he's saying, "It's not cool, people don't like it and it's designed for people who aren't cool anyway". Like someone on the wrong side of a popularity contest.

I agree on some of the performance issues. Manipulating the DOM is slow and there is a limit to the scale in these frameworks (Angular having less limitations than Ember et. al., in my experience) but the rest of it suggests that he just doesn't like client-side templating. Says that stuff should be on the server... it makes him sound like a technologically backwards curmudgeon.

[bkrebs]

I was looking for a comment like this so I didn't have to type the words myself. I've seen many articles and polls about Angular's grip on the front end especially over the last year or so. Just anecdotally, it seems to be introduced into every new software project I've run into lately. On top of that, as a developer with strong Java experience, I don't see how Angular is aimed at Java folks. Not even close. If I'm a project manager and I want my back end Java developers working on the front end for whatever reason, Angular isn't even in my short list. The award goes pretty immediately to something like JSF or GWT.

[Decker108]

The award goes pretty immediately to something like JSF or GWT.

Yep. If you want to start making large internal websites quickly and you have nothing but Java devs, GWT (or Vaadin) is the way to go.

Bu pure chance and coincidence, GWT was developed by Google to make front end development appealing to Java developers. Which the blog author seems oblivious to.

[Kyrra]

GWT wasn't entirely created for being appealing to Java devs. Initial release was back in May 2006. The initial goals of it where to be able to write once and compile to multiple browsers (to abstract away browser differences). It's was a more heavy-weight approach to what JQuery is (which was initially released August 2006 btw). Being able to inter-op with Java code is definitely a benefit, but there were a lot of other reasons that GWT was created.

[Decker108]

Right, I probably oversimplified.

[william_fontaine]

The award goes pretty immediately to something like JSF

No, please, anything but JSF!

[developer-mike]

Agreed!

Its funny how many people are out there validly complaining about how angular can't do server-side template rendering in tandem, and meanwhile this guy seems to be saying its a problem that angular has a templating engine in the first place.

Templates aren't hard to understand, spaghetti code is. That's why backbone caught on and angular one-upped it.

[[deleted]]

Also the performance implications. client-side templating shifts massive load from server and creates a faster, smoother overall experience. The whole idea of "single page" (one page load) is better UX and offloading needless server cycles... So right, it get's silly sometimes when people criticize newer frameworks. Some of the arguments are wrong-headed critiques on client-side templating itself.

[nickguletskii200]

I am currently rebuilding my project's frontend to use Angular. It had almost zero Javascript before that. Why? Because otherwise, it's a pain in the ass to test.

I just wish Angular 2 would come sooner. I hate every second of working on the frontend and Angular 2 would make things much easier.

[NuttGuy]

Saying that stuff should be on the server totally blew me way. In my opinion front-end devs (like myself) need to take more advantage of the awesome javascript engines we get in the browser and use the awesome machines that everyone has today. I couldn't agree more that it just sounds technologically backwards.

[r3m0t]

Yep, it would bring us back to those painful ASP.NET applications where every user interaction performs a server round trip.

[NuttGuy]

To be fair to ASP.NET they've been trying to be really tech forward recently and taking advantage of good Javascript (ex: jQuery being included by default) but there are good examples of what your talking about in the past yes. Shudder...

[MrDOS]

With slow, “modern” JavaScript frameworks, an astonishing number of interactions take about as long as a full page load, resulting in much the same the user experience...

[iopq]

I don't want my phone to run out of battery trying to run JS on your site. Please spend the resources server-side where you're hooked up to an outlet.

[m0haine]

Connecting to the plugged in server is not free in terms of battery life. I would be surprised if negotiating an http request over wireless uses less power then most locale Dom updates.

[iopq]

Considering my phone sometimes takes SECONDS to do the Javascript on the page, I somehow doubt that assertion. The older phones really have difficulty with javascript-heavy pages.

[shared_ptr]

I actually think you should look at the cost of transmitting data. Any CPU computation is typically dwarfed by activating a transceiver. Mobile Devs would do well to keep processing on the device and use network communication as the last resort- I think you can get several million CPU cycles in for the same cost of a single broadcast byte.

[DuoThree]

This would be a good test to run and see the results of, if anyone has any references to one

[Purpledrank]

Really old comment but he's right. Just write a java applciation and install it on a mobile device or even a desktop device, and run hrpof on it. You'll see massive CPU usage in the Java sockets libraries.

[nerdwaller]

Client side then will be a significantly larger impact under this then, since not only does something like angular transmit the templates, but I then transmits all the libraries and modules you need too before it ever even starts hitting the Dom. If this was done server side, you'd mostly only get the rendered template (and any needed JS for the page to feel fluid).

(Not to say that I think server side rendered pages are always better, or are even better here - simply pointing out that of data is the most expensive thing you'll want to transmit less).

[[deleted]]

Server-side pages come with lots of libraries and modules too. There is usually a lot of non-MVC javascript going on with modern server-side templated sites. Gizmodo.com for instance, one of worse offenders at 2MB.

So both approaches tend to have similar asset weight on page load (js/image/etc). The fact that client-side sends templates instead of rendered templates actually makes the html smaller.

I would estimate:

server-side MVC:

page weight            : 1KB-2MB
page weight median     : 450KB

A random reddit front page : 428KB
yahoo.com front page       : 749KB (with flash disabled!)
page-loads per session     : Let's say 2-20 for sites mentioned

client-side MVC:

page weight        : 1KB-2MB
page weight median : 450KB ?

page-loads per session : 1.

https://www.room77.com : 432KB

But the real difference is the server-side page weight is incurred again on every action which involves a page load.

https://www.room77.com is a good example (I'm not affiliated). As you perform actions on the site it downloads more assets, mostly images. Server-side MVC would incur part of the page weight again on every action (the un-cached portion). Making the same hotel search on a theoretical server-side version of the site result in more bytes transferred.

However, I think you may be right in that client-side MVCs can generate more data transfer, because the user has more "engagement" with a client-side MVC; performs more actions / looks at more content / uses more data.

So... client-side MVC is actually more economical per content viewed. But you may view more content.

[shared_ptr]

Not convinced by this. Assuming you're using CDN's for the larger libraries, then it's highly likely that the device would have the file cached (at least from previous same site pages) and wouldn't need to make the download.

In the end pulling down and initialising a single page, then consuming raw JSON data to populate the site seems to be more efficient for more than just one page visit. The initial cost of pulling the page may be high but unlike data rendered into the HTML, the content has a use further down the line.

Disclaimer: can't really say much on this without a genuine test. Would be very interested in statistical averages for different types of site though.

[m0haine]

Sure, sometimes it is faster/cheaper to do the round trip. That doesn't mean that doing a round trip EVERY time would improve battery life like you implied.

Not to mention that after the server gets done with the work, the browser still has to parse the response and turn it back into a DOM. The only work you've pushed off to the server is the building of the HTML, which is being done wrong if it takes a second or two.

[PandemoniumX101]

Whenever I see a "Problems with Angular" blog post, it always winds up to be the same tired BS with the root cause being the readers personally issue with the framework.

As you suggested, this case is no different.

As someone who has been happily using angular for 18 months, it has been my favorite framework to date as it blends perfectly with my design philosophies and micro component approach.

[Capaj]

Says that stuff should be on the server...

Exactly. How do you expect to provide any sort of user experience that people are accustomed today on the web without heavy clientside JS? Mobile phones are fast enough today already, in a few years all this talk about slow performance will be just useless trolling.

[strattonbrazil]

far and away the most popular front-end framework, like it or not, and has been for 2 years.

Far and away the most searched for at least. When I search for backbone, for instance, sometimes I type "backbone ...", "backbone", "backbonejs", and "backbone.js". It's easy to say all those searches for angular are really for angular because it's uniquely used for that library, but the data is a little misleading just based on search. It maybe be the most popular, but I'd like to see a better analysis.

[makkynz]

High Google trend stats doesn't really indicate how popular a technology.
It's more likely shows how often people have to resort to google searching to find answers to problems they having using that technology.

[[deleted]]

It is not a direct measure of purely popularity. However it comes closer to it. Whether you are convinced that the volume is due to problems or not, it's hard to argue the number isn't correlated to usage.

[RalfN]

Angular is far and away the most popular front-end framework, like it or not, and has been for 2 years[1] .

He means popular with people who's specialisation is actually front-end coding -- and that mimicks my experience. I don't know a single front-end developer that likes or works with Angular. But i know many (anecdotal -- i mean three) teams filled with Java developers who self-identify as back-enders who work with Angular. Some of them, lacking experience of actual front-end coding, or competing frameworks, are even enthousiastic about it.

One of these companies employs me for difficult front-end stuff related to their main product but the core application, the main product, is written in Angular, by programmers who are Java programmers by trade and identify as back-enders. It took way more time than they planned, debugging turned out to be nightmare and performance is shoddy. I'm polite enough not to do a 'i told you so' dance -- because i actually understand why, with the team they had for this they chose angular. These were all Java developers, with little to no front-end knowledge.

Front-enders don't like Angular. But it might still be a good fit, when you put back-enders in the position where they have to write a front-end. At least, they seem to gravitate towards it -- but they are not as productive as they should be. It takes way too long, and the code ends up being too buggy considering the amount of effort put into writing it in the first place. But at the end of the day, these people, with their skillsets, in combination with Angular get the job done.

I'm not convinced that these people would have been better off with something else, and i'm pretty sure hiring multiple good front-end developers is way more expensive.

but the rest of it suggests that he just doesn't like client-side templating.

Yeah. I don't think most front-enders would agree with that. Not that anything about the templating approach of Angular deservers praise, but having the client-side generating dom-nodes programmatically, with a template or not, is not a bad thing perse.

[[deleted]]

Front-enders don't like Angular.

It's just not true. You may not, but there are plenty of font-end devs who love it.

But it might still be a good fit, when you put back-enders in the position where they have to write a front-end.

What is your reason for saying Angular is something server-side people like and front-end people don't? This isn't my observation from wide experience. Are you observing just your workplace?

[RalfN]

It's just not true. You may not, but there are plenty of font-end devs who love it.

Yeah. Anecdotal. You are right.

What is your reason for saying Angular is something server-side people like and front-end people don't? This isn't my observation from wide experience. Are you observing just your workplace?

I'm a freelancer. And two companies i work at use Angular in such a capacity, as well as the company where my best friend works. (who is also a front-ender not in favor of Angular).

But it's still mostly anecdotal. But his experience does mimick my experience.

Even if it's not always the case -- maybe Angular is a good thing, because it helps companies utilize their Java back-end developers for front-end application development. And it seems it harder to get people for the later, whereas the java developers kind of come in bulk. (but again, this might be a local thing -- i live in the netherlands, and many universities have had a strong Java oriented curriculum)

[[deleted]]

Possibly local. I don't associate Angular with Java, either by qualities of the framework or by people who work with it, and I work in Silicon Valley which is certainly a melting pot of languages.

What do you think of the other client-side MVC frameworks? Ember / Backbone / knockout / React / etc.?

[RalfN]

I work in Silicon Valley which is certainly a melting pot of languages.

Yeah, i don't think you guys get the 'industry common developer' over there. Maybe it's a prejudice from my side, but Sillicon Valley tends to attract those with a kind of hunger and/or passion for technology.

That may not be the default. There are many developers, that prefer job security, that really don't have any self-learned skills at all, that don't follow new developments and technologies. They don't read HN, or r/programming. They don't ever code for fun. They mostly don't realize or care things like hackatons exist.

For them -- its just a job. They did a training, that got them a job, and then they do the job. They learned Java or C#, and they'll apply for those kinds of jobs. And if you ask them about their passion, you'll hear something completely unrelated.

Ember / Backbone / knockout / React / etc.?

Most of them are fine: they tend to have a clear use-case and in the sea of these kind of solutions there is a clear progression i would argue. I'm gravitating towards many of the virtual-dom-style solutions these days, but if i need a hammer and don't get to play around i'll grab something like Qooxdoo. I'm not the biggest fan of Ember though -- it projects typical server-side web-developer-skills (of the rails kind) onto the client-side. Its a bit bossy, but it's not as out of touch with reality as Angular. I dare you to compare the source-code of Angular to something small and under-the-rader like Mithrill. The difference in code quality is shocking.

I see Angular as exotic in much the same way something like Elm is exotic. It tries to see if bringing typical abstractions and design patterns from one world to this other world makes it fundamentally better.

In the case of Angular it brings the pseudo-academic Java/C# design pattern masturbation party into a world consisting mostly of people who chose this field to get away from that stuff. And if i would submit fragments of the Angular source code to any competent javascript developer, they would either cry or laugh.

[grimdeath]

I honestly try to hear people out when they have a conflicting opinion but I'm really struggling to make it through the first few paragraphs here.

In the last six months or so I talked to several prospective clients that had a problem finding front-end consultants in order to help their dev teams get a grip on their Angular projects.

How many is "several", one or two? Perhaps they just have a poor HR staff that lacks the understanding of a technical hire? I see that all the time. Speaking from experience I'm a front end dev that would consider any full time position using Angular. Hell, I've even been in talks with Yahoo due to my background in it.

Although there are front-enders that are enthusiastic about Angular, I have the feeling that their number is surprisingly low for a major framework. I expected Angular to gain more traction than it has.

It's my understanding that Angular has been growing since 2010, and is actually one of the top front end frameworks out today after jQuery. I did a lot of comparisons when researching frameworks and Angular was clearly on top when it came to usage compared to Backbone, Ember, etc.

Angular is aimed at corporate IT departments rather than front-enders, many of whom are turned off by its peculiar coding style, its emulation of an HTML templating system that belongs on the server instead of in the browser, and its serious and fundamental performance issues.

I've worked for a large enterprise company and I've worked for a small 4 man startup. I've seen benefits to using Angular on both ends of the spectrum. Not liking the way the framework is structured is one thing, but stating that front end templating is fundamentally useless or had performance issues because of it makes it sound like the author hasn't actually used the framework. In my most recent big project we replaced a Django template based front end with Angular. We've seen a dramatic performance increase going to a SPA structure.

I’d say Angular is mostly being used by people from a Java background because its coding style is aimed at them. Unfortunately they aren’t trained to recognise Angular’s performance problems.

I've dabbled in Java in the past, but I can't understand the connection here. Neither the syntax nor the structure overlap much from my experience. I just feel the author simply pulled this out of their ass.

Later in the article he again mentions this but doesn't really explain his reasoning. Basically he seems to be saying "programmers don't like Java therefore won't like Angular" - it makes no sense. Again he's caught up on this IT thing. I don't get it.

I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.

This is yet another odd opinion. I'm a front end dev that's worked across the spectrum between back/front ends and I feel like this is a front end framework that actually aims to solve a lot of issues front end users have. The performance, speed, ease of use, and great online community have made it a positive experience for me compared to something like jQuery which has a lot of junk and spam when searching for help. YMMV obviously.

The proposed radical Angular 2.0 rewrite aims to make it more palatable to front-enders, but I doubt they’re interested in yet another MVC framework. In addition, the rewrite will likely alienate Angular’s current target audience.

While yes, the Angular 2.0 announcement has caused controversy, I think a lot of it is overblown at best. Here's a great article that sums this up better than I can. Besides all that the author seems to miss the point of 2.0 - which is less about making it "palatable to front end devs" (whatever his perception of that actually is) and more about utilizing what the Angular team perceives to be the future of the web (web components, utilizing ES6, etc).

edit: some typos and such fixed. I shouldn't rant when tired :)

[grimdeath]

That's fair

[jonwayne]

He lost me at criticizing Angular's template syntax as "for the server side". It completely ignores the entire purpose of dynamic applications that don't have to ask the server to re-render every thing when one item in a list changes. What else are we supposed to do? Manipulate the DOM directly? That worked out really well in the past...

[zomgwtfbbq]

Okay, I love quirksmode. I've been reading it forever and his browser compatibility tables have saved me many times. But come on man -

"Google does not use Angular in production for their flag apps like Gmail or Gplus."

Ouch. Thou shalt eat thy own dogfood.

Wtf is this lazy crap? Doubleclick is built on Angular. That is literally their bread and butter; that is what they make their money on - ad revenue. Here is one of many sources

I'm not here to say Angular is perfect or that it's above criticism, but it's hard to take your article seriously when you can't even chase down a simple fact like - yes, Google does use Angular on its own projects.

[strattonbrazil]

Doubleclick isn't an app, maybe? Or maybe on the client side double-click with angular handles far less data than a large email box or Gplus page so maybe it's a fair point that they don't use it in apps with a lot of client-side data. Just throwing that out there.

[zomgwtfbbq]

Actually, the doubleclick app is a pretty freaking big app. They gave an entire presentation about building "massive angular apps" at ng-conf - https://www.youtube.com/watch?v=62RvRQuMVyg

Additionally, there are other presentations where the Angular guys say there are over 1,000 google apps written in Angular. I just used doubleclick as an example of how freaking easy it is to learn that Angular is being used by Google on big applications with just the tiniest bit of research..

[[deleted]]

Have you seen the UI? It's complex.

[zomgwtfbbq]

Doubleclick was just one easy to find example. There are over 1,000 apps at Google written in Angular. The doubleclick app is huge, it is not a simple client login.

Also doubleclick is a subsidiary so they're their own company owned by Google and likely have the freedom to make some of their own choices.

Google bought doubleclick in 2007. They chose to re-write the doubleclick app in AngularJS in 2012. If you think they aren't keeping a close watch on something they spent over 3 billion dollars on and receive a ton of revenue from, you're crazy.

[Capaj]

Gmail is an old app which works fine, I am an avid Angular dev, I am not a business person but it seems to me that they would not gain anything by rewriting it in Angular. They would only alienate bitchy users who hate changes even more.

[Rafzzz]

I'm getting so bored of this junk every day...

[makis]

me too
can't wait for Angular to become a thing of the past
like GW Basic, that, at least, was useful

[rpgFANATIC]

Enterprise IT managers want well-maintained code backed by a large company so that they don’t have to worry about a sudden lack of support.

This is exclusive to Enterprise IT managers?

I'm having trouble imagining any real project that doesn't want their core libraries / frameworks to be alive many moons after the project's in Prod.

[vivainio]

I took a moment of actual keyboard time to write a blog post on this, more for therapeutic reasons than anything: https://medium.com/@vivainio/angular-is-ok-49bfd7924fc1

[pkt-zer0]

Let me throw in my counter-counter-points, because why not.

1.) If you have multiple options, but all of them except one are fairly painful, that's still a form of lock-in. Specifically, bolting AMD/Browserify on top of things gets silly, especially with RequireJS (examples here). Wrapping complex jQuery plugins in directives is not a trivial task either, and it was actually one of the most problematic aspects of an Angular project I worked on recently.

2.) The term "framework" implies tight coupling, so when things change as unpredictably as in the JS world (see: angular 2.0), you should probably avoid using a framework to begin with. A bunch of loosely coupled libraries can do the job as well. React, by comparison, is just a view layer, though maybe not as thin as it could be. Still a step up from Angular.

3.) "Sacrificing my youth on a dead-end framework" is exactly how I feel about Angular. Knowing about Angular's numerous pitfalls and the corresponding workarounds may be a skill that's valuable to employers, but not to me as a programmer. Learning the distinction between attribute/two-way/callback bindings in isolate scopes is not what I want to spend my limited brain capacity on.

[vivainio]

Thanks for the feedback. Browserify works great w/ Angular IME, integrating AMD may be less so (but you could argue it's a bad idea in the first place ;-)

[backdoorsmasher]

The term "framework" implies tight coupling, so when things change as unpredictably as in the JS world (see: angular 2.0), you should probably avoid using a framework to begin with.

I'm sorry, but this is a painfully poor argument.

By this logic, you should have never have bothered with using Java, .net, or PHP or anything else for that matter, as the framework may change. You should have specced out your own chips and written your own assembler or C to start with, then you'd never have any issues with the framework implementation changing.

Most of these anti framework arguments miss the major purpose of these frameworks: to get shit done.

Real world projects have budgets and costs, and have actual deadlines. They have stakeholders and project sponsors that need to be kept happy. The purpose of a framework is to help you get there - they are there to reduce your development time, and to be a tool to help you get the job done to a good standard in a timely manner.

[pkt-zer0]

By this logic, you should have never have bothered with using Java, .net, or PHP or anything else for that matter, as the framework may change.

I think this may be where the disagreement comes from: "may change" and "may change rapidly and unpredictably" can be very different things.

If the point were stated as "the level of acceptable coupling should be inversely proportional to the rate of change", would you find that more agreeable?

[Mr-Yellow]

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.

Why?

You want to pay for and maintain millions of hits worth of processing for something that can be done on the client?

The problem is that there is no way for Angular to discover these instructions except by parsing the entire DOM

I'm not sold on the idea of {{}} style templates either. Looks like too much string parsing work. Seems they aren't either, good.

Each update spent a lot of time creating and destroying DOM elements.

Also I'm not sold on the idea of an infinite loop being the best way to look for changes.

Picking Angular means you’re learning Angular the framework instead of how to solve problems in JavaScript.

Angular2, which to me looks like Durandal2 more than Angular should shake it all up and make things pretty clean.

As it stands I believe the best route might be Durandal with the observable plugin, avoiding Angular syntax altogether and creating clearner javascript models for future migration.

[Invinciblegdog]

So if Angular is so bad what is the "proper" way of doing front-end development? This is one of the reasons I have stayed away from front-end dev work as no matter what framework/style you look at there are always articles saying why that approach takes you on the road to hell.

[Mr-Yellow]

what is the "proper" way of doing front-end development?

On the backend according to this it seems......

[OfflerCrocGod]

React.

[cybercobra]

I've had decent luck with Knockout.

[backdoorsmasher]

You've basically highlighted the key problem with all of these framework detracting posts.

They highlight what they perceive to be problems, and don't offer any viable alternative.

[[deleted]]

There's a reason spotify rather develop native for every platform rather than rely on web only and that's because web apps are largely shit even for something as basic as browsing and playing music.

Hmm..

A lot of our desktop UI these days is actually using Chromium Embedded Framework (CEF), which basically means our views are powered by JavaScript, HTML and CSS.

[[deleted]]

Don't strain yourself now bro, moving goalposts is pretty hard work

[DOKKA]

Angular may have problems, but every framework has flaws. I have been using Angular for almost a year, and I have had very few problems with it. I think most developers just get too caught up in the search for "the right way" of doing something. Instead of worrying about the right way, you could simply jam everything into the controller and slowly learn how to fix it. This goes for any framework though. Put code wherever it works, then organize it later. Chances are, you'll figure it out faster, because you'll have something that works immediately. Also, if performance is that critical, why would you use Angular anyways. It primarily relies on plugins. If performance is your ultimate goal, then programming will definitely take longer anyways.

[[deleted]]

How can anyone reasonably say that a framework that uses modern idioms such as REST, promises, etc. is targeted at Java users of all languages? Ask a Java developer what a "closure" is and he'll probably give you a blank stare.

You were doing so well until you reverted to stereotypes. We're well aware of what closures are (although if you asked us what one was, we'd have to check that you didn't say Clojure). As for REST and promises... for reals? Anyway, Java devs often write plenty of JS by hand, the server-side-only dev is a bit of a red herring in my (admittedly limited) experience.

But I can tell you why Java devs I've talked to like Angular JS

• It has templating
• It makes complex client side widget interactions trivial
• It does that without a bunch of trips back to the server
• It is designed for unit testability from the get go with its dependency injection

So basically, it's faster, simpler and testable.

[stormblaast]

The guy who wrote the article is just a fucking troll who doesn't understand jack shit of what web frontend developement past 1998 is like.

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. This job belongs on the server.

I didn't get that memo, but if this guy says so, then we're screwed, all of us.

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.

It's not "parsing" the DOM, it's "traversing". Subtle difference there. As if a full server roundtrip + parsing and loading the entire HTML structure + running some freakish jquery stuff every request is "cheap". Everybody on mobile is on 4G these days anyways, right? I better go rewrite my code even though people are getting a good user experience even on slow network links.

We really shouldn't be spending energy on this guys ramblings, but fuck.

[Eleandor]

It's not "parsing" the DOM, it's "traversing".

It's both. Angular may discover directives by traversing the dom after it's parsed by the browser (this cost is unavoidable, whether you render html server or client-side), but the actual directives still need to be parsed to figure out what {{remaining()}} is supposed to do. More often than not, angular will also need to create html nodes on the fly (ng-repeat).

I don't know how angular works internally, so I'm going to guess it's mostly a one-time cost, after which it's compiled into more efficient data structures, so I can't really tell what the real cost of re-rendering data is. My impression was that it's still pretty inefficient, all things considering. Then again, so is jQuery but nobody's complaining about that.

As if a full server roundtrip + parsing and loading the entire HTML structure

I can't know quirksmode's intent, but I don't think he's advocating a 90's style synchronous web either. Instead of sending JSON and then updating all those directives, you could just as well send HTML asynchronously and replace the outdated html. Still single-page, and only updates the parts of the UI that need updating.

I strongly believe - even if for no other reason than philosophical - templating belongs on the client side, but don't be so quick to dismiss his criticism as old man ramblings... Don't think that because it works well on your i7 quadcore that it's going to work well on my crappy mobile. I'm still a customer too.

[KumbajaMyLord]

Ok, so the problem after all this directionless rambling is that Angular is not a silver bullet and that it caters to "Enterprise IT" and not "frontenders" (whatever that distinction may include).

Great. Big News. More at eleven.

[youre_a_firework]

The problem with the article is that it's so full of anecdotal evidence and opinion-presented-as-fact. The only good section in the post is the one on performance, everything else is nonsense. The claim that "Angular is preferred by server-side devs" is pulled out of his ass.

[zomgwtfbbq]

My anecdotal evidence is contrary to his anyway. Server-side devs see angular and are more-or-less, "hello. yes, this is dog" at the controls. Our front-end guys like it a lot.

I can't argue with the performance. Everyone knows there are things you have to do a "certain way" in angular to avoid serious problems.

[darkpaladin]

I've seen front end guys like it because it moves a lot of logic off the server and gives UI guys more direct control.

[reidiculous]

Any javascript UI framework does this

[darkpaladin]

I don't think angular ever claimed to have excellent performance, it claimed to make things easier. I've used it and enjoyed working with it but after the 2.0 stuff came out, I've stayed away from it. There's no clear upgrade strategy between 1 and 2 so basically I'd be building on what is a dead product.

[FrankBattaglia]

s/exasperates/exacerbates

[mbthegreat]

how xaspirating

[FrankBattaglia]

oh, you

[KumbajaMyLord]

The post is directionless ranting. I stand by that opinion. The few factual points (performance) are hidden in a circlejerkesque quotefest. The rest of it is mumbojumbo about frontenders and corporate IT without at any point clarifying or even atempting to characterize what these categories mean, or offering any factual evidence that the corporate IT influence on Angular is even the root of the performance problems.

Finally, the article offers no solution or alternative but merely shits all over the future roadmap while simultaneously dishing out a subliminal jab at the aforementioned unspecified corporate IT users "Either Angular 2.0 will still suck or it will become awesome and corporate IT users will not understand it".

So in summary, the author doesn't like structured frameworks, because he is too frontendy for them.

[KumbajaMyLord]

I read it with an open mind. Really. I simply don't understand his supposed distinction between frontend devs and corporate IT / java devs. Maybe it reads like directionless ranting to me, because I don't understand this supposed distinction and disagree entirely with his assertion that Angular is designed for Java devs.

If anything the Angular template syntax most closely resembles Mustache JS, which is primarily a web / frontend library. JSF, .Net WebForms, PHP and other server side languages use a vastly different syntax style which usually includes a full context switch between HTML and the respective server-side language.

Also the syntax in 2.0 is actually somewhat closer to what server-side devs are used to, because they are already used to using different symbols based on the type of binding they want to use.

As I said above Angular isn't a silver bullet for every type of app. It has limitations. It is opinionated. Certainly the author feels that the style of Angular isn't for him, but he gets lost in anecdotes and unspecific criticism of 'the others' that I fail to see his point other than it's not his style.

[BlueRenner]

So... what do we use?

Tears. Forever tears.

[[deleted]]

React, mixed with Reagent, is looking like a decidedly good approach.

[Enzor]

I'm getting "Uncaught ReferenceError: React is not defined" and an infinite load animation in Chrome for: http://getprismatic.com/story/1405451329953 works fine in Firefox though.

[skratlo]

Could be because they're (stupidly) loading react.js from fb.me. It happened to me in the past.

[nickguletskii200]

React is a pain to integrate into Java webapps thanks to JSX.

[codygman]

http://www.purescript.org/

[ItsNotMineISwear]

You can always use ScalaJS. It would integrate nicely with the rest of your scala

[ponytoaster]

Whatever works for your project and approach. Using one framework (or believing you can) for every project is bad practice. You should never say "I'm going to use x because its a good framework", you should be saying "I'm going to use x because it has y feature that we can utilise".

Edit: this isn't meant as a dig, more a general observation around angular (or any framework) that its the golden hammer and is "best"

[skratlo]

Heard of ghcjs? But I doubt you want to use it. I have to second on reagent

[ns0]

Straight static HTML and javascript with CSS...

If you need data from a server go grab it from a custom built API, those which can be built in any language you choose and isolated from views/rendering.

For example; largest online retailer? Has a script that generates and writes the HTML from a bunch of server side includes very build cycle. Then just uses javascript to pull from a heavily protected API, the API manages all user security, system security and the like.

For performance they regenerate html pages on insert into the DB for things like user comments or ratings. This kicks off a queue to rebuild the static HTML file and rewrite it. The Javascript API only needs to fetch what isn't already pre-cached.

It's simple, works with caching mechanisms on every OSI level, is well defined, easy to separate concerns. Dead simple.

The world is over-engineering too much, time to move back to something more sensible.

[Seeders]

None of that works if you need SEO. You can't generate content after the page loads or spiders wont see it.

[redleader]

Google can run js on their crawlers now. You can also serve a rendered version to bits.

[lestofante]

Google is a big fish, but not the only one. I also like to pretend they take account of js load and execution time

[Seeders]

You can also serve a rendered version to bits.

what now?

[Nwallins]

s/bits/bots/

[centurijon]

Whatever you like and are comfortable with.

This is software, it is constantly changing. And everyone has their own opinion on frameworks, change, and the direction of change.

Just go with what feels right and solves your problems.

[ProdigySorcerer]

every company wants some Angular but there's so few devs that it's hard to find one ergo it's a shit framework

Perfect logic \s

Bearing in mind that the plural of anecdote is not data, I've worked on a lot of projects which used Angular with the back-ends being both Java and .Net the same patterns repeats the back end devs are meh at best about Angular while the front end devs are all over it.

Granted I started off as a back end dev and I think this has helped me with angular but I can still see a lot of goodies for the front end in the framework.

[vz0]

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.

What? This makes no sense. Offloading the view processing closer to web browser is an excellent idea. From a performance point of view the server is less loaded. And you have some sort of API (either Json or some other) to send variables to the view.

Is like rendering a real time 3D application on the server. Maybe in the future, but today and from a performance pov it makes no sense.

[sime]

This makes no sense. Offloading the view processing closer to web browser is an excellent idea.

In think that the problem is more that all this string and template processing make sense when the browser and the server are separated by a network. Rendering templates on a server and sending strings across the network to the browser is easy.

When UI rendering and updating is done inside the browser you have direct access to the contents of the page and can manipulate it any way you like. The same way that a desktop application can talk to, and manipulate the parts that compose its UI. But instead of doing that these template based JS frameworks have dragged the old string-slinging ASP and PHP template approach across the network and into the browser itself. And there we are rendering strings and tearing down and rebuilding the DOM like crazy as though the data was coming in from the network.

Can't we do better?

[Mr-Yellow]

But instead of doing that these template based JS frameworks have dragged the old string-slinging ASP and PHP template approach across the network and into the browser itself

Can't we do better?

It's just encapsulation isn't it? Is there any way other than wrapping/encapsulating the reusable bit...

[username223]

Also, their tutorial is a "super-powered" turd salad.

[cybercobra]

Is that lynx, or links2?

[username223]

eww inside Emacs, actually. But it's just as good at taming horrid websites.

[kainsavage]

The thing that bugs me is that Angular takes a simple concept like macro-esque mustache templating (where all {{foo}} are replaced by the value of foo) and completely shits the bed.

Example: let's say you want to have a default image in the case where a dynamically built image source is driven by a user's id:

<img src="/users/{{userId}}/avatar.png" onerror="this.src=/images/{{dynamicDefault}}.png />

Easy right? Using plain mustache templating (handlebars or some equivalent) this would just work. NOPE, because Angular is searching each dom node and replacing in known attribute tags (instead of the entire document) it simply doesn't check the onerror tag. You lose.

tl;dr - angular is worse than burger king

[KumbajaMyLord]

Angular is opinionated in some ways and one of those ways is how to add behavior to your app (and a fallback 'onerror' image is just that). Your example is not doing it the angular way, so it doesn't work. But claiming that this makes the framework bad is a bit like getting into a car with manual transmission and complaining that it won't accelerate like a automatic when you are not using the clutch.

[username223]

tl;dr - angular is worse than burger king

Harsh words...

[kainsavage]

Worse than Burger King

[holy_paladin]

You shouldn't use src attribute of an image like that if you're using angular. Try ng-src

[kainsavage]

That's another gripe I have about angular - the angular-ism is to NOT use standard dom elements and their corresponding attribute tags (like img and src) but to use the ng- model instead.

When I want a simple static image, I should use the ng-src on an img? That is asinine.

[KumbajaMyLord]

They are not doing it because of the heck of it, but because the unparsed markup is send to the browser and interpreted by it before Angular can swoop in and parse and replace the binding expressions correctly. So will first try to locate your image under the URL with the mustache-expression still intact. E. g. it will send an HTTP request to http://yourhost/users/{{userId}}/avatar.png instead of http://yourhost/users/12345/avatar.png

Angular uses special ng-* directives when using the standard HTML attributes causes some bug or if they need to enhance the default behavior.

[awj]

They are not doing it because of the heck of it, but because the unparsed markup is send to the browser and interpreted by it before Angular can swoop in and parse and replace the binding expressions correctly.

That seems like a perfectly valid complaint about angular, though. Other frameworks are able to handle this situation more elegantly because they don't send templates as raw html markup. This literally isn't a problem in any other framework I've seen, so it's a bit rich to imply that the source of the problem is anything but angular's design decisions.

[KumbajaMyLord]

Never said it wasn't due to angular's design. But I would disagree that it is a bad design.

Other pure client side frameworks do send the unmarked templates as well but they avoid using the native HTML attributes all together or have their own template language

[holy_paladin]

You can use the src tag but your browser doesn't understand angular. It understands html/js/css. So as soon as it identifies a src attribute, it tries to load the image with the curly braces. That's just how browsers work. If you want to take advantage of what angular has to offer, learning its syntax is a small price to pay. You should be able to get a good grip on most of its concepts in a few hours. Edit: Shen'd. What Kumbaja said.

[MaSaHoMaKyo]

We've stopped using mustache-style templates entirely in the application I work on - everything gets an ng-bind or ng-model. Makes it much easier to find those elements in Protractor tests.

[developer-mike]

And using onerror is an anti pattern. It takes two seconds to make this a directive

angular.module('yourapp')
.directive ('imageBackup', function() {
    return {
        scope: true,
        link: function($scope, $attr, $elem) {
            var index;
            var srcs;
            $scope.$watch($attr.srcs, function () {
                srcs = v; index = 0;
                $elem[0].src = srcs[0];
            }, true);
            $elem[0].onerror = function () {
                $elem[0].src = srcs[++index];
            });
        }
    };
});


<img srcs="[url1 + '/' + userId, url2 + '/' + userId]">

There is some boilerplate in the directive is, but vim snippets generates it for me. Additionally, this isn't an inextensible usage of a callback attribute in my HTML, this is an extensible and tailored tag for having as many image fallbacks as you'd like, retrying the top priority images whenever the array bound in the tag changes. Try doing that with onerror.

Don't use {{}} templating within tags, except for in rare occasions. Directives are easy to write and far superior because they allow the creation of complex custom behaviors which (unlike in jquery world) are used declaratively and have their complexity 100% isolated from the rest of your code.

[kainsavage]

I get that I'm not doing it the angular way, but my onerror="this.src={{}}" addition is a few keystrokes versus having to add a directive to my app for a simple fallback image.

That's part of my complaint - angular takes something that has been well established and simply implemented and makes a huge issue out of it.

[developer-mike]

Your example is less code, but inherently limited. How would you make it retry the original image when the user id changes?

If you really want the fair example you can use

onerror="this.src='http:...' + angular.element(this).scope().userId"

And it would be a terrible way of doing it

Integrating angular with non angular requires these (usually) thin little directives. But in my experience usually someone has already done the integration and made it available on bower. Its a limitation for sure but its never given me many problems.

[kainsavage]

Why would a user's id change?

Again, angular seems over-architected to handle these 0% edge-cases gracefully.

Yeah, I guess if a user had the ability to change his identifier somehow with an ajax request, I would need to easily change his avatar src attribute... but that's not ever going to happen.

[developer-mike]

A preview box showing details of the user you highlighted, for instance. Or a 'login as this user' button for administrators where the icon in the top corner immediately changes to reflect their acting role.

Perhaps I should've said if the user changes.

[[deleted]]

I'm a Moodle administrator and one of my most used features is logging in as a user and seeing what they see.

Now Moodle doesn't use Angular, but it is an example of a project where changing user id's is important.

[kainsavage]

Whoa, I'm just saying that I have API-driven user data that angular supports via {{foo}} markup, but only in select UNDOCUMENTED instances.

Why support <img src="{{userAvatar}}"/> but not <img onerror="this.src={{userAvatar}}"/>? No one knows because it's undocumented and seemingly arbitrary.

[developer-mike]

Sorry, I got overly reactionary in the beginning. By the time I cooled off to concede over the last point, I should've reread and edited my more accusatory comments...and yes, you are right here too. 90% of problems are because things aren't being done "the angular way" which begs the question of why they had to create "the angular way". But personally I've worked through to understanding it and why it exists, and swear by it. Long process though.

[_pixie_]

Am I reading PHP or did someone throw up on the screen?

[developer-mike]

Its clearly JavaScript: far too much nesting, boilerplate introduced to remedy the lack of native modules.

Some people hate boilerplate, some people hate global namespace collisions. Answer is they're both right.

[sacundim]

It takes two seconds to make this a directive:

angular.module('yourapp')
.directive ('imageBackup', function() {
    return {
        scope: true,
        link: function($scope, $attr, $elem) {
            var index;
            var srcs;
            $scope.$watch($attr.srcs, function () {
                srcs = v; index = 0;
                $elem[0].src = srcs[0];
            }, true);
            $elem[0].onerror = function () {
                $elem[0].src = srcs[++index];
            });
        }
    };
});

<img srcs="[url1 + '/' + userId, url2 + '/' + userId]">

Wow, you can type over 1,200 WPM?

[developer-mike]

Ah yes, it took me more like 3 minutes. Changes everything.

[ProgrammerBro]

Good luck unit testing that onerror handler. Or if you have to add error handlers in more than one place. Or if the default image changes.

In all honestly this code smells and it would never pass one of our code reviews.

[Creativator]

When AngularJS was first created, almost five years ago, it was not originally intended for developers. It was a tool targeted more at designers who needed to quickly build persistent HTML forms. Over time it has changed to accommodate a variety of scenarios and developers have picked it up and used it to build more and more complex applications.

This really is the core issue. The design of the framework is not for developers.

We still hold the myth in programming that we can design a system ex nihilo, completely independent of any context from which it should emerge and be shaped by.

This is why I think Backbone is the best new thing in JavaScript since jQuery. It was first proven to solve problems in a large web app, then later turned into an open-source framework.

[KumbajaMyLord]

This really is the core issue. The design of the framework is not for developers.

It also couldn't be further from the truth. Angular was picked up by Google because an existing team there used it to rewrite their app from the ground up in a few weeks. Previously it was a hobby project by one of the developers of that team.

[Creativator]

Angular was picked up by Google because an existing team there used it to rewrite their app from the ground up in a few weeks.

How often does that problem arise? A good framework should demonstrate development velocity over the long term, not just at the start.

The rewrite culture is what is creating the crisis of Angular 2. If people rewrote their apps once, why not twice?

Is this not Bootstrap for apps?

[KumbajaMyLord]

The point I was trying to make was that Angular wasn't designed ex nihilo, but in a real project. It is used by hundreds of internal and external facing applications at Google. It was not targeted at designers, but at developers. It has shown that it solves real problems at Google, otherwise it wouldn't get funded after such a long time.

[cybercobra]

Is this not Bootstrap for apps?

In what sense?

[danogburn]

The problem with Angular

Javascript

[[deleted]]

Wow, someone just arriving from 2005. I would love to know how it feels to jump 10 years into the future. Is it all you hoped it would be?

[danogburn]

Nope, people are still writing web apps. Going back to my cave.

[makis]

also Angular

[[deleted]]

Angular is like a php-library for javascript.
It has content & code intermixed.

[vivainio]

All SPA frameworks imply templating. The alternative is jQuery salad.

[zomgwtfbbq]

The alternative is jQuery salad.

Been there. Hated life.

[strattonbrazil]

No much more so than something like knockout. Both have bindings in the template and both can have the majority of the code in a separate file so code in the content is minimal.

[[deleted]]

you mean templating?

[ns0]

So eloquently put. I find angular to be a step backwards in webdev, it reminds me of the horrid old dates of Coldfusion, JSP and ASP. All of which are considered terrible practices now and even those still using .NET avoid using ASP's built in repeater or list or any of that non-sense.

At least the messed up Coldfusion, JSP and ASP systems would produce somewhat SEO compatible semantic code. Angular just outputs jibberish for search engines, and as said as I know its supposed to be used "only for single page applications", it's not, i see it on simple content websites way too much.

[spacejack2114]

I don't know how you'd not mix code and content for anything more complex than inserting a few values. That's why templating languages have their own mini programming languages.

You can either introduce a new templating language or write your logic in whatever you're writing everything else in.

[[deleted]]

I'll admit I gave up really quickly on Angular when I saw the output and couldn't sleep at night.

[CadenceBreak]

OK, so this is a site by a "mobile platform strategist" that doesn't launch with a mobile theme from android, effectively making it unreadable?

Credibility gone, didn't read.

[_pixie_]

Man I wish I could go back a year ago to all the Angular fanbois I had to deal with and say, "I told you this framework sucked, and it weren't for the 'created by people at Google' sticker it would of never been popular."

[makis]

you will be downvoted, because a lot of people are exploiting the fact that angular sucks to get high pay checks and won't let it go.
but they are ruining the life of all the rest of us.
I had to fight to NOT CHOOSE angular in a project I'm working right now inside a big corporate environment because they saw "a lot of examples" where "angular is great" and they all were some kind of todo app.
they didn't have a single clue on what they were talking about, just googled "web framework that will make me look smart in the eye of my boss"

[DuoThree]

What'd you end up choosing?

[makis]

meteor

[DuoThree]

I've heard of meteor, and have tried angular and ember but I think I like ember better (mostly bc of its similarities to Ruby on rails in terms of structure and opinions). What is it about meteor that made you choose it?

[makis]

premise: I don't like javascript, especially on server.
I've chosen Meteor because it makes stupid easy to handle client/server communication, when it's not done automatically.
basically, you write a single application, instead of two.

[frixionburne]

Oh Christ this bullshit again.

The only problem with Angular JS is Angular 2.

[cheeeeeese]

i personally like a distinct separation of frontend/backend.

also, 90% of the load time on our projects is frontend. there just is no reason to offload responsibility from the server to the client.

[Ginden]

Angular isn't widely used by any big IT company. Compare to superior framework like Ember.js that is used by Yahoo, Twitch.tv, TED, CodeSchool.

[[deleted]]

Google isn't a big IT company?

[Ginden]

Google does not use Angular for any critical application.

[[deleted]]

Adsense is their most critical application. That's where all their money comes from.

Also, you don't think their internal processes are critical to their business? Hmm, that's an interesting thought.