
The problem with Angular - robin_reala
http://www.quirksmode.org/blog/archives/2015/01/the_problem_wit.html
======
jasonwocky
I don't really follow many of the author's objections. I think he or she left
out a lot of reasoning.

 _" 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.

~~~
lhorie
Just thought I'd add a bit of meta context: PPK (the author of the article) is
perhaps the first person in the js community to catalogue detailed per-feature
cross-browser compatibility tables. You could say he's one of the old timers.

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.

~~~
dpark
> _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)._

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.

~~~
lhorie
> in my (admittedly limited) experience Angular doesn't really introduce
> anything new

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.

~~~
dpark
My impression of Angular is that it makes simple things complex and that it's
poorly designed and engineered. I think that it tries to do too much, and
tries to be too clever, and doesn't try at all to be usable (beyond maybe
trivial examples, which could still be simpler, honestly). It speaks very
poorly of Angular that many (most?) people familiar with all the tools it
builds on (CSS, HTML, JS) find it difficult and unpleasant to work with.

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.

~~~
lhorie
FYI, I actually agree with you that Angular is overly complex and has a lot of
serious problems. I even wrote about my gripes with it back when Angular was
still somewhat "cool" (here: [http://lhorie.blogspot.ca/2013/09/things-that-
suck-in-angula...](http://lhorie.blogspot.ca/2013/09/things-that-suck-in-
angularjs.html) and here: [http://lhorie.blogspot.ca/2013/10/things-that-suck-
in-angula...](http://lhorie.blogspot.ca/2013/10/things-that-suck-in-angularjs-
follow-up.html) ), and last year, I wrote a micro-framework of my own to get
away from the frustrations I was getting w/ Angular ( I talk about it here:
[http://lhorie.github.io/mithril-blog/lessons-learned-from-
an...](http://lhorie.github.io/mithril-blog/lessons-learned-from-angular.html)
).

A lot of the stuff I wrote there is still relevant.

~~~
dpark
I didn't realize Mithril was yours. Seems nice, though I haven't used it
myself.

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.

------
pera
I usually have a terrible UX with Angular websites, I don't know if the
problem is Angular itself or the developers, but these are some of the
problems I usually experience:

-No HTML hyperlinks. This means that I can not open pages in new tabs, which it's very frustrating.

-Slow loading times. Static websites are much faster. Even non-cached server-side dynamically generated websites are faster.

-High CPU usage. To be fare my computer (1.4ghz c2s) is almost 5 years old, but using 100% to render a very simple "About us" page is ridiculous.

-Broken style when using some add-ons. This _only_ happens with Angular.

~~~
sosuke
No HTML hyperlinks is an annoyance, especially since part of Angular is being
in the DOM, but that is something that can be handled, the lazy method is to
just not do it. I guess that is something I like in a framework or library,
that the laziest method it promotes does the most work by default.

~~~
snlacks
The point of a framework though is to remove the boilerplate, best-practices
should be part of a front end frame work's default settings. The problem with
Angular's popularity is that it's often used for bad purposes (including in
their own guide as an e-commerce tutorial). Angular's strengths, solely IMO,
play up to large single page apps comprised of many small angular apps, apps
that don't use hyperlinks and aren't driven by sharing or SEO.

There's a lot of weird choices in Angular, but it's not broken though, and
enterprise will still use it because it is backed by Google, only a few
frameworks are backed by big companies, and it's less of a departure than the
other frameworks.

React and Backbone aren't frameworks in the sense that businesses need
frameworks, where repetitive decisions have conventions.

I just wish we'd stop trying to wedge these frameworks in to the wrong types
of projects. Angular is great, for our authwalled web apps, from my use. I bet
it would be for other people with the same needs, and wouldn't be for people
who are trying to build marketing sites, blogs, or e-commerce.

Edit: stray keystroke.

~~~
nemothekid
I'm working on a very large, single page app in Angular. I use HTML links
everywhere, and I thought that was standard. The router makes it so much
easier to use regular hyperlinks for navigation.

------
davexunit
AngularJS is a great example of over-engineering. Pretty much everything is
needlessly complex and poorly designed. Learning to use it was difficult, and
watching new employees struggle with it was painful. Newer libraries that take
a virtual DOM approach like MithrilJS are so much nicer to work with. They are
easier to understand, simpler, and faster. I wrote AngularJS applications
professionally for a year at my last job, and in hindsight I wish we had spent
more time evaluating the other options available at the time. AngularJS got us
away from a structureless jQuery mess (not blaming jQuery btw, but technical
debt from an application that grew too quickly), but what it created was a new
kind of mess that is much harder to fix now that the team bought into the
"Angular way".

~~~
k__
Wasn't the point of Angular, bach in the days, that it isn't over-engineered
and was put together by some guy at Google to show that it can go easier than
with GWT?

I remember, 2 years ago, I was on a JS-meetup, and some guy was rambling about
how Angular is the hot shit.

Funny thing was, he always said "yeah we had often the feeling, that something
was fundamentally wrong with Angular, but after a few days into a problem, we
found that we were wrong and Angular got it right."

His main argument was, that he uses Angular, because it feels better to use
something "a guy at google did for fun"

~~~
coldtea
Which sounds more like pop-culture (to quote Alan Kay) and not science or
engineering...

The guy might as well rock a yo-yo for the way he's into fads...

------
susan_hall
The reality is, Javascript has problems, and smart people disagree about how
to solve those problems. The proliferation of frameworks is a symptom, but the
frameworks are not themselves the problem. Javascript has some quirks, that is
for sure, and then, independent of Javascript, HTML/XHTML has its quirks. Most
ambitious sites today are trying to deliver software as a service, but HTML
was conceived as a publishing mechanism for documents. The emphasis on
publishing brings in some baggage that complicates any conversation about
doing HTML right. Consider the holy wars that have raged regarding the word
"semantic". There are many GUIs in the world that focus strictly on visual
representation and programming mechanics. Think about Java/Swing, or GTK, or
Flash. Swing does not aspire to be semantic, it only aspires to give us a GUI
for those who would create a GUI app with Java. GTK is the same, it is for
programming environments. But Javascript/HTML is given the task of being both
a programming environment and also a publishing platform, with semantics and a
hierarchical document object model. This is a confusing burden to put on
something that most people nowadays only want to use as a programming
environment.

In the short run, I do not know what the solution is. I suspect developers
will continue to invent new Javascript frameworks in an effort to create
sufficient levels of abstraction to ease the pain of development for the Web.
In the long run, the solution for the industry will be polyglot browsers, and
polyglot protocols, that can work as a runtime and thus give developers the
kind of freedom on the frontend that they already have on the backend. Despite
the many brilliant minds working on the issue, Javascript is never going to
work as the byte-code of the Web. Something more general is needed. On the
server, the JVM gives developers a runtime that allows them to use many
languages, and many different paradigms: Scala, Clojure, jRuby, Jthyon, etc.
We need that kind of flexibility on the frontend. And we need protocols to
support that runtime.

~~~
einrealist
That sounds nice on paper. But would it not be a security nightmare and result
in browser fragmentation?

I rather tell my customers to embrace HTML and a concept where a URI has a
main concern and if I want to see that concern, I have to load the page. I
like to build web applications that work without Javascript, but enhance the
page for better user experience, when activated. (Like the old (sane) times.)

It would be so nice, if I can just mail a link or make a bookmark and when I
follow that link, I don't get a firework from a client-side application that
tries to magically restore state.

BTW. I have JS deactivated by default and I am not the only one (security
measures, privacy, insane amounts of JS loaded by e.g. news pages). I tend to
be annoyed, if the page does not work without JS.

~~~
smeyer
You're obviously not the only one who deactivates javascript by default, but a
quick google brought up numbers of around 1% for users with javascript
deactivated. I can see why a lot of developers wouldn't be too concerned about
that 1%.

~~~
vanadium
It used to be that a significant portion of that 1% (and those that also
turned off CSS) were from those leveraging screenreaders some years back; with
the uptake of ARIA and better screenreaders, not so much the case anymore.

So there was once a definite use case for supporting them in a B2C context, at
least. You still see it in .edu/.gov/.mil quite a bit as a requirement (Sec
508, et al).

------
onion2k
Rendering on the client makes a lot more sense. By sending the user a template
followed by the data necessary to fill it out you only send the structural
code once. If the user views 100 pages then that's 99 times you've not had to
send the HTML required to display the content. That's good news from a
bandwidth point of view, an environmental point of view, and, if you're clever
about how you code it, a rendering speed point of view because you only have
to replace the _content_ in some DOM nodes rather than repainting the entire
template. That can lead to a faster display than swapping in the rendered
content for some situations (particularly if the changes are small text
elements and you have a shadow DOM available eg reactjs).

If you're doing something _very_ complicated and your users have old or
underpowered devices then rendering on the server is sensible, but in the
modern web it really isn't appropriate.

~~~
pdkl95
Sending incomplete pages means those of us that don't run javascript[1] don't
actually see your site. First impression matter, and when your page is:

    
    
        SomeSite
    
        {{storyTitle}}
    
        {{storyBody}}
        {{curPage}} of {{numPages}}
    

...the common interpretation is "broken site". This current fad of being too
lazy to implement progressive enhancement is a regression. Rendering on the
server so you server up a _actual page_ is trivial, and you can still provide
javascript that loads the next pages faster. Serving up _only_ a template (or
worse: an _empty body tag_ ) is insane.

The usual counter is that "javascript is always available" not only ignores
the risks, I suspect the claim is based on bad data. How do you know how many
people disable javascript? We aren't going to be in most analytics...

[1] for the numerous security and privacy reasons. Running arbitrary
instructions in a Turing complete language is a bottomless pit of problems,
and "analytics" is still spyware. Google shouldn't get to build a log of every
page we visit.

~~~
smtddr
I actually would like to get HN's take on this. Maybe someone should submit an
HN poll. I'm still of the opinion disabling javascript is an extreme measure
and those that do it need to come to terms with whatever broken internet
experience they get. While I do think it's worth it to display to the enduser
something like _" Looks like javascript isn't enabled; you'll need to turn it
on for this site"_, is it truly reasonable to spend development time to make
your site functional without client-side javascript? Probably depends on your
audience. I bet sites that are more commonly accessed through Tor have people
more likely to have javascript turned off.

But yeah, anyone here work webdev where your webapp is expected to fully work
without client-side javascript?

~~~
wwweston
I've worked on projects where that was the expectation; I've _set_ that
expectation for projects.

The reasoning has both been concrete/practical and philosophical (but still
practical):

* Mobile processing time is still costly in terms of battery life and performance. And the number of http calls (and their latency) also makes a difference in performance; SPAs tend to have smaller requests but larger numbers of them and it seems to me that's actually the opposite profile of what 3/4G cellular networks are good at. (And while this is all less true on the desktop I'm starting to find it annoying that we're nevertheless finding ways to make things choppy and slow on 2 GHz machines with operations not more complex than _scrolling_ ).

* This is more vague, but I find there's a discipline imposed in starting the conception of the app in terms of plain HTML/HTTP that seems to keep things better organized, while projects that start with a focus on a rich/heavy UI devolve into overspecific yet mixed concerns more quickly. This doesn't work for everything, since some apps just aren't about resources and media types. But honestly, your app probably is. :)

* Being able to debug/autotest with something like curl is pretty nice.

------
marknutter
This article is ranting about single-page applications written with javascript
frameworks. The word "Angular" was thrown as click-bait because it's the
latest whipping-boy. From what I read there isn't a single valid complaint
that's specific to Angular.

~~~
wuliwong
I think it is inaccurate to accuse the author of using Angular as "clickbait".
To me that term is reserved for titles which don't match the content. Whether
you feel every argument could also apply to "every" js framework, you cannot
argue that this article was specifically about Angular. It included Angular
code, anecdotal references to real Angular projects, and various quotes from
sources all about Angular.

The one complaint the author made about the DOM parsing definitely doesn't
apply to React, though not sure how Ember and Backbone handle that sort of
thing.

~~~
marknutter
He could have replaced the Angular code with Ember code and levied the exact
same complaints. Re-read the article and try to figure out which complaints
aren't also valid for other large JS frameworks. It's clear he's a libraries >
frameworks guy, which is a perfectly valid viewpoint to have, but it's
cowardly to frame such a debate as a thoughtful criticism of a specific
framework because it won't draw rebuttals from nearly as many people who might
otherwise feel the need to chime in.

~~~
jbergens
He specifically mentions performance many times but has no statistics to back
this up. I have created a web app with Angular and it runs fine on old Android
phones and iPhones. We don't see any performance problems. Of course YMMV but
he/she makes it should like the performance is a really big problem that
everyone will get affected by which I thinks is wrong, most apps won't have
any major performance problems.

------
strickjb9
I can't get behind the article's idea that Angular is built by people who are
non-front-enders for non-front-enders. It's a bold statement that hasn't been
supported.

I'm an avid user of Angular and as far as performance goes: you have to be
aware of the hefty digest cycle.

We should all be well aware of the downsides of Angular. Just like any
technology, there are upsides and there are downsides. When used right,
Angular is a powerful tool and the downsides can usually be mitigated.

If I had to help support this article then I would restate the problem
statement: the field of web development has exploded and the barriers to entry
are nil. Frameworks now have to be built in such a way that they can hold up
to the abuse and misuse by less experienced devs.

------
LoSboccacc
I disagree with this:

"Although templating is the correct solution, doing it in the browser is
fundamentally wrong."

We keep forgetting that the decision of where to run the view logic depends on
the environment.

We have swung between cpu and bandwidth as bottlenecks in the last decades
multiple times, and that's how framework moved between server side and client
side mvc multiple times.

No approach is radically different. We moved to thin client when browser were
good enough; increase in bandwidth and smaller latency enabled rich client
application, making the browser thick again. Handheld devices however are
getting more common, so people are facing problems with all the logic and
content being manipulated on the client.

It doesn't mean the thick client solution is fundamentally wrong. Also it
doesn't mean we have to invent new strategies and pattern to solve this.

When you take a step back from the technology and return to the problem it was
solving, it appears to me that we are just back at the thin vs thick debate,
and as before this is not an issue of 'which is better', more of 'which is
more appropriate to the topology constraints we have'

------
cheriot
I've always respected the quirksmode blog, but this article is pure FUD.

Many of the criticisms are general to thick client web apps:

 _" I feel that Angular’s fundamental proposition blurs the line between front
end and back end."_

 _" Although templating is the correct solution, doing it in the browser is
fundamentally wrong."_

Others are intentional ignorant.

 _" Ouch. Thou shalt eat thy own dogfood."_

Google also makes GWT and Dart. Should they use all three on every product?
The more resources you have and the more demanding your circumstances, the
less any general purpose framework will make sense.

 _" In other words, Angular requires you to spend a lot of time to teach
yourself the Angular way of doing things."_

What part of this industry doesn't? Put the logic on the server and you're
learning Rails, Flask, whatever instead.

 _" Google will eventually stop supporting 1.x."_

Yes, years after they release 2.0. They've been very explicit about that and
it's a better policy than most libraries have.

I can't help but get the idea that the author just doesn't like the idea of
doing things differently than he always has. Good luck with that.

------
aidos
I disagree with the majority of this article.

There seems to be a theme in there that angular is too heavy (Java, templates,
performance, time reading DOM on load) for the front-end.

There's really a false premise at play here - that apps these days are as
simple as they once were. Imagine for a second that front-end applications are
vastly more complex than they once were (because they are). For any of us who
have built more complex front end tools, you need something to help you manage
the complexity you're now carrying around.

Now the rest of it starts to make sense. More uptake from backend devs than
front-end devs? The backend guys have built large complex systems in the past,
they know that a tool like this can help them and it's something they're used
to dealing with. Prescribed structure to your code? Yup, sounds good - I don't
want to spend my day figuring out someone's callback spaghetti or DOM updating
triggers from random locations. Front-end templates? If you don't need them
and you're using angular you are using the wrong tool for the job.

~~~
rimantas

      > Front-end templates? If you don't need them and you're
      > using angular you are using the wrong tool for the job.
    

What if nobody needs them, and hence angular ir the wrong tool for the job? ;)

