
2 years with Angular - robin_reala
http://www.fse.guru/2-years-with-angular
======
jhpriestley
I find the rise of Angular kind of baffling.

Angular's scope system is exactly analogous to the scope system of a
programming language. This is a solved problem! When you make a scope system,
make it lexical, and require explicit declaration before use. If you're not
making those choices, then at least acknowledge that these are the standard
answers, with very clear advantages over other scoping systems, and explain
why you are not using these answers. But with angular, we have a dynamic,
implicit declaration scoping system. New scopes are introduced somewhat
unpredictably, at the discretion of each directive. I thought that introducing
dynamic, implicit-declaration, non-block-scoped variables in 2014 was like
introducing a new car with a coal-burning engine, but no one even seems to
remark on it.

Then there's the dirty-checking loop. After every event there is a digest;
every digest runs every watch. To me, just reading this description makes a
voice speak up in my head: "Uh-oh! That sounds like O(n^2)!" Now that angular
is being widely used, people are noticing that it's slow as shit. But why did
the framework get to this level without anyone remarking, "this dirty-checking
algorithm is fundamentally, irremediably not scalable"? Do people not have a
sense even for the most coarse performance characteristics of algorithms like
this? Or do people simply think that nowadays "performance does not matter"?

Angular's "module" system is the strangest of all. It doesn't do namespacing
or dependency tracking. What is even the point of it? What thought process led
to this useless module system?

It's just strange. Hundreds of years of people's work are spent on something,
which the most cursory, CS 101 analysis shows to be seriously flawed. Is
analysis simply a lost art in this industry?

Oh well, people are finally realizing Angular has its faults, because they've
seen them with their own eyes and now they believe them. It would be nice if
we could learn from this, and maybe skip the next boondoggle (web components
for instance), but I have no hope for it.

~~~
cportela
I knew someone who consulted a large bank not to use Angular for financial
apps. They were insistent to use Angular until he finally showed them a fairly
typical requirement of an app like that in angular: 5 tables with 100 rows and
columns. It literally crawled when running on a Dell Workstation laptop.

It is kind of nuts that angular is big.

~~~
trose
My team is using Angular for an app that contains large tabular data all over
the place. We ended up having to rewrite the table generation in jQuery and
now we've got a POC in development using React. Most other places we've had to
use shims like angular-once to make menus performant. At this point we're
building work-arounds for most of the things that makes Angular special.

~~~
zivc
> has perf issues with angularjs

> writes a solution using jQuery

Angular tries to be clever and solve loads of problems, sure tables and table
rendering sucks anyways, but a simple querySelector with jQuery is 98% slower
than just using normal DOM methods.

If you're gonna write your own bits of code to improve the caveats of any
framework, especially in the financial industry, you go full hog and you write
it properly.

Fixing an angular problem with a jQuery solution will get you marginal gains.
Fixing an angular problem with a DOM solution will get you the best results
and it isn't even that hard.

~~~
untog
_a simple querySelector with jQuery is 98% slower than just using normal DOM
methods._

A simple querySelector with jQuery maps directly to a normal DOM method in
browsers that support it.

~~~
deckiedan
apart from the overhead of finding out if the normal DOM method will work -
and the overhead of parsing the selector to make sure it's not using jQuery
extensions.

------
swombat
This seems to be the summary of every tech flame war ever, and applies rather
well here:

A: I've used tech X in a lot of Y contexts, and I find it's not great. I will
generalise slightly imply that tech X is not the panacea that it has been
presented as.

B: Yeah? Well, I've used tech X in a lot of Z contexts, and I find it works
fine! You're wrong! You're using it wrong! Maybe you're not wrong in context
Y, but for most other contexts X is still the best tech!

C: I haven't used tech X at all, but here's my opinion on it anyway.

~~~
c0brac0bra
Amen. Look back 10 years ago and we were having the exact same discussions
about mod_perl, php, and java servlets. Nothing has really changed except
perhaps for an increase in the number of regurgitated comparisons.

~~~
nutate
Except that php won. As weird as that seems. CGI.pm was removed from the core
Perl distro this year. React learned a lot from php/xhp and is easier to use
because of it.

------
wldlyinaccurate
I've worked on Angular projects of varying sizes -some as large as 30KLOC
(products where every page has enough interaction to justify an Angular
controller)- and I can never find myself agreeing with these articles.

Have I just drunk too much kool-aid? Or is it possible that with the right
team, the right architecture, Angular can actually be a really great framework
to use? The common theme for every large Angular project I've worked on is
that the teams have leaned towards a more functional design where state is
rarely used. This has always seemed to encourage smaller, decoupled modules
which don't suffer from many of the problems that the author mentions.

But hey, it's probably the kool-aid.

~~~
gadr90
YES! Thank you! I think I'll die if I have to read another developer
arrogantly defining what should and should not be, and how he, in all his
glory, hereafter defines this framework to "NOT BE WORTHY".

I can't stand how some articles simply s&*t on years of software architecture
principles and the work of very talented engineers and simply dismisses them
like it's nothing.

If you disagree with a framework's perspective, AT LEAST be respectful.

BTW, I also have used Angular for 2 years and, given the pros and cons and
existing alternatives, I will choose it again for my next big project. The
structure is simply too solid. This is invaluable when you have a large team
that must work together.

~~~
jasim
I am always conflicted about writing about Angular on a negative light because
the team has put some great work into it while raising the bar in how rich
apps could be built on the web. Being a back-end developer for a long time, it
let me build some great interfaces on the front-end really quickly, and I'm
very thankful for that.

But we should also learn from where Angular succeeded and where it failed.
Making XML declarative is fraught with difficulties. Things like ng-repeat are
but a thin declarative veneer over the fundamentally imperative nature of
constructing views. The biggest difference between most existing templating
frameworks and React is in this world view: is the view constructed
imperatively, or is it declared?

The other question of contention is how much implicit magic should the
framework supply vs how much explicitness the user should bring into the code.
Angular's design decision is to make bindings work magically, while React
identifies explicitness as a virtue.

Having used both, I'm liking the imperative+explict camp.

~~~
gadr90
Finally, a respectful and well founded analysis. Thank you for improving the
quality of the debate.

My 2 cents: I actually prefer the declarative approach. My attempts at
imperative view generation resulted in far more shooting-on-the-foot.
Naturally, this is the very specific conclusions of me and my team, not the
entire human race. I always think you should try both!

Also, I'm a huge fan of Polymer, which is also very much declarative. Going to
use Angular instead of Polymer simply because of better project structure and
browser support.

------
pygy_
This post reminds me of these other two [0, 1] that ultimately lead Leo Horie
to create Mithril [2], a tiny (5 KB down the line) but complete MVC framework
that also eschews most of the criticism raised by the OP.

The Mithril blog is also worth a look, it addresses a lot of concrete
scenarios with recipies to solve common front end problems with the framework.
For example, here's a post on asymetrical data binding [3].

————

0\. [http://lhorie.blogspot.fr/2013/09/things-that-suck-in-
angula...](http://lhorie.blogspot.fr/2013/09/things-that-suck-in-
angularjs.html)

1\. [http://lhorie.blogspot.fr/2013/10/things-that-suck-in-
angula...](http://lhorie.blogspot.fr/2013/10/things-that-suck-in-angularjs-
follow-up.html)

2\. [http://lhorie.github.io/mithril/](http://lhorie.github.io/mithril/)

3\. [http://lhorie.github.io/mithril-blog/asymmetrical-data-
bindi...](http://lhorie.github.io/mithril-blog/asymmetrical-data-
bindings.html)

~~~
kaonashi
That framework has its own problems, like you have to wrap all your data
structures into the mithril collections/models so that they can communicate
with the views.

~~~
pygy_
_> you have to wrap all your data structures into the mithril
collections/models so that they can communicate with the views._

Only when you need bidirectional bindings, and you're not forced to use the
builtin `m.prop()` helpers, you can easily whip your own if they don't work
for your use case.

See my last link for an example.

~~~
kaonashi
Isn't that the whole point though? I mean, discarding existing DOM with forms
is a horrible experience.

------
Nitramp
I work at Google, and have been using AngularJS in different projects for
about three years. The OP raises a couple of good points (in particular his
"The Bad Parts" are mostly valid), but I cannot understand some others, nor do
I share his take away.

AngularJS is not a silver bullet or panacea. It has bad parts such as the
directives API (making it hard to create reusable components), the global
namespacing in the injector, and indeed, the number of watch expressions is an
issue.

That being said, internally at Google:

\- we do have well working, shared, reusable UI components based on
directives. So it's quite possible to write usable AngularJS modules.

\- There are multiple old (>3 years), large AngularJS apps that do not seem to
have major maintenance issues. Maintenance of large code bases (>100k SLOC JS)
is always an issue, but if you follow the style guide [0] at least it doesn't
seem worse than with other JS frameworks

\- Code is minified and compiled, using Closure Compiler's @ngInject and
@export annotations as required.

OP's comments mostly sound like they were burned by not following software
development best practices (e.g. throw the prototype away, make sure to
properly design your domain model, have a qualified tech lead, have qualified
engineers).

His "Lessons for framework (and metaframework) developers" seem generally
useful, but unrelated to particular AngularJS shortcomings.

[0] [http://google-
styleguide.googlecode.com/svn/trunk/angularjs-...](http://google-
styleguide.googlecode.com/svn/trunk/angularjs-google-style.html)

~~~
btbuildem
This is in an established corp (best practices, standards, workflows etc) -
you could build things out of mud and they would still hold. Doesn't say much
for/against this particular framework..

------
lingoberry
I'm late to the party, but I want to share an insight I've had regarding game
development and UI applications. It baffled me for a long time why building
UIs were such a pain, and doubly so in a web app. Why could I, and others,
create such seemingly advanced graphics and interactions in a video game, but
try to make a UI and you're stuck with thousands of difficult to discover
bugs. After I started using react, I realised games are "easy" for the same
reason react is a huge productivity multiplier: you re-render the game every
single frame. You have the data that represents your game state, there's a
game loop, and you render every single little damn thing, every damn frame.
It's a one-way flow of information from your explicit state to the
presentation layer. React works the same way, only it re-renders only if the
state changed. That's it. Super simple, but it's a mind shift.

~~~
CmonDev
Also you can use a different exotic approach in every game - it's completely
open!

In the modern closed web you unfortunately have to deal with legacy tech like
HTML, JS, CSS which will never ever go away "because compatibility".

------
oinksoft
I've been using Angular on-and-off in professional settings since 2012.
Angular is a framework obsessed with testability that treats usability as an
afterthought. That said I've found Angular to be more than flexible enough to
meet the needs of your typical CRUD apps, and generally enjoy working with it.

One thing I agree with the author about is the importance of expertise for a
successful Angular project. Some specialized knowledge is needed to get a
decent fit and finish, and the results can be horrible without that.

Strongly discouraging globals goes a long way towards improving code written
by inexperienced engineers, but Angular's provider system is _still_ not
clearly documented with practical examples, which makes those engineers more
likely to shove everything into the unavoidable Angular constructs
(controllers, directives, $scope).

The middling quality and small availability of third-party Angular libraries
is a problem. I believe that greater awareness/better tooling for ngDoc would
be a tremendous help there. Best practices are not well-presented anywhere in
the Angular world, particularly for designing reusable Angular libraries.

The other big problem is the project source code which I find poorly organized
and documented. If you want to get into the guts of Angular for debugging
purposes, good luck!

~~~
jrochkind1
You say:

> That said I've found Angular to be more than flexible enough to meet the
> needs of your typical CRUD apps

The OP says:

> Are there any use cases where Angular shines?

> * Building form-based "CRUD apps".

So I guess you and the OP pretty much agree.

~~~
oinksoft
The author and I don't agree, except that Angular is not suitable for high-
performance frontends (like games). The author suggests that Angular is only
suitable for prototyping and that simply using the framework is technical
debt. I particularly disagree with this statement: "Accept the fact that you
will suffer in the future. The lowered expectations will help you stay happy
sometimes."

It seems like the author is simply unhappy to be working in a framework not of
his own design: "Create a metaframework based on angular, tailored
SPECIFICALLY for your project needs and your team experience!" That's the one
thing you _shouldn 't_ do if you want to reuse code between projects.

~~~
aikah
> The author and I don't agree, except that Angular is not suitable for high-
> performance frontends (like games).

Would you really use DOM/virtual DOM templates to make a game? it makes little
sense. I dont believe any "MV*" framework is suitable for games,even if the
game is DOM based.

In a game,what you want is to make sure that at time T,the screen reflects the
state of the game.Since you are manually pooling all states with a timer in
order to render the game on screen,there is no need for databinding.

~~~
kuni-toko-tachi
Actually that is the point :) The virtual DOM is equivalent to how you do
write games. Declarative to imperative. React took its cues from how games are
written. The renderer in react targets the DOM. React is a renderer.

------
aikah
I'm a big angularjs fan butI agree with all the points made by the OP.

I will however stick with angularjs because frankly there is no better
alternative.

the selling points for me are:

\- Testing:Karma,Protractor,dependency injection are fundamental when working
with a team.Everything is so easy to test,so easy to mock.

\- Speed:Sorry but there is no other framework that makes front-end dev
faster.I can come up with very complex apps within hours,fully tested.

\- Resources:20+ books,hundreds of blogs,1000+ directives on the web.

\- Easy to integrate with legacy jquery mess:since jQlite is compatible with
jQuery,I can just drop a jQuery plugin in a directive observe something with
no effort and have it rendered properly.