~~~
aidos
Well, true, you don't technically _need_ them :)

If you're building an app that can't be rendered on the server, at some point
you've have to update the DOM - templates are one method that allows you to do
that in a declarative fashion.

------
radicalbyte
Sorry, I'm calling bullshit on his argument for server-side rendering for
increased performance.

Consider a typical SPA:

===

In my SPA I load one large html document and javascript file in. The html
document contains the 30-or-so templates my system needs to use. The script
contains logic and localization data for the user.

This is all cached.

As my users use app, Angular makes calls to my REST/JSON services,
transferring just the data it requires with a very efficient encoding. Some of
the data is even cached in local storage.

Now, imagine that I've moved the rendering to the server. Instead of
transferring a couple of KB of JSON data when a user filters a grid, I have to
transfer 30k of HTML markup. My HTML could be smaller, but my designers really
like to have class names on all elements. Plus the German text I see is really
long.

===

In this rather common scenario the SPA vastly outperforms the traditional
server-side render-as-markup sites I was making three/four years ago. Network
dominates, especially on mobile. It's not your CPU killing your battery, it's
the screen and radios.

If you're making a simple informational site - a newspaper, blog, marketing
site - then sure your performance will suffer, but that isn't the problem. The
problem is that you're using a excavator to plant a daffodil. You shouldn't
even need to use a server-side framework, let alone Javascript.

~~~
syllogism
Agreed.

Server-side templates only make sense if you assume that every user action
will end up needing the DB. If what you're building is really an _app_, and
not just a webpage, you can't expect to compute its UI on the server, making
the user wait for a network round-trip for every action.

If your app is built around server-side templates, but your UI doesn't need
the server, then you end up with a royal mess. The client has to do DOM
manipulation over the rendered page, so now the templates have to include
convenient hooks for the jQuery selectors your client will need. There ends up
being no clear separation between the server's responsibilities and the
client's. In this situation it's much better to just let the client own the UI
entirely.

------
wpietri
This article could be right; I don't know the domain enough to say. And it did
clarify for me why some people find Angular so contentious: different tribes.
But at a number of points where I was expecting explanation, I got bare
assertions.

For example, "These languages have their place in the web development stack —
but on the server, not in the browser." Why's that? Personally, I'm looking
forward to seeing languages that pay little attention to the divide, so that
you can easily move code from one execution context to another as needed.

Or the already noted bit about client-side vs server-side rendering.

Or "Google aims to conquer the enterprise market, and Angular is one of its
tools." Do they? I live in San Francisco and know a bunch of people who work
at Google, and I have never heard the notion that they are aiming to own a lot
of enterprise-developer mindshare. I'm certainly having trouble seeing how
increased Angular usage leads to some billion-dollar revenue stream.