The main drawbacks:

\- Dont expect to understand angular without a serious understanding of
javascript.

\- Performances: yes there are performance issues,but when they show up,one
needs to work on these issues.

\- Probably too much hype.

~~~
ep103
I plan on looking into react and mithril in the coming months

------
hassanzaheer_
While most of the arguments presented in this article are somewhat valid but I
hope with the release of Angular 2.0 majority of the issues will be addressed
(though does it make sense to make such drastic changes in the upcoming is
another debate and already taken care of at:
[https://news.ycombinator.com/item?id=8507632](https://news.ycombinator.com/item?id=8507632))

I'm currently working on a comparatively large webapp built in Angular and it
was after about 7 months into the project that we started realising it's
pitfalls, and it was very difficult to abandon it then.

So we worked it around by: 1) using one-way binding (or bindonce to be exact)
to reduce watches 2) avoiding un-necessary $apply() and using $digest()
carefully if required 3) using ng-boilerplate for scaffolding 4) defining our
own style guides/coding conventions/design patterns to overcome Angular's bad
parts 5) frequent code-reviews that made sure new team members are upto speed
with the above techniques

luckily we haven't ran into much issues after that :)

~~~
cmdkeen
Angular 2.0 seems to be a long ways off - to the point where the presenters
wouldn't show actual code examples in their demos of it at ng-europe.

It rather makes me worry it is going to be the Python 3000 release all over
again in terms of how much is changing.

~~~
Alex3917
> It rather makes me worry it is going to be the Python 3000 release all over
> again in terms of how much is changing.

The underlying technology is changing so fast (ES6, web components, mobile
web, etc.) that it's going to make upgrading an obvious choice even if it
involves relearning a lot of stuff.

~~~
hassanzaheer_
couldn't agree more on the Python example, I think one of the main agendas for
the 2.0 release will be to make it more popular on mobile side of things
([https://www.airport-parking-shop.co.uk/blog/built-
app-2-week...](https://www.airport-parking-shop.co.uk/blog/built-app-2-weeks-
using-ionic-framework/) is one such example though not from the core AngularJS
team) for which they may have compromised backward compatibility infavour of
performance.

and also do you think they'll continue with the 1.x releases? since so many
developers have already invested time and effort on their webapps and shifting
it to an entirely new framework (read release) is a major cost to pay..

~~~
Alex3917
There is probably going to be at least a 1.4 release. The new 1.x dev team
that Google just created talks about their plans for the future here:

[https://www.youtube.com/watch?v=LG9VkCDbte0&feature=youtu.be](https://www.youtube.com/watch?v=LG9VkCDbte0&feature=youtu.be)

They say the exact plans for how long they are going to support 1.x won't be
finalized until after 2.0 gets released, so that they have some idea of how
difficult it's going to be to migrate.

------
lhorie
_disclaimer: I 'm the author of Mithril.js_

I've also used Angular for around 2 years for a large application. This
article resonates pretty accurately with the problems we were running into
before I decided to write Mithril.

It can certainly work well (heck, the mobile part of our app was doing just
fine because it was specifically designed to be a trimmed down version of the
much more powerful desktop app), but performance problems aren't necessarily
because people don't know how to use Angular. In our case, performance
problems usually became obvious when we had UIs for editing large volumes of
information, and large volumes of information did appear on the page. Two of
the examples that we were running into problems with were a work breakdown
structure UI, and a scheduling UI, which are far from being things-you-should-
not-be-doing.

The team scalability issue is real, but I think it's not entirely Angular's
fault per se. My general experience w/ co-workers dabbling w/ Angular was that
they were accustomed to jQuery in terms of discoverability (i.e. if you don't
know jQuery, you can fake it w/ Google-fu until make it). Getting into Angular
is not like that at all. There are lots of places where you can shoot your
foot if you don't do it the right way (tm), and deadlines _will_ trump doing
it the right way if the right way is sufficiently non-intuitive. You can blame
that on teams not having good processes or good developer or what have you,
but hey, that's the real world for ya.

My main problem with Angular is the error messages. Imagine writing this:

    
    
        $(".foo").each(function() {
          this.addClass("bar")
        })
    

But instead of throwing a familiar native js error on line 2, you get an
asynchronous ReferenceUnboxingException on line 3475 of jquery.js and your
code is nowhere in the stack trace. That's what a lot of Angular errors look
like (when they do show up, because null refs from templates don't).

~~~
1971genocide
Big Mithril.js fan here !

Mithril.js seems like something I would study in my maths class (its a good
thing). I have spent a good amount of my last year trying to get better at
angular and wasting a large amount of my time. Angular.js has seriously
colored my image about google's engineering poweress.Looking back I put my
intuition and education at the back seat - due to my own insecurity of my
intelligence - google must be better than me right ?

------
BinaryIdiot
Maybe I'm old fashioned but Angular just does too much for me. In fact many
frontend frameworks simply do too much for me. I like to structure my web
applications in a very minimal way.

I like having one layer that covers the UI display and UI events. This layer
does nothing beyond styling, setting up the UI and using messages to pass back
events in a generic way.

My business logic handles generic events. So say I have a button for saving,
in my UI layer it registers the click event but then sends a generic message
with a payload that is simply "Save". The business logic then saves it. This
let's me drastically change any of the UI with zero affect on my business
logic.

I wouldn't recommend it yet for production (very early) but I'm working on a
small library that does much of this messaging and binding of messages
directly to DOM objects.
[https://github.com/KrisSiegel/msngr.js](https://github.com/KrisSiegel/msngr.js)

~~~
osconfused
Question: I also like a minimally structured app. I've experimented with
Backbone.js. Have you tried it? Did you decide to go with msngr.js after using
Backbone?

I feel like I spend a lot of time trying frameworks, only to find very little
benefit. Happy to learn more, but would love to have some basis of comparison
to some tech I've worked with to date.

~~~
BinaryIdiot
Backbone looks interesting and I've worked on projects that used it but
honestly I've never really taken a hard look at it nor had to make huge
changes with it to really have a good opinion one way or another on it. I
mostly started writing and using msngr.js because I love messaging and I
didn't see anything that did exactly what I wanted to do (and even if I had
found something I still may have written it anyway as I've learned quite a bit
in doing so).

------
debacle
Angular is a result of the over-engineering that is endemic to web development
right now. Programmers are taking strategies designed by Google and Facebook
and places that actually need the high level of conventions prescribed by
software like Angular and applying it to their personal blog, their half-done
only on github "startup," etc.

JavaScript isn't really a good place to adopt convention - you're dealing in a
mixed-code environment almost from the start, speed is constantly an issue if
you're doing something complex, and there's no such thing as "one size fits
all."

I've looked at almost every JavaScript framework out there, and they really
don't offer much more than what you would get out of a very lightweight jQuery
(or your library of choice) abstraction. I want very much to find something
that is as useful as the programming friction it introduces, but I haven't
really found anything that meets that criteria yet. React seems to be very
good at face value, but in general it isn't saving you nearly the amount of
code that you might hope it does. Ember is probably the best at this, but it
has its own tradeoffs (namely speed).

------
shubhamjain
I can't speak of Angular since I haven't used it but one problem that is
recurring with use frameworks, in general, is that thinking or getting used to
"their" way takes a significant amount of time and seeing the continuous
change of technology, I am not sure that time is justifiable in the longer
run.

Take example of rails. I was trying to learn it sometime ago and was really
amazed how it has a process for nearly everything. Migrations, asset
pipelines, generators, and very extensive command line. Sure it does make it
seem like "Once I learn it, it will be so much easy to make the next app" but
it is easy to realize after sometime that you have to cross usual hurdles of
Googling everything, learning these processes, facing issues, digging out new
ways of debugging to finally be good at it.

My idea is that frameworks should be minimal which only ensure a basic working
architecture and everything else should be extensible (via packages).

~~~
mattgreenrocks
There's a term for minimal frameworks: libraries.

Ultimately, you should control the architecture of your application. When this
is the case, you can develop abstractions around libraries that shield the
rest of your code from their bugs, 'conventions', and error handling
strategies.

------
jasim
I recently wrote about my experience with Angular in a different forum.
Sharing it here:

I worked on Angular last year building an app with a few complex views. The
initial days were full of glory. Data-binding was new to me, which produced
much goodwill towards the framework.

Things started falling apart as I had to inevitably understand the framework
in a little more depth. They practically wrote a programming language in the
bid to create declarative templates which knows about the Javascript objects
they bind to. There is a hand-rolled expression parser
([https://github.com/angular/angular.js/blob/v1.2.x/src/ng/par...](https://github.com/angular/angular.js/blob/v1.2.x/src/ng/parse.js)),
new scoping rules to learn, and words like transclusion and isolate scope, and
stuff like $compile vs $link.

There is a small cottage industry of blogs explaining how Angular directives
work
([https://docs.angularjs.org/guide/directive](https://docs.angularjs.org/guide/directive)).
The unfortunate thing is that all of Angular is built on directives (ng-
repeat, ng-model etc.); so till one understands it in depth, we remain
ignorant consumers of the API with only a fuzzy idea of the magic beneath,
which there is a lot of.

The worst however was when we started running into performance problems trying
to render large tables. Angular runs a $digest cycle whenever anything
interesting happens (mouse move, window scroll, ..). $digest runs a dirty
check over all the data bound to $scope and updates views as necessary. Which
means after about 8k-10k bindings, everything starts to crawl to a halt.

There is a definite cap on the number of bindings that you can use with
Angular. The ways around it are to do one-time binding (the data won't be
updated if it changes after the initial render), infinite scrolling and simply
not rendering too much data. The problem is compounded by the fact that
bindings are everywhere - even string interpolation like `{{startDate}} -
{{endDate}}` produce two bindings.

Bindings are Angular's fundamental abstraction, and having to worry about its
use due to performance issues seems quite limiting.

Amidst all this, React feels like a breath of fresh air. I've written a post
about what makes it attractive to me here:
[http://www.jasimabasheer.com/posts/on-
react.html](http://www.jasimabasheer.com/posts/on-react.html).

Compared to Ember, neither Angular nor React dictate as rigorous an
organization of files and namespaces (routes, controllers, views), and have
little mandatory conventions to follow. But React is as much a framework as
Angular is. The event loop is controlled by the framework in the case of both,
and they dictate a certain way of writing templates and building view objects.
They can however be constrained to parts of the app, and so can play well with
both SPA and non-SPA apps. The data models are plain Javascript objects in
both (it is not in Ember), which is really nice.

Google recently released a new version of their developer console
([https://console.developers.google.com](https://console.developers.google.com))
which is built on Angular. So the company is definitely putting their weight
behind the framework. However, Angular 2 is not at all backwards compatible.
That was quite unexpected. If I had known this going in, I would have never
used it for the project. But it felt like such a good idea at the time...

~~~
aikah
> But React is as much a framework as Angular is.

Sure,the difference is React doesnt tell you how to organize your
application.AngularJS does,you have to use dependency injection.I like it,some
people dont.

AngularJS is in no way perfect.But compared to other
frameworks,Ember,Backbone,... In my opinion it's better.

I personally dont like React because of JSX,I dont want to have to learn a JS
superset,and i'll probably wont like AngularJS 2.X because of atscript
either,wether it's mandatory or not(understanding exemples on the web will
make it mandatory).

~~~
jasim
You can use React without JSX. It is especially easy if you are using
CoffeeScript which makes the syntax quite terse.

I personally like JSX. It is more of a variant of Javascript that lets us mix
HTML into JS seamlessly. It was inspired from XHP
([https://www.facebook.com/notes/facebook-engineering/xhp-a-
ne...](https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-
write-php/294003943919)), a PHP extension developed and used by Facebook that
lets PHP understand XML. I think that the cross-pollination of this idea into
React might be one of the best things to have happened to front-end
development in the recent past.

JSX is different from HTML in a few simple ways
([http://facebook.github.io/react/docs/jsx-in-
depth.html](http://facebook.github.io/react/docs/jsx-in-depth.html)):

\- All HTML attributes are written in lowerCamelCase, like so:
contentEditable, maxLength etc. React has a wonderful "is this what you
meant?"-style warning system for when we slip-up on these details. More on
HTML attributes in JSX is here: [http://facebook.github.io/react/docs/tags-
and-attributes.htm...](http://facebook.github.io/react/docs/tags-and-
attributes.html)

\- You can't use `class` to denote CSS class names. It is always `className`.
You are going to forget this as you copy-paste a FontAwesome icon definition
or Bootstrap snippet into the project and wonder what went wrong. But practice
makes perfect.

\- If you want to write inline styles, the style attribute should be written
as a Javascript hash (it is actually a blessing in disguise). React documents
it here: [http://facebook.github.io/react/tips/inline-
styles.html](http://facebook.github.io/react/tips/inline-styles.html).

I haven't found any other incidental quirks in JSX, and it integrates nicely
with Javascript in practice. It is however different from the way things have
always been done, which can be a good reason for resistance.

~~~
aikah
Sure,but you need to learn JSX to read code exemples around the web.So you
cant really use React without knowing JSX.

That's a subtle thing but important enough when you're working on big
projects.

~~~
dandelany
Sure, but if you can read HTML and you've read the above list of caveats:
congratulations, you can now read JSX. The attributes are simply passed to
children as props. There's really not much to it.

------
tomelders
I'm currently enjoying angular after having spent a year and a bit working
with it exclusively. I am keen to try out Flux and Mithril, but I've not had
the time nor the opportunity. But as it stands, we're deploying several large
projects into very demanding organisations that are stable, performant and
easy to manage. We as a team owe lot to Angular in terms of our productivity.
We're also a great team and that counts for a lot too.

The thing I would like to add to the debate is this: We've all learned that
Angular is hard. It's a complex beast with it's own nuances and
idiosyncrasies. It also offers plenty of ways to do things you probably
shouldn't do (i'm looking at you expressions). But more than that, with
Angular in the tool box, people push themselves to deliver products vastly
more complex than would be feasible without it. And these two issues collide
all the time. Learning a framework + the desire to deliver more; One should
follow the other, but people tend to attempt both at the same time.

I personally don't think there's anything "wrong" with Angular, but people
have to acknowledge that despite the marketing hyperbole, learning Angular
means setting out on a long and difficult journey that will require the
developer to rethink a lot of what they know about building web stuff. But
that's web development in a nutshell. It's a different gig every year, and
within an alarmingly short amount of time, Angular will probably be replaced
with something better suited to the tasks that try to accomplish the thing we
want to accomplish with mere HTML, CSS and Javascript.

There's also a lot to be said for how you organise your projects and what
tools you use (eg Require or Browserify etc etc), but that's a very different
kind of conversation.

------
city41
I'm really disappointed that not only is this article on Hacker News, but it's
currently at #1. The article contains almost no substance at all.

Angular's a controversial topic. So if you're going to write a long blog post
picking a side, you really need to back it up with examples and offer
alternatives. The six part "detail" posts aren't much better.

~~~
harel
I was hoping to read some examples and alternatives as well.. Presenting a
problem without examples to back it up or a solution is just ranting. That's
fine, but its just less productive.

------
xpto123
I confess I am an Angular fan.

But this article is not Angular specific at all, it stays on a very high-
level. Replace the word Angular with any other web framework and the article
would still make perfect sense.

Not that the article does not have some value, just that it has very little to
do with its title.

~~~
atmosx
NOTE: Haven't used AngularJS and only scraped the article. But Rails for
example, doesn't have a namespace problem, because ruby modules provide a
namespace and prevent name clashes easily.

That said, I'm not sure Rails and AngularJS are _direct competitors_ as many
apps use a combination of both frameworks or more generally Rails + JS-
framework.

~~~
pcthrowaway
Rails and Angular are apples and oranges. Angular isn't a full-stack
framework, it's a client-side framework that handles data source interfacing
and view updating.

------
akamaka
I totally disagree.

I've spent the last year working on a complex and widely-used site that is
built with Angular. It is maintainable, performant, has a smooth UX, and is
mobile-friendly.

I'm usually extremely cautious about relying on frameworks for long projects,
because easy setup doesn't matter after you've been working on something for a
year. In our case, using Angular was the best choice we could have made. I
would absolutely not replace Angular with my own in-house MVC, even if you
gave me a year to develop it.

-The testing tools are some of the best I've used, and hugely contribute to making the app easier to maintain

-It's not as much of a framework as a set of tools. Angular mostly stays out of the way and mostly allows us to structure code to match our needs

-You _absolutely_ need to have top-notch developers, and ideally someone experienced enough to mentor people on the team who are new to Angular. There are a lot of JS developers who are former Flash designers who learned how to use a few jQuery plugins. If they don't know the fundamentals of programming really well, they will make a huge mess of the project.

-We've definitely run into performance problems, but they're manageable. We've had to write code that bypasses Angular's digest cycle, but it feels similar to writing a bit of inline assembler in a C++ program. I wouldn't stop using C++ because of that.

------
maouida
I've been using Angular for a SaaS for 7 months, the project is launching in
about a month from now.

It is not just a CRUD app. It has:

~170 views ~70 custom directive ~100 controllers

Many directives can execute on the same page.

A single page can have multiple tabs, forms, modals, charts.

I hit some situations where performance dropped a lot but if you take the time
to benchmark and test you can fix it.

The key to keep it stable is to load the UI (directive) when you need it and
destroy it when you are done.

Personally, I've not found any serious issue so far.

------
esaym
I've actually never used any javascript framework. It is stuff like this that
drives me away. If you pick any one framework, you get half of a crowd telling
you that it sucks, and then a year later your version is now
deprecated/replaced and you get to re-do everything again. I've attempted to
avoid the whole web-app scene, but with the current job market, looks like one
has to know one of these frameworks...

~~~
woah
Angular got a lot of its popularity, I think, from people with a similar
mentality as you. Since it had the Google stamp of approval, it was seen as
being more stable. Unfortunately, this was not actually the case.

I say, be thankful for the flux currently underway, and realize that it will
result in some really good tech when it's all sorted out. Until then, either
get used to learning new things, or leave front end dev to the professionals.

~~~
esaym
The irony is angular was going to be the framework I learned the next time I
had free time. Now I am not so sure.

------
jMyles
If Angular is not The Thing (a premise which I have no trouble believing),
then what is a Good Thing to perform the task of, for example, consuming
Django Rest Framework endpoints and making a frontend of them?

~~~
atirip
IMHO Good Thing is to have set of libraries and not a framework at all. Start
with handcrafting all HTML,CSS with interactions you need. You HTML skeleton
will depend greatly on what you want to achieve - like when one page changes
to other and theres a ajax call between - where you put the wait screen: as
separate, on old page, then wait, transit to new at once, then wait and so on.
If that is done you know broadly what you need. Example configuration may be
React for rendering, cherry picked Model (or State) from Ampersand, Backbone
Events Standalone for event bus. Something for History/routes too, can't
recommend anything specific because my projects did not had one (yes, you can
build web-app without back button support). This way if something better comes
up, you can switch, if something is abandoned, gets your way, you can switch.
Or you can rewrite it in-house fairly easily. I imagine that when you discover
that React is too much, too heavy, too bloaty (for example, i'm not saying,
that it is, we are happy React users now), then preserving all API calls and
replacing it with few lines of Mustache templates is doable. Not trivial, but
doable.

~~~
mattgreenrocks
Meta: digging the downvotes in lieu of actual discussion here. Stay classy.

~~~
cloakandswagger
The comment above yours is a giant, unbroken paragraph of dogma. I'd say it's
worthy of downvotes.

------
hokkos
I've got to build an SPA and I'm trying to choose between Angular and React,
can you guide me a little, the app will :

\- create a big form based on an XML schemas, the form will be used to
generate valid XML with the schemas

\- some schemas can be really big with more than 3000 elements, the whole
thing won't be shown in full to the user directly but probably folded

\- because it is based on XML Schema, it must have interactivity to make some
elements repeatable, and groups of nested elements repeatable, some elements
with bounds, some maybe draggable to reorder them, everything an XSD can do...

\- it will also some kind of polymorphism where you can choose the children
element type and have the corresponding schema showed

\- it will also show a leaflet map, with some interaction between the form and
the map

\- there is also a rich text editor where you can arrange xml objects between
formated text

I fear that angular won't be fast enough for that, but his support for forms
seems better, I've tested JsonSchema forms generator like
[https://github.com/Textalk/angular-schema-
form](https://github.com/Textalk/angular-schema-form) and
[https://github.com/formly-js/angular-formly](https://github.com/formly-
js/angular-formly) the first one is slow when editing 3000 items the second
seems fast when editing, and slow when it generates the json. I've done some
angular tutorials and their concepts don't stick in my head. I've tested React
and their concept stick easily in my head but there is less native support for
forms.

I had just decided to go with angular partly because of all the hype around
it, but I see the article and others as a bad omen and I want to go with react
now. Any advise ?

~~~
jasim
Angular will force you to convert all your rendering logic into its
declarative API: ng-if, ng-repeat, ng-include etc. With React, you can simply
write your program logic in Javascript and compose, reuse and pass around
parameterized components with ease.

Try building a simple nested tree in both Angular and React to see how both
feels.

Khan Academy has open-sourced their QA builder that supports creating
questions and answers with graphs, radiobuttons, multi-selects, images etc. It
is built in React. Take a look here:
[https://github.com/Khan/perseus](https://github.com/Khan/perseus)

~~~
hokkos
Thanks, the idea to use code instead of a limited set of declarations to
create the view is convincing.

~~~
kid0m4n
And now we go around in circles. ASP and classic PHP were the forerunners of
using code to do the view!

~~~
ep103
That is very, very different, and you know that : p

------
dynjo
We built a pretty complex app with Angular
([https://slimwiki.com](https://slimwiki.com)) and have had nothing but great
experiences. The main issues are no guidelines about the right/wrong way to do
things, it needs to be more opinionated.

~~~
robin_reala
That’s been my biggest problem with Angular too; I’d love some more opinions.

------
lbacaj
I think people are failing to see that not all apps are huge monolithic
applications; for most of those apps Angular works just fine.

In fact we should be striving to get away from all of those monolithic code
bases as much as we can. In the cases where we can't get away from that then
we should be going with tried and trusted methods of building those apps and
probably relying on the server a hell of a lot more for those kinds of really
large/enterprise/corporate apps.

Most use cases for angular are to make a web app that pulls and pushes data
from some Restful service. Angular lets us take that web app, through
cordova/phonegap/etc, and wrap it into a mobile ready application that you can
push to an app store.

Whats wrong with that?

~~~
woah
Cordova has nothing to do with angular. Why do you bring it up? In fact,
angular is probably one of the worst possible frameworks to wrap into a mobile
app, because of its abysmal performance.[1]

[1] [http://matt-esch.github.io/mercury-perf/](http://matt-
esch.github.io/mercury-perf/)

~~~
Bahamut
That's an older version of Angular being compared against - lots of perf
improvements have been made since.

------
lucisferre
Sorry, did I miss the part where the author explained the "right (tm)" way to
do things these days?

Seriously though, I've used Angular just as long as the author and for the
most part I wholeheartedly agree with the complaints (and I have complained
myself for some time). However, what is the "better" way? People keep throwing
out things like React, but React solves much less for app developers. Also,
that answer doesn't help the countless people who began app development more
than a year or so before React was released.

The Javascript ecosystem is evolving constantly and yet in some ways not much
at all. Throughout that time, I've found that just about everyone can find
excellent reasons not to use the various frameworks and libraries but few
offer concrete recommendations in exchange for these criticisms. It's
disappointing.

At this point in our own project, like many others I assume, we are
reconsidering Angular. Not simple because we don't like it, but because
clearly the Angular team doesn't either. Angular 2.0, like Sproutcore 2.0
before it, appears to be a complete rewrite. (Rightfully so.) As a result, we
plan to examine our other options in detail while our work is still mostly in
the prototype territory.

Right now however, I don't think I've seen anything yet, that makes sense for
most people who've started out with Angular to do that re-write. I'm hoping as
I spend more time examining this I'll find I'm wrong.

I've had many people ask me what framework they should use for new projects
and every time I've said, it probably doesn't matter use right now, but be
prepared to fully rewrite things in a year or so. The JS ecosystem is in so
much flux right now that you can't count on any of these choices being the
right one in couple of years. I've accepted that reality for now.

People hate this answer. They tell me that no PM/Exec is going to want to hear
that. Fine, don't tell them. The silver lining is that whatever does comes to
save us will hopefully be so much more productive than what you were doing
before you won't care about rewriting it, you'll do it because it actually
makes sense.

Let's all hope that's true.

~~~
woah
Try vue.js. Same general idea as angular, way less bs. However, the author did
just get hired by meteor, so that is something to consider.

------
prottmann
The problem is not Angular specific, every Framework is designed to solve a
certain problem in a certain way.

But most developers think, that when they learn once a Framework, they can use
it for any kind of project.

When i read "xxx is really cool and fun" iam really careful. Most people
create a "Hello World" and then THEIR favorite framework is the greatest thing
in the universe and they communicate it to others.

Take a framework, live with the mistakes, until the next "better" framework
appear... and it will appear, and the next, and .... ;)

------
Bahamut
I also have been using Angular for my entire professional developer career,
which in a few days will hit 2 years.

This article is pretty accurate for the most part, although some of the minor
complaints are not quite so accurate.

Performance is something to be careful about, but the Angular team has worked
hard at improving it and it has improved immensely with 1.3 - optimizations
such as bind once & $watchGroup and optimizations around the $digest cycle and
$watch make it a huge improvement over 1.2. I want to say there is a chart
floating around showing over 30% improvement.

As far as frameworks go, I believe Angular is the best we have currently. It
does a lot for you without getting too opinionated in general, and some of its
tooling is just flat out better than much of what you can find in the wild.

I have been experimenting with Polymer lately though with an eye towards web
components - there is a lot of change coming in how we will have to structure
our code. I suspect that those using React will also not be shielded from the
pain of integration with ES6 and web components as well, and so I have been
hesitant to recommend it in a core product. Ember claims they will make the
breaking changes slower, but I also suspect that it will limit its growth as
well.

Frontend seems to be rolling on as fast as ever - I don't see much of a way
around everyone having to scrap their code regardless of the major library
chosen for their projects. I'm hoping the pain dies down once ES6 and web
components becomes the norm though.

~~~
Cthulhu_
I wouldn't recommend either Polymer or the current development version of
Angular 2.0 for a production application just yet; Polymer leans heavily on
the unfinished web components standard and other experimental and
unimplemented browser features, and Angular 2.0 is still under heavy
development. I also gather they're either going to use ES6-but-with-extras-
because-we-can, or with AtScript, ES6-with-types-because-why-not. I can't say
I agree with those motivations (and I'm sure I've got it wrong), and I quite
like the more vanilla JS feel of Angular 1.x.

Anyway, my point is, both of those aren't production-ready.

~~~
Bahamut
Oh, I agree about not moving to either for a major project currently, although
I'm probably going to use Polymer for a small static site project I'll be
starting in the next month or two - web components are supported in Chrome
currently (shadow DOM and custom elements at least - not sure about the data
binding part yet), and Polymer's platform.js makes it very easy to polyfill
the missing functionality.

I suspect Angular 2 will be the best we have once it comes out, but I also
question some of the decisions made from certain perspectives. At least
they're listening to the community, evaluating the feedback and suggestions,
and incorporating it into their decision making though, such as the change
with the HTML templates.

------
praetorian84
As someone who has thus far only used with Angular for smaller projects,
seeing performance raised as a concern is a bit of a concern for ever using it
in a serious project. Would still like to see some numbers to back up the
anecdotal evidence.

It's also hard to motivate starting a potentially large project in Angular
right now, knowing that v2 is on the way that is basically a new framework.

~~~
woah
[http://matt-esch.github.io/mercury-perf/](http://matt-esch.github.io/mercury-
perf/)

------
datashovel
The thing I really like about Angular is it makes composition of complex ideas
relatively easy. The encapsulation and dependency injection is perfect way to
allow you to be as structured or unstructured as you want / need to be.

I can understand how someone coming from more traditional frameworks, and
working in an environment where you are rarely or never required to think
outside the box, will have difficulty making the transition.

Where I personally think Angular could be better (yet was state-of-the-art
when it originally came out) is with directives. Now, I'm not talking about
run-of-the-mill directives that are easy, that implement relatively
straightforward concepts. I'm talking about highly complex functionality that
you want to encapsulate into a single "thing" in your code. I think Polymer is
going to fill that gap. That being said, Angular team has already (if it
hasn't changed) decided they're going to be moving forward with Polymer.

Personally I think Angular + Polymer is going to be hard combination to beat.

------
gldalmaso
"And whar are no-no factors for angular?

    
    
        Teams with varying experience.
        Projects, which are intended to grow.
        Lack of highly experienced frontend lead developer, who will look through the code all the time."
    
    

I am greatly interested in learning what is the alternative that would be a
'yes-yes' in these bulletpoints.

~~~
sytelus
This kind of distorts the issue here. The problem is not lack of highly
skilled devs but rather the fact that you _need_ highly skills devs to digest
and maintain the level of complexity that Angular produces.

I'm big believer on light frameworks that does least amount of abstractions
and can get out of way if you need. You definitely want to avoid frameworks
that claims to abstract everything away and especially those that requires to
learn entirely new way of doing pretty much everything and its own world of
lingua franca. My preference therefore gravitates towards lighweight stuff
like KnockoutJS and likes. Any average dev can understand KnockoutJS in just
hour or two. More importantly, most devs can immediately have intuitive
understanding of how things work under the hood and therefore can anticipate
performance issues or easily extend it.

~~~
Cthulhu_
You don't need highly skilled devs, you need a disciplined team - which should
review each other's members' code, stick to a style guide, research best
practices, etc.

Like with every software development, actually.

------
EugeneOZ
"2 years" and "10 projects" \- 2 months for each project? And he talks about
"big enterprise apps"? lol.

Please links to examples of your code, author.

I wonder how people can't understand all the power of the 'directives'
approach it's the MOST powerful thing in web development now and only advice I
can give to future inventors of new frameworks: implement 'directives'
concept, and then do everything you want else. It's advice after my 3 years
with Angular, and counting ;)

Reusable code and TDD is the key for growing apps and directives - most
successful following of this way.

\---/ please news.ycombinator, treat new line symbols as new line symbols and
use ANY modern framework to make this site less slow and more mobile friendly

------
jaunkst
All of the frameworks suffer from performance issues. Performance will get
better, but we will always have to profile our applications. A slow web
component used in a ng-repeat scenario will always bring the application down
to its knees. We can't just design a spaceship and expect an engineer to build
a performant application. Designs need boundaries and guides as performance is
one if not the most important factor of the UX. We also cannot reason with the
jQuery spaghetti demon. Practice some Feng Shui, write better code. Understand
whats going on in your framework. Work through the limitations with your
designers. We are at the mercy of limited computation until our browsers give
us more, and there is no magic bullet.

------
rpocklin
It's fair to highlight the less-ideal parts of AngularJS, but IMO the
ecosystem and testing integration is as important as the framework code
itself. Most of the issues the author mentions can be mitigated (eg. use ui-
router).

The momentum behind AngularJS is huge, and with the 1.3 release I feel like
90% of webapps can be written well in Angular. Ionic is a great example of
pushing AngularJS to the edge with mobile applications.

It really is up to the team to enforce good practices, pair or review code and
refactor and unit test components. There is no framework which can make this
happen, you need to be disciplined and always look to leanr more and improve
the code you have written.

The author certainly does not recommend anything else, so where to now?

------
cbdileo
I feel somewhat conflicted about this blog post. I can agree with what others
are saying in the comments that all frameworks have there pitfalls. A lot of
development is dealing with trade offs and your teams varying experience.

On the other hand, I agree with the author that there is a tipping point where
a framework/tool becomes too much of a burden. Sure, we can all do it the
"right way" but teams don't always have people with the experience to even
know what the right way is.

We should think about the frameworks we use as tools. Make sure the tool is
right for the problem and the team. Also, don't try to apply all your older
experience to the new tool. Take time to learn about the thing you use.

------
aaronem
You know, I'm just going to say it:

Angular is the Rails of Javascript.

That probably sounds like a derogation. But behold: I offer nuance!

They're both big and powerful, and capable of rewarding dedicated study with
enormous power. Thus they develop a devoted following whose members often do
things lesser mortals find little short of wizardry.

They're also both built to be friendly and welcoming to the newcomer, and
offer a relatively short and comfortable path from zero to basic productivity.
Thus they trigger the "I made a thing!" reward mechanism which excites newbies
and leaves them thirsting for more.

They also, in order to go from newbie to wizard, involve a learning curve like
the north face of K2.

In both cases, it's a necessary consequence of the design decisions on which
the platform is based, and those decisions, by and large, have sensible
reasons behind them -- not, I hasten to note, decisions with which everyone
will (or should) agree, but decisions which can be reasonably defended.

But that doesn't make it a good thing. When people start off with "I made a
thing!" and then run smack into a sheer wall of ice and granite, initial
excitement very often turns into frustration and even rage, as on display in
some comments here in this very thread.

(I hasten again to add that I'm not judging anyone for being frustrated and
angry over hitting that wall -- indeed, to do so would make me a hypocrite,
given my reaction to hitting that wall with Rails a year or so ago.)

Further compounding the issue is that, often enough, wizards who've forgotten
the travails of their ascent will condescend to say things like "Well, what's
so hard? Just read {this book,that blog post,&c.} and it's all right there."
Well, sure, for wizards, who are well accustomed to interpreting one another's
cryptic _aides-memoire_. For those of us still toiling our way up the hill,
not so much.

I will note, though, that while I hit that wall (hard!) with Rails, and in the
end couldn't make it up, I haven't had the same problem with Angular. The sole
significant difference I can identify, between the two attempts, is this:

When I took on Rails, there was no one else in the organization who knew (or
should've known) the first thing about the platform. When I had a problem with
Rails, I faced it all alone, with only my Google-fu, my source-diving skills,
and my perseverance on which to rely. For a while I did well, but in the long
run, for all but the most exceptional engineers, such expenditure of personal
resource without resupply becomes unsustainable.

When I take on Angular, I do so with the support of a large team, composed of
the most brilliant and capable engineers among whom I have ever had the
privilege of working. When I have a problem with Angular, I have a dozen
people at my back, at least one of whom is all but guaranteed to have
encountered the exact same situation previously -- or, if not this precise
permutation, then something very like it, from which experience more often
than not comes precisely the advice I need to hear, to guide me in the
direction of a solution.

Of course, whether this is really useful to anyone is an open question; I
think it's a little facile, at least, to say "Oh, if you're having Angular
problems, all you have to do is find a team of amazing people who mostly all
have years of Angular experience, and work with them!" But, at the very least,
if you're going to be fighting through the whole thing all by your onesome,
maybe think about picking up a less comprehensive but more comprehensible
framework, instead.

~~~
striking
My opinion of Angular is now that it's basically the equivalent of PHP (if
we're comparing it to other languages.) PHP is super easy to get started with
and is magical and with enough forethought and planning, proves to be a
serviceable language suitable for small projects.

However, if you don't draw lines in the sand for yourself and watch
performance very carefully as you scale, your app will suck. For reasons of
maintenance or user experience, it will suck.

It's awesome for tiny projects or things that won't need to be changed or
internal use stuff. I personally am using it to build a prototype of a
product. But I'm planning to convert this prototype very soon to React or
Meteor.

~~~
aaronem
Comparing Angular with PHP doesn't strike me as entirely fair; Angular,
whatever else one might say about it, has a high degree of conceptual
consistency in its internals, whereas PHP, for all that it's improved over the
past few years, remains an utter farrago and likely always will. Comparing
Angular with Laravel might be more reasonable, but my lack of knowledge of the
latter framework forbids me from commenting further on the comparison.

------
FrankieTh
I really think that the bigger the app gets the smaller the framework should
be. If it lacks functionality, it should be possible to easily add it using
the frameworks core functionality.

IMHO in general the core functionality of a clientside framework is to provide
a way of structuring the app and allow for communication between logical units
that are nestable and modularized.

If a basic framework does that, and only that, it should be bulletproof. I
admit, it took me 10 years to rethink and recode this over and over - and
there is no end in sight.

I love this discussion, it reflects much of my thoughts about the issue.

------
sebastianconcpt
I really resonate with: "Do not make things easy to use, make your components
and abstractions simple to understand."

And not only for AngularJS but as design principle.

------
cportela
I am not a lover of angular, but the reason angular is so popular is because
it gets the prototype out there.

So many things and places are just doing things "lean" and "iterating" so
angular makes that easy.

I'm not sure anyone could tell me Angular isn't __very __productive and that
it wouldn 't be tempting to use it so you can get some fairly magical
experiences for users and in demos.

------
limaoscarjuliet
So if not Angular then... what? If I wanted to do a single page app with REST
backend (little to no db access), what would you recommend?

------
username__
I've been using Angular now for a year and half, and a year professionally.
The only issues I've run into are pages with large data bindings. I would love
if the Angular team could recommend a solution other than "don't do that."
That answer is simply unacceptable in my opinion -- their silence on this
topic has been very frustrating.

~~~
bahmutov
Take a look at step by step example improving angular web app performance:
[http://bahmutov.calepin.co/improving-angular-web-app-
perform...](http://bahmutov.calepin.co/improving-angular-web-app-performance-
example.html) I think any framework or library could suffer from these
problems.

------
CmonDev
"5 star performance requirements" \- Scala Play comes to mind rather than any
JS MVC frankly speaking.

------
fndrplayer13
I don't mean to be a jerk, but this article is really poorly organized.

------
cturhan
As author says in the comment, these are valid for Angular 1.x so I'm hoping
that angular 2.x will be more carefully designed framework.

------
kuni-toko-tachi
AngularJS owes it success to an easy onboard that allows a user to easily
create a gimmicky two-way binding demo. And then the pain begins.

It matters little whether some find it productive, what matters is that the
engineering principles it is based upon are fundamentally unsound.

Control and conditionals in attributes are absurd. Especially when they
require learning an expression language unique to that framework. Especially
when they create side effects. Why should something as simple as a loop or if
create a new controller and scope? This is absurd. The expression language is
not statically analyzable to boot.

There is no reason for a framework to do anything beyond handling the last
mile tranform between view model and DOM. Everything else can be done through
JavaScript and modules.

JavaScript is a wonderfully expressive language, reinventing that through some
hacked up expression language makes no sense and buys no advantage.

Bindings can be handled through a multitude of great npm modules.

Watch the video of the Google Analytics team explaining the cortitions needed
to make AngularJS performant. Watch the videos where the AngularJS 2 team
discards nearly everything from 1.3 (and then adds their own comical
nonsense).

Declarative DOM manipulation through a virtual DOM is the future - every more
than web components will be. Why? Because instead of being another "web
framework", is it sound computer science.

~~~
Cthulhu_
> It matters little whether some find it productive, what matters is that the
> engineering principles it is based upon are fundamentally unsound.

I disagree. What matters is whether you can produce a working application -
and iterate on that, but after actually releasing. Angular is modular enough
to allow for gradual optimization (like integrating React et al), instead of
doing premature optimization.

Using vanilla JS like you recommend will lead to a lot of reinventing the
wheel, and for new developers to have no clue what's going on (they have to
learn the framework you thought up). At least you can make predictions about
applications when it says 'AngularJS' on the job advert.

~~~
kuni-toko-tachi
True, but Angular reinvents the wheel unnecessarily and at a cost of
performance and being difficult to reason about.

JavaScript code can be easily written for reuse and composition. When a
framework attempts to co-opt that there should be a very good reason. For
Angular no such reason exists.

------
lcfcjs
Bizarrely enough, I've built about 4 web apps ( using Angular over the past 2
years also. However, I've found that scalability (mainly due to it's
reusability) is one of the strongest points. I've worked with enormous
applications built entirely with jQuery.

I love angular, but perhaps thats because I'd only worked with jQuery before.

------
waps
The real news should be : javascript framework is actually still considered
useful for something after 2 years.