Or this, criticizing Angular's origin as a prototyping too: "I don’t think
that a rapid-prototyping framework should be used for complex, enterprise-
level production code." This from a guy whose favorite language was created
for some light mouseover animation and form validation? You could say that
Rails fits his description precisely, and it seems to be doing ok in the
enterprise.

So I wish this had had more meat. As it is, it seems more like a dressed-up
version of "Angular does not match my tastes," than the serious examination it
wants to be.

Also, fussy language note: please nobody ever say "pulled straight from the
horse's mouth". If you're going to use a metaphor, use it fully and well.
Pulling something from a horse's mouth is going to be a disgusting and
possibly dangerous operation. One _hears_ something straight from the horse's
mouth.

------
tschellenbach
Written by one of the most experienced JS developers. I wonder how he feels
about EmberJS.

~~~
tuananh
who is he ?

~~~
wil421
The author of the article we are commenting on.

------
coldcode
All I know of Angular is the pain our JS devs have using it. If Angular 1.x
was so great why is Google tossing it out and building essentially a new
framework in Angular 2.0? That would seem an indication that it isn't very
good.

~~~
watty
Because the web is changing at light speed and the frame work they designed
years ago requires more than a bandaid to adapt. It doesn't mean it's not
"good", it's just not great. The dev world is very opinionated, if you pick
the most popular framework in for any language or environment you'll find a
heavy amount of "haters" and rightfully so.;

Angular is the leader, they're rewriting to address some of the haters, and
are getting more hate for it.

------
izolate
The author hit the nail on the head for me: "The biggest problem for many
front-enders seems to be that Angular forces you to work in one specific way."

I'm opposed to opinionated frameworks. which is why I don't use Rails. And why
with Python I use pyramid/flask instead of django.

And with JS/node, I've found the commonJS+modules approach a far better means
to structure my code than any monolithic framework.

~~~
wpietri
Opinionated frameworks have their benefits. If you're working in their chosen
domain, they're often pretty cheap to use. And for some teams, it's especially
handy to have plenty of opinions baked in to minimize arguments over every
goddamn thing.

When he wrote, "Many front-enders, on the other hand, who have worked with
JavaScript and browsers for years and have developed their own coding style,
tend to have their doubts about Angular," my thought was, "Oh god, imagine a
team of 10 of those people."

I too have developed many style preferences over the years, but long ago I
learned they don't matter nearly as much for project success as having a
common style.

~~~
SchizoDuckie
Exactly yhis is the point PPK is missing imo. A generic structure is offered
by Angular, versus the mismatch of libraries, plugins, templating engines (all
with their own bugs) that we had before.

I've built a lot of HTML5 over the years, and handing over projects that
include your personal preferences and nifty things (even if it's 'Object
Oriented' Mootools) can make another developer that has no prior knowledge of
it decide to throw everything away and start from scratch.

At least angular provides a standardized and documented way of doing
everything.

------
zirkonit
Well-written.

Monolithic and opinionated, in software libraries and frameworks, will always
contrast with lite an modular. Some monoliths end up long-lasting (Rails?),
some perish – as always, fitting the needs of your target audience is key.
“Backend engineers”, for a JS framework, is as good a target audience as any.

------
andreyf
_Adopting Angular 2.0 would require them to allocate massive amounts of budget
to rewriting code that already works._

I really wish the team would rename "Angular 2.0" to "Angular for ES6". This
would make the rebuttal to this point painfully obvious - one day most ES5
code will need to be rewritten / re-architected for ES6 anyway. The cost of
rewriting everything is not just for upgrading a framework from 1.0 to 2.0,
but to use a (then) modern language.

------
tinco
Now I'm definitely more embedded in the backenders community than the
frontenders, but from my perspective Angular.js has been a lot more popular
than the author suggests. Of course my only metric for this is hearing other
people talk about it.

When we started selecting technologies for a new frontend for our web
application about a year and a half ago, I did a quick evaluation of the big
frameworks. Looking at the TODO list implementations and implementing a small
side project in Angular and a few others.

My conclusion was that the way angular works and how you use it was pretty
horrible, and I was quite surprised to see so many so impressed and positive
about it. I didn't even think about its performance (as it was promised it was
going to improve as it stabilised). The whole idea of the dependency
injections and factories, it just doesn't make sense. Within the company my
colleagues agreed with my conclusions so we decided to pick something else.

My probably not so popular opinion on dependency injection in dynamic
languages is that you shouldn't bother with it. Javascript (and Ruby for that
matter) allows you to overwrite both properties and prototypes, this means
that any dependency injection can be done dynamically at runtime whenever you
want as long as your logic and data is nicely captured in properties. (Note
that his last clause is something that often does not hold in Javascript
projects as most/many authors love wrapping their stuff in functions with very
harshly make lots of things private and immutable)

So designing a whole framework around enforcing this pattern, with a terrible
syntax and un-fathomable semantics, on top of a dynamic language, it doesn't
sit well with me.

~~~
marknutter
Angular's dependency injection is very similar to AMD modules. In fact, the
syntax is barely distinguishable. So if you have an issue with Angular's
dependency injection, you likely have issues with AMD and perhaps javascript
modules in general. I much prefer having my dependencies injected in a modular
way than having to pollute the global namespace with every library and
component I pull in.

~~~
tinco
Well this is exactly the point that people disagree on with me. I think your
application owns the global namespace, as long as your dependencies are neatly
defined somewhere there really is no downside to letting pulled in libraries
'pollute' your global namespace.

~~~
marknutter
When you're working on large teams it's no longer your global namespace alone.
I've worked on quite a few projects that abused the global namespace and it's
very painful to try and recover from.

------
ben336
I can't really verify the authors thesis that most people using Angular are
backend developers, but it does seem to have become the first thing everybody
tries to learn after JS/jQuery. I've been interviewing a lot of entry level
candidates lately, and "I've also started playing with Angular" has
practically been a theme song.

~~~
porker
Of the people dozen I know who were early adopters of Angular or do AngularJS
now, only one wasn't a serious back-end developer.

I think the split may be better worded as programmer/scripter. Some of my
unscientific sample were using other Javascript frameworks (Backbone mostly)
but were definitely programmers, and wrote in assorted languages too.

------
debacle
The problem with Angular is that it's 2005 technology masquerading as the new
hotness. Angular existed in 2005 in almost the same state. Why? For people who
wrote Java or PHP that didn't want to learn this "new" language, JavaScript.
In fact, we had a half-dozen implementations between ASP, whatever the name of
Google's solution was at the time, and the Myriad of "MooTools Helpers" and
"Prototype Helpers" in PHP.

The reality is that Angular, as a framework, takes you 90% of the way there,
just like any other framework, but it makes the last 10% almost impossible to
do "right." This is in contrast to JS-based frameworks which don't conflate
your entire application to add some questionable ease of use. ReactJS,
Knockout, etc, are all superior in that they allow you to do some Angular
things without getting in your way when you need to do non-Angular things.

~~~
gee_totes
I just had a panic attack and a series of stressful flashbacks reading the
phrase "MooTools Helpers". Can we get a trigger warning on here? /s

------
bitplanets
"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 is the problem? I make isomorphic apps and I really like this. DRY

------
IgorPartola
HTML templating belongs on the server-end? Well, that's... debatable.

I like Angular. It is backed by Google so it's less likely to be abandoned
because of boredom. It ibolides the batteries; I don't have to learn about
dozens of independent libraries just to get something simple together. It is
fast enough. Lastly, Ionic is pretty neat.

That is not to say it doesn't have it's bad parts. I don't care for some of
the boilerplate it has and how badly it fails if you screw any of it up. I am
not a fan of the built in $http service. The state service and URL routing are
also too confusing and often do not work correctly when doing slightly more
advanced things (intercepting transitions, rewriting history). But overall, I
like it better than, say, Backbone.

~~~
beobab
I'm not familiar with the word "ibolides", and a google search didn't turn up
anything I could fit as something you could do to batteries. Could I convince
you to explain what it means?

~~~
dnissley
I'm guessing they meant "includes".

~~~
IgorPartola
Yes, indeed. Typing on a mobile device is a pain, sorry.

------
ebbv
This article is really bad. Having learned Angular and written an app in it, I
liked Angular 1.x OK. I think between Angular 1.x and Ember it was mostly a
six of one, half dozen of the other question. I went with Angular for my app
because I thought "It's backed by Google, they'll grow it responsibly and
smartly." Well, color me stupid. I feel pretty burned by Angular 2.0, now not
only does the app I wrote need to be 100% rewritten, but everything I spent
time learning about Angular 1.x is now wasted effort.

That is the problem with Angular. Angular 2.0. Nothing else this article talks
about is really a valid criticism at all. See other comments about that.

------
at-fates-hands
Just a few points for me about Angular in my own experience. When I first
started using it, it seemed rather straight forward and easy to use. I could
use it in some of my projects, or build entire apps with it.

Then came the notice of the rewrite. At that point, I pretty much lost
interest in it. I mean, if you're going to have a major rewrite and and not
make any of it backwards compatible, what's to say you won't do it again in
another few years? For me, this was a deal breaker. Why build apps now which
be obsolete when 2.0 finally rolls around?

Also, I'm not sure why people think apps have some incredibly long life span.
Almost every large enterprise app I've ever worked on only goes about a year,
maybe two years before it gets a complete overhaul. Here's a good example:

Large Enterprise Healthcare App:

\- First iteration which was the longest and went from 2005-2010. Built on
Java and Tables in HTML. Brutal, but effective and easy for the Java guys to
maintain.

\- Second iteration was from 2010 - 2012. Built on Java and with mainly
Javascript and the HTML is cleaned up and tables removed.

\- Third iteration was from 2012-2013, Built on Spring MVC, HTML5 and CSS3
with lots of jQuery and Javascript for several interactive charts.

\- Last iteration I was a part of was in late 2013 - October of 2014.
Completely rebuilt with responsive design, built on Grails, with lots of CSS3,
jQuery and some Ember and Backbone pieces.

Even when I left they were contemplating another total overhaul, possibly
moving back to Spring, and doing more client side stuff with Angular or
Backbone and possibly doing some NodeJs as well. The app basically went from 5
year re-design schedule, to essentially less than 14 months in between
overhauls. I'm just chalking this up to a constant parade of contractors who
come in and are using the latest and greatest stuff, and then push that for
the app. When they leave, nobody has the ability to maintain it, so they just
rinse and repeat with contractors and technology.

Either way, my point here is that apps seem to have shorter and shorter
lifespans before being completely overhauled. It's like maintenance isn't even
really a requirement anymore.

~~~
iovar
Can you clarify what you mean here?

The way I see these two sentences are contradicting each other:

> Why build apps now which be obsolete when 2.0 finally rolls around?

> It's like maintenance isn't even really a requirement anymore.

Also, your example application seems to have issues with management, rather
than maintenance.

~~~
at-fates-hands
They don't contradict each other.

> Why build apps now which be obsolete when 2.0 finally rolls around?

It's well known Agular 2.0 won't be backwards compatible with 1.X projects:

[http://chariotsolutions.com/blog/post/angularjs-2-0-bold-
new...](http://chariotsolutions.com/blog/post/angularjs-2-0-bold-new-step-
typed-js-es-6-without-concerns/)

"Although Angular will run on ES 5 browsers (the current world), changes being
made to the core Angular architecture will break every Angular application.
See this InfoQ article for details, which include removal of controllers,
current directive definition syntax, $scope, and more."

and from the Angular Team after the Euro conference:

"Our goal with Angular 2 is to make the best possible set of tools for
building web apps not constrained by maintaining backwards compatibility with
existing APIs."

Which is totally different than having to maintain an application over an
extended period of time. They're two totally different issues.

------
benaston
The problem with AngularJS can be summarised thus:

"Its marketing and documentation does not correct those who believe it is
suitable for web-applications more complex than simple CRUD apps."

As soon as you have an application where you have to reason about the events
ocurring in your page, with AngularJS you're lost. Note that CRUD apps are a
sizeable proportion if not the majority of applications, so it's brilliant for
a massive number of applications.

But for anything more complicated, you're on a knife-edge of performance-
problems and ballooning accidental complexity.

------
buckbova
> Angular is aimed at large enterprise IT back-enders and managers who are
> confused by JavaScript’s insane proliferation of tools.

I pushed Angular for our team because it was so confining. Keep the code
modularized and stick to best practices. Honestly, it's been a joy to work
with. Instead of hodgepodge jquery soup, we have structured code that anyone
can dive into and follow a common style.

It feels like the old guard keeps pushing back on SPA's. It is a so much more
dynamic experience for the user than your typical oldschool postback driven
site.

------
billions
Angular was written by Google for Google products. It had a big corp audience
in mind from the start. It provides developer structure at the cost of
agility. This makes sense in large teams where contributors come and go and
have varied skill sets. Encapsulation and isolation of scope makes limits the
damage one component can do. To achieve this rigidity a lot of background
enforcement is required. The result is performance decline and lots of
development overhead.

~~~
robin_reala
Out of interest, which Google products are using it?

~~~
sehr
The biggest one I know of is their search trends page, which isn't really
saying much.

------
sakri
It's not just Java and Backend guys, I worked with Flash and Flex for 10
years, for me Angular makes perfect sense. I know I'm not alone either. Before
these great "framework wars" of Javascript, there were framework wars in the
Flex world, with frameworks of varying credibility and endless haters /
fanboys publicly pronouncing their butt hurt about their whims. Google any
"[enter framework] sucks" and get your opinions validated.

------
Crenshinibon
I admit I haven't read all the comments. But what I have read from the author,
in some comments here and in the follow up article, I get the impression that
there get things mixed up, that actually don't belong together. In my opinion
you have to distinguish between web apps and content pages.

In the first, client side templating is just fine and the right way.
Everything changes and the users are making a great deal of changing the
output. A round-trip here is destroying the feeling of an app.

In the second, client side templating is just unnecessary. But so is server
side templating, in many cases. Taken that the pages to display are rarely
changed it would be even better to have simple static html, pre compiled.

The hard task comes when we have some mixed scenarios. A CMS for example. In
my opinion the content creation process is a very valid use case for client-
side-rendering - an app for creating html output, if you will. But when it
comes to display that content it should reside precompiled (no server side
rendering) on the server. So that just plain html pages have to be delivered
to the actual users.

------
teknologist
This article is mostly BS. He's got the knack of sounding like he knows what
he's talking about when he actually doesn't. Some examples:

 _" Angular’s ng-repeat directive will create or destroy DOM elements
accordingly. This turned out to be quite expensive. ...

... what worries me is that this non-performant mode is Angular's default.
Front-end framework defaults should use established front-end best practices.
Angular’s don’t."_

He's talking about ngRepeat's "track by" function here and clearly doesn't
understand that it _can 't_ be switched on by default as the user must specify
the name of a unique id used in their data models. There is no way for this to
be on by default.

 _" 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."_

What does that even mean. Consumer hardware contains heaps of resource for web
browsing.

 _" Many front-enders, on the other hand, who have worked with JavaScript and
browsers for years and have developed their own coding style"_

Cute front-enders with their own adorable coding styles. Code is code.
Patterns structure code to increase maintainability. Stop imagining there's a
group of people whose work this does not apply to.

 _" That’s why most Angular developers come from the back-end, particularly
from Java. As far as I know this situation where a front-end framework is
supported mostly by non-front-enders is unique."_

More of this front-end/back-end discrimination bullshit. That's a distinctly
enterprise paradigm that just has to go. It's 2015

------
acaloiar
" _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._ "

If I follow the logic correctly--people with Java backgrounds are not trained
to recognize performance problems? Quite the curious line of reasoning.

~~~
wriq
_"...Angular’s performance problems."_

It's specific to Angular running in the browser opposed to Java running on a
server. You'll certainly run into different performance bottlenecks especially
in long running client side applications. What works on the JVM will be very
different than what works on the browser especially across multiple vendor's
JS runtimes and versions.

------
drderidder
Angular emanated some 'project smells' that have kept me at arms length. The
size of the codebase was very large compared to alternatives. Lots of add-on
solutions for various problems (ng-this, ng-that) kept cropping up. Articles
explaining how to do X or Y in Angular indicated things were probably not as
simple as they ought to be. And, it was mainly driven by Google as opposed to
a small core team of diverse individuals. The tools that have turned out to be
the best in my experience have often had one visionary lead developer, a BDFL-
type champion. I expect Angular to appeal more to enterprises, while the early
adopters and lean startups shift towards small libraries and microframeworks.
I think web components will become more and more important, and that we'll
begin to see more libraries to assist specifically with data persistence and
synchronization between the client and server.

------
bceagle
This is really just a compilation of previous rants against Angular. If you
want to get a more balanced view, you can read my article dealing with a lot
of this: [https://medium.com/@jeffwhelpley/screw-you-
angular-62b3889fd...](https://medium.com/@jeffwhelpley/screw-you-
angular-62b3889fd678)

------
FesterCluck
The author's logic follows, the only problem is he's picked the wrong term.
His argument is against using javascript and/or data-/ng- attributes to bind
default data to a template. Wasted power and cpu cycles. I think we can all
agree that premise is true. However, templating with binding is all about
savings in bandwidth, memory, and http requests. It also keeps complexity down
when done right.

So yes, quit using various unnecessary means of supplying binding references
to the DOM and serve & send your HTTP correctly. But none of youo ever will.

------
hmottestad
Why should I offload templating to the users?

Because it saves me lots of money since I don't need so many backend servers.

We are already offloading lots of stuff to the client already. CSS is a great
example of this. We could have a server calculate the colour of some text, or
just tell the browser which rules should be used to calculate that colour.

EDIT: For almost two years I've used Angular on most of our web systems at
work, and also on most of my private ones where i make the client
exceptionally thick and the server is just for persistence.

------
msane
Most of this seems a bit personal and a bit of a surprise from PPK.

The first few paragraphs are trying to convince you that Angular isn't popular
and isn't meant for cool people. You don't need to consult Google Trends to
sense that there is an ego on the wrong end of a popularity contest at play,
but here it is:

[https://www.google.com/trends/explore?hl=en-
US#q=ember.js,+a...](https://www.google.com/trends/explore?hl=en-
US#q=ember.js,+angularjs,+backbone.js&cmpt=q)

------
ziles88
Poorly written article mostly. Largely just fluff and opinion, and rehashing
of problems other people have mentioned. I swear everytime I read one, I
expect a unique take, but they always end up the same. Two or three paragraphs
hinting that it might not be performant, and another 3 or 4 paragraphs talking
about how Google doesn't even use it and how Angular is somehow hard to learn.
Only thing that surprised me is he didn't tell us about how great React is at
the end of the blog.

------
ChicagoDave
"Although templating is the correct solution, doing it in the browser is
fundamentally wrong."

This statement alone sounds like someone doesn't want to learn new things.

I'm sorry, but I wrote ASP.NET webforms for years and you will pry Angular
templates out of my cold dead hands. Of course if you have optimizations for
narrow scenarios, then by all means refactor...but most activity in a SPA is
pretty simple stuff. A template and a couple of REST calls and you're set.

------
JustSomeNobody
I think some of these front end frameworks come from developers looking the
bloated mess that is Enterprise Development and they think, "Man! I gotta get
me some of that!"

/S

------
FallDead
I don't think the author has heard of JSON,restful end points, and or design
patterns, I don't understand why he would develop with the intent of rendering
the pages on the server side, when the client can do that faster and you can
reduce server load. Not only is that a performance advantage its a design
advantage, now you can have mobile clients that render data natively and you
don't have to work as hard to develop for mobile.

------
jscheel
This is what I have been saying since 2012. Angular was created by java
developers for java developers. It's is an abomination to the frontend.

------
iSnow
>The biggest problem for many front-enders seems to be that Angular forces you
to work in one specific way.

I am not sure this is a weakness. While everyone protests change and all
developer's heads explode when you force them to use a specific convention, in
the real world a common standard of coders in one company is a good thing.

------
hodwik
This guy would have been better off just saying "Angular 2.0 breaks Angular.
The End."

They took out {{ }}, $scope, DDO, controllers, jqlite, angular.module, and are
moving to ES6 when basically no browsers have even started supporting it.

Isn't that enough? Do we really need to complain about Java developers writing
for the web?

------
monokrome
It is more than obvious that the author of this article __really __doesn 't
understand Angular. Also, you can't say that poorly educated developers is a
"problem with Angular", and this is essentially the author's primary argument
here.

Honestly, how did this make it to the top of HN?

------
programminggeek
In my experience, most of what people want can and should be done server side.
Instead of big frameworks, something smaller like Knockout can be useful for
adding some interactive javascript in a way that is cleaner than the standard
pile of jquery.

------
myliverhatesme
How did such a horribly written article with no substance or structure got so
popular? This guy just explains how he "thinks" and "feels" with no supporting
evidence.

One of his first points is: "I feel that Angular’s fundamental proposition
blurs the line between front end and back end."

Why? I feel it makes the line clearer. So there.

After I read the entire article I was still left wondering what his point was.
He concludes with discussing Angular 2.0

"The 2.0 rewrite is aimed at front-end developers, but may not reach them, and
in addition will turn off Angular’s current following. I don’t think Angular
will survive the rewrite."

Well, no shit. Let me get this straight: a front end framework isn't going to
survive because it's targeted at front end developers? Who writes this crap?

------
arcosdev
I agree, specifically with the fact the Angular 2.0 will turn off all the
corporate/Java devs and thereby kill itself.

------
asdrty
I don't like that Angular makes HTML pages very much useless by themselves
(content-wise without javascript)

------
breakingcups
If the author happens to chime in, that big Dutch corporation wouldn't happen
to be ING, would it?

------
mark_sz
I think bigger problem is with developers who are using Angular wrong way.

Before same story was with jQuery etc.

------
brainflake
Really disappointed with the quality of this article. PPK was such a valuable
resource back in the day when it came to front end development and always had
great content (especially when it came to compatibility issues). I'm not even
saying I disagree with him here, but this writeup seems pretty half-assed, at
least for someone of his caliber.

------
nolk100
I don't agree with this claim whatsoever - "Angular is aimed at corporate IT
departments rather than front-enders"

I'd say it's the other way around, if you read "front-enders" as hobbyists,
start ups and SME's. Angular is still far too new and unproven for most big
corporate IT departments.

~~~
test1235
The tide might be about to change - I'm currently doing Angular work for a
major car manufacturer.

~~~
pistle
The Angular juggernaut is like the Java juggernaut at light speed for
corporate IT. I'm interested to see how the Angular 2.0 risk assessment is
constructed within corporate IT today. Start on a 1.2 project with,
potentially, a full rewrite needed within 2-4 years? That's not typically a
risk slowly evolving LoB applications take on. Good luck finding Angular devs
in 5 years willing to live on the 1.2 brownfield. Until the schism around 2.0
gets resolved, I'm not sure I see this playing out well for them.

------
damm
Angular is the new PHP didn't you know?

------
hippich
Cross-posted to ihateangular.com

------
naeemShaikh27
Just A Crap

------
DevFactor
My issue with AngularJS: Debugging is an absolute nightmare, error messages
are far and in-between. And when working on a 50k+ line production code-base,
one single comma a in a file where it is not supposed to be will shut down the
whole GUI. And occasionally, it won't even show where in the console.

~~~
Bahamut
In dev it will show exactly where in the console, assuming you have a sane dev
environment, and if you're running a tool like jshint, you can catch any such
error fast. That is a non-issue, and not even one unique to Angular.

------
gaius
IBM invented rendering on the client in the 3270 terminal... In 1971.

~~~
shawndumas
I got my start as a professional programmer at an IBM shop on an System 38 -->
AS/400 writing RPG apps with 5250 terminals. When HTTP/HTML started taking off
in 1993 because of Mosaic I felt right at home.

RPG ran on the AS/400 and your DSPF (display file) ran on the terminal. DSPFs
did screen layout, validation, etc...

------
jorisw
The final paragraph I really don't get:

> Despite its serious technical problems Angular 1.x is a success especially
> among corporate developers with a Java background. The 2.0 rewrite is aimed
> at front-end developers [...]

... says who? I don't know any Java developer who does Angular now, and who
ever said front-end devs are the target audience of the rewrite?

------
doczoidberg
Angular 2.0 addresses frontend and not corporate developers? Ridiculous!
AtScript is more like Java/C# and supports strongly typing.

------
skrowl
People here at HN really love to hate on Angular for some reason. This article
doesn't even make any sense, but it's still getting voted up.

~~~
pluma
There are generally two kinds of people who love to hate on Angular:

1) those who have used Angular, been burned by it and are now sour about it;

2) those who haven't used Angular but hate {JavaScript|frameworks|SPAs|the
web|anything popular} out of principle.

The first category includes both those who hate it because they don't
understand it and those who hate it precisely because they do understand it.

I wouldn't say I hate Angular, but I'd like to think of myself as being in the
latter subset of the first category.

------
wooptoo
> I feel that Angular’s fundamental proposition blurs the line between front
> end and back end.

Sorry?

> Angular is aimed at large enterprise IT back-enders and managers who are
> confused by JavaScript’s insane proliferation of tools.

Wait, seriously?

> When AngularJS was first created, almost five years ago, it was not
> originally intended for developers.

When I started using Angular 3 years ago (ver 0.9) it was already mature
enough for serious web development and better (better structured, better
documented, better for large web apps) than a lot of other frameworks (like
Backbone). Back then it was developed by three Czech guys, that Google
employed in the meantime and funded their project.

> Enterprise IT managers also like the fact that Angular closely mirrors the
> preferences of their back-end developers.

This just pisses me off already.

> Many front-enders, on the other hand, who have worked with JavaScript and
> browsers for years and have developed their own coding style, tend to have
> their doubts about Angular.

Yes, because their old code used to be utterly crap compared to something
written in Angular. Angular does not let you write such messy code as you
could without a framework.

This article is all FUD. I have never imagined that I'll ever see such a bad
piece written about Angular.

~~~
rimantas
Tell us more how it is better structured and better documented than Backbone
and what exactly makes it better for the large apps. The size of the app will
hide the size of the framework better?

