

AngularJS is amazing, and hard as hell - bitsweet
https://coderwall.com/p/3qclqg

======
calebgilbert
As someone actively rolling their own JavaScript framework (more as a learning
exercise than for anything else), I second the opinion that AngularJS is
uniquely hard/blackboxed compared to other JavaScript frameworks (which I
frequently refer to in order to guide my own efforts).

For instance Backbone is pretty much what would happen (give or take) if all
the JavaScript books on how to program OOP and MV* got together and build a JS
framework. It's not fancy, it's not "magic", but it is very approachable in
terms of advanced standard/best/popular JavaScript programming practices.

AngularJS left all that stuff behind and built their own little world. It
might even be a great world, but on the surface or to the implementation-level
developer has little to do with "regular" advanced JavaScript programming
techniques/patterns.

To me it's a bit like the JavaScript version of Drupal, which gives you a ton
out of the box, but is just it's own whole world of conventions etc, that has
little do with anything seen outside of itself.

~~~
ryanisinallofus
"JavaScript version of Drupal"

Ouch, but accurate.

~~~
marknutter
Wow, this could not be further from the truth. Angular is much more similar to
Rails than Drupal. Like Rails, it magically takes care of some of the more
routine and annoying parts of front-end development like DOM manipulation and
testing, but beyond that you're just writing javascript without having to
worry about making sure your views are being updated. To extend the analogy I
would compare Backbone to Sinatra. It's much smaller, allows the developer to
make more choices, but takes care of less details.

So if you prefer Sinatra over Rails, you'll probably prefer Backbone over
Angular or Ember. If you like all the magic Rails has to offer, you're
probably going to feel right at home with Angular. But comparing Angular to
Drupal is ridiculous.

~~~
mmatants
Actually, I would compare AngularJS to Node's Express or Ruby's Sinatra.
Because by and large it's actually a set of highly reusable and composable
blocks that make very few assumptions about what you're trying to do (aside
from something vaguely DOM related). It's a fairly pure look at the MVVM
metaphor and does not even assume you're trying to do CRUD or RPC or whatever.
Heck, you're not even tied to using client-side routing.

~~~
ianstormtaylor
Please don't compare it to Express. Express is a beautifully simple, and clean
framework that strives to always have the least magic possible. You can see
that goal reflected in the simplicity of its documentation as well. You can
build on top of it with any other node modules you want exactly because it
doesn't make strict assumptions about your code. If you were to compare
Express to any front-end framework it would be Backbone.

Angular is not simple in any since of the word. (Especially if we're talking
about its documentation.) And it's components are only reusable inside the
Angular bubble.

~~~
marknutter
Plus isn't express server side anyways?

------
olegp
We've been using it at [https://starthq.com](https://starthq.com) for about 6
months and I have to agree. Angular is so hard that even the core committers
sometimes struggle to keep it together.

I gave a talk recently on our experience with some tips that may be of
interest, here's a link to the slides:
[https://docs.google.com/presentation/d/13_tqIGJYJo7CxLvgZlUQ...](https://docs.google.com/presentation/d/13_tqIGJYJo7CxLvgZlUQ0RpkXEnxJxZKrhBChoP6w4w/edit?usp=sharing)

If this comment gets enough upvotes, I can upload a slidecast with the audio
as well ;)

On unrelated note: Are there any web apps out there for creating slidecasts
apart from Slideshare?

~~~
baudehlo
Can you expand on your experience with IE8 and Angular?

~~~
olegp
IE8 is a second class citizen in Angular and Angular UI, so some things that
should work, don't. We've spent a fair amount of time patching it up and
trying to get our patches merged into master. Here's a list of things we
fixed:
[https://gist.github.com/olegp/f564ad1a17cadf269d44](https://gist.github.com/olegp/f564ad1a17cadf269d44)

------
ulisesrmzroche
Hard as hell? Nothing to be proud of. Main reason that keeps me from buying
into the Angular hype is that apparently even after a year of practice in
production, no one knows what the hell is going on.

~~~
ryanisinallofus
Exactly. In a post-rails world how can poor developer ergonomics even be an
acceptable thing?

~~~
swalsh
Damnit, I wish Shit HN says was still updating.

~~~
ryanisinallofus
Haha. Is this better?

HARD IS NOT GOOD, HARD IS STUPID

------
cpprototypes
AngularJS is a level of abstraction above the old JQuery and Backbone style of
app. It frees the developer from worrying about the tedious details of
updating the DOM. For example, a typical old style app would do something like
this:

    
    
      function updateCheckoutButton(cart) {
        if (cart.length === 0) {
          $('#checkoutButton').addClass('light-blue');
          $('#checkoutButton').prop('disabled', true);
        else {
          $('#checkoutButton').addClass('dark-blue');
          $('#checkoutButton').prop('disabled', false);
        }
      }

And in the HTML:

    
    
      <button id="checkoutButton"></button>
    

Compare that to how it would be done in AngularJS

(In the controller code)

    
    
      scope.isCartEmpty = function() {
        return cart.length === 0;
      }
    

(In the HTML)

    
    
      <button ng-class="{'dark-blue':!isCartEmpty(), 'light-blue':isCartEmpty()}" ng-disabled="isCartEmpty()"></button>
    

The AngularJS style has the following advantages:

1) Code reduction - The C language was invented to be an abstraction above
assembly. Assembly code has a lot of low level details of moving values from
registers, adding them, etc. The C language abstracts that away. In a similar
way, AngularJS abstracts away the low level details of DOM manipulation.

2) Data binding - In the first example, it's important that
updateCheckoutButton() is called wherever it's necessary for it to be called.
Otherwise bugs could appear when the button is not updating when it should.
AngularJS simplifies this to just listening for changes in the scope. It's
possible to achieve the same thing using events, but again that's a lot of low
level details of managing events and event propagation.

3) Declarative UI - <button id="checkoutButton"></button> tells me nothing
about how this button behaves. The AngularJS example is immediately obvious on
the button's behavior.

4) Unit testing - I can write a unit test to ensure that the value of
scope.isCartEmpty is updating correctly. This test can be pure JS without any
DOM support. It's much harder to test the DOM manipulation code style.

------
sker
I see AngularJS as a general purpose framework, conceptually, similar to .NET,
JVM, Node.js, although limited in scope to front-end web development.

What I mean is that there's still room for someone to build another framework
on top of AngularJS, with common features such as authentication,
authorization, breadcrumbs, rich controls (grids, combos, autocomplete), etc.

I also find it harder to grasp than other frameworks like ASP.NET, RoR,
Django, probably because you have to do so many things from scratch and
because it introduces many concepts not commonly found on your typical MVC
framework.

~~~
christoph
For me, even though it's PHP, ProcessWire consistently models data in a human
way. I've put the out-the-box backend CMS in front of people that interact
with computers very little and they instantly "get it". All data is simply a
node in a hierarchy, and is easily movable and editable. I don't understand
why more frameworks don't copy this basic structure.

If you watch "The mother of all demos"[1] the structure is almost visually 95%
the same.

I look at Angular and it's looks complicated - the article is about how
complicated it is. Surely we should be striving for tools the everyday man can
pick up and play with?

[1] - [https://www.youtube.com/watch?v=yJDv-
zdhzMY](https://www.youtube.com/watch?v=yJDv-zdhzMY)

~~~
jacques_chester
> _I don 't understand why more frameworks don't copy this basic structure._

Lots of problem domains are difficult to model as trees because often, a node
can be logically assigned to multiple parents, but the tree model requires it
be physically assigned to only one.

Recently I bought a prepaid SIM card for a trip I am making to the USA.

In my bookkeeping system, I could enter it either as a transaction against the
"Telephone & Internet" expense account, or I could enter it against
"International Travel". What I can't do, because trees require mutual
exclusion, is enter it under both. That breaks the model.

If instead Renaissance accountants had understood sets and relations, I might
be able to log it against _both_ and then derive whichever view of the data
was necessary.

And that's the problem with hierarchical data. It privileges _one and only
one_ view of the problem domain. As soon as you need some other view, you are
in trouble. If your project management system organises by project, then
getting per-staff reports is now much harder. If your class hierarchy views
A->B as the natural order of creation, what happens when you come up with
cases where C->A but not C->B? You can't: you have to introduce complicated
workarounds.

Hierarchies are simple to understand on their face. But they quickly come
apart when faced with the real world and ad hoc queries about the state of the
real world.

~~~
LBarret
Sets and relations are indeed the most richest metamodel but most of the time
a dag (directly acyclic graph) is enough : object can be connected to many
parents but it keeps most the hierarchical organisation, which is easier to
model.

~~~
jacques_chester
What can be modelled as a graph can be modelled as sets and relations and vice
versa; they're both equally powerful. But just as any two Turing-complete
languages are equally powerful, the discussion doesn't end there.

It's still the same problem: you have mixed the logical model and physical
structure of your data together. You are privileging one view of the data over
all other views.

I consider switching to a full graph model a complicated workaround for the
limitations of trees. You now introduce new and exciting paradoxes and you
will need to litter your code with special cases (B means C, but only when A
is not an ancestor, otherwise it means D). Ask C++ programmers about the joys
of multiple inheritance.

In some cases the logical model _is_ a graph and in those cases you should
absolutely model it as a graph. But modelling _all_ problems as a graph is
inadvisable.

------
cia_plant
Angular is yet another programming technology made by people who think that
this:

    
    
        <span ng-switch="foo">
          <span ng-switch-when="bar">...</span>
          <span ng-switch-default>...</span>
        </span>
    

Is in some way easier or better than this:

    
    
        if(foo == bar) { ... } else { ... }
    

It also has this weird retro stuff like dynamic scopes and reactive
programming. It's also really slow, because it implements reactive programming
with dirty checking.

Still not sure what problem it's trying to solve.

~~~
chrisrhoden
Few problems with your argument.

1) The first example is a template/view. It is reactively updated
automatically when the values referenced are updated. It maps to markup on the
page. The second example is a basic control structure that does nothing.

2)

    
    
        <span ng-bind="foo == bar ? '...' : '...'"></span>

~~~
cia_plant
Yeah, I'm not saying that Angular literally replaces javascript "if" syntax
with SGML syntax.

However, it does fit in with a long line of tools whose premise is "Normal
programming with normal control flow is an insufficient tool for the unique
problems of ${DOMAIN}. We need to create a new programming model with its own
syntax and exotic control flow to make things easier."

The appearance of the "if-statement-in-markup" (or "if-statement-in-flowchart-
diagrams", etc.) is to me a sure sign of a certain kind of misguided system.

~~~
chrisrhoden
You mean like literally every other template language for the web?

------
swalsh
I worked in web dev 3 years ago, then I moved to WPF. Recently, the place I
was at decided to try some web development. Being the only guy with experience
in it, i landed the project.

It is blowing my mind, how in 3 years the environment is so different. I'm
sure these things existed on the fringes, but its very mainstream now.

When I left, JQuery was the in thing, it was pretty rad. Today i'm doing MVC,
unit testing, and code coverage WITH JAVASCRIPT!

ASP.NET MVC is pretty slick too.

------
agibsonccc
Angular reminds me a lot of enterprise java. Lots of its own conventions,
inversion of control and lots of magic.

That being said, I love working with it. It's definitely cumbersome feeling at
times though. Despite that, I like the idea of self contained modules, the
html binding, and all of the semantics that go with it.

It's definitely an acquired taste though. There are many things that you can
do with it that you probably can't take to other javascript frameworks though.

~~~
cpprototypes
Yeah it's similar to some Java technologies, especially Spring or Guice.

~~~
agibsonccc
Ironically why I like it, as bloated and silly as the technologies are, it's
what I cut my teeth on (let's just say my first boss was a former IBM guy)

------
lucidrains
it isn't that hard... it's actually simpler than Ember to grok.

it is the right thing to learn right now anyhow, as the concepts naturally
leads to web components, which will probably be the future of app development
(cue polymer [http://www.polymer-project.org/](http://www.polymer-
project.org/)).

~~~
cookrn
AuraJS is another project to check out along the web components track:
[http://aurajs.com/](http://aurajs.com/)

~~~
lucidrains
cool, i'll check it out, thanks cookrn :D

------
chrisfarms
Angular's dependency injection is literally magic. Someone who has never used
javascript before would probably have the advantage over a seasoned js-pro
when reading the code.

That said; once I realised what it is doing, I quite like it and it has led to
some of the cleanest client-side code I've written.

~~~
aidos
As you say - once you know what's going on it's not that magical at all. It
literally looks at the text source for you function definition and injects the
arguments you ask for. Certainly, when I first looked at it I felt the docs
didn't explain that little nugget so you sort of wonder how your arguments are
injected. More of a doc problem than an obfuscation issue, I think.

~~~
ianstormtaylor
Careful, that's a pretty easy (read: tautological) way to justify all magic.

------
Kiro
Am I the only one making AngularJS apps without writing a single test? The
examples given are usually "test that this custom math function is doing what
it should" but how often do you have those in a real app?

~~~
guiomie
I dont either.

~~~
aidos
Me either - but I feel guilty about it. I get away with it as the sole
developer, but it's really not a great practice.

~~~
tomsaffell
we should form a support group -- i too feel guilty about our lack of test
coverage. but honestly, i dont think its much of a problem. we know from user
feedback that none of our big issues are bugs in our Angular code.

------
Ycros
We're using AngularJS for the second time on a project, and it's great. While
I found the basics easy to pick up, some of my team struggled a bit more (but
they've also spent less time doing heavy client-side JS development).

The biggest problem AngularJS has is documentation. Some of it is missing,
some of it is poorly explained, all of it should have examples. The developer
guide and API reference both need a rework/rewrite. I think the team should
focus on this after this major 1.2 release.

What comes out of poor documentation is that best practices are not
immediately obvious, because if you're trying to guess things from just the
API and just picking a random way to achieve your end result, chances are
you're going to do it wrong. This has been identified at
[https://github.com/angular-ui/community/issues/1](https://github.com/angular-
ui/community/issues/1) so hopefully it's going to get better.

The major thing which I think almost everyone gets wrong at first are the
relationships between templates, scopes, controllers, services and your actual
data. If you get this wrong you'll either end up writing a bunch of tricky
workaround code, having memory leaks or subtle data binding bugs.

I highly recommend everyone watches the best practices video from the
AngularJS team at
[http://www.youtube.com/watch?v=ZhfUv0spHCY](http://www.youtube.com/watch?v=ZhfUv0spHCY)

------
mping
Let met tell you why angular is hard. It is because most of us are not
familiarized with the concepts. The docs are hard to read and some stuff is
buried deep within the language, but once you understand the concepts it's
very easy to get started. We have introduced angular here and are using it in
several production apps, and everyone is very happy. We had one team member
learning it in a week (granted, he could learn very fast because he could ask
someone when he had doubts), and already wrote 2 or 3 apps in the next weeks.
An he isn't a "javascript" guy.

In fact, most or all of angular concepts can be found elsewhere in other
frameworks such as spring/guice(IoC), any decent ORM (dirty checking, "digest
cycles"), WPF (directives/code-behind,declarative, whatever you want to call
it), etc.

Although I feel that its source code is hard to read sometimes, I'm happy to
let the framework do its magic and allow me to write apps without getting in
the way. I can write modular components and test them with the
angular/grunt/karma combo. If I need tabs, modal or whatever I can pull some
libs and get it working quickly. If size/speed's a serious concern, I'll write
my own lib/directive/etc.

------
purplelobster
I decided not to go with AngularJS, mainly because I want to reuse as much
client side logic as possible in future native apps and Angular seemed very
tightly coupled to browser apps and the DOM. With Backbone find it easier to
separate the UI specific code so that I can swap it out and control native UI
elements instead, running the js in a hidden WebView. Anyone tell me if I'm
wrong.

~~~
marknutter
Angular makes front-end development much more like native development because
it gives you true MVC. Meaning, the views are automatically updated based on
the current value of the models. In an Angular controller, you really don't
care or even know about the view other than the fact that you're sharing scope
with it. The controller just makes sure the models are in the correct state
and the view handles the rest automatically, perfectly decoupled.

In my experience, this is much closer to how native development works. In an
iOS app, you have your view controllers which are responsible for responding
to user input and making sure the models are in the right state. The views
just automatically update themselves based on those models, much like Angular.
So if you're writing your Angular apps correctly, they should be very similar
to your native apps.

~~~
bsaul
genuely curious : how do you manage to keep your views automaticcaly
synchronized with the model in IOS ? It seems that your controller's in charge
of the two-way data binding, and that it is clearly NOT automatic... contrary
to angular.

~~~
marknutter
Check out uittableviewcontroller or uilistviewcontroller. With those you
specific a data source and the views automatically render based on that data.

------
Throwadev
I haven't used either one, but can anyone who has used both shed some light on
how ember.js compares WRT to ease of use / complexity?

~~~
HNJohnC
I have learned and used both within the last few months with the most up to
date versions of both and I settled on Angular for our CRUD business
applications.

Angular is more mature, well thought out, better supported, much better
documented, is logically consistent throughout, supports the concepts of MVC
properly (unit testing is a breeze), much easier to use with REST backends I
could go on and on.

There simply is no comparison.

Ember, even after the major changes recently, feels like someone's idea of how
MVC should be done without consulting any existing standards or ideas about
MVC or REST or any related technology and just throwing in things without
thinking them through.

Angular feels far more trustworthy and serious to me than Ember by many orders
of magnitude.

Neither though are even close the level of documentation and support and
widespread relevant reference apps as I was used to in the .net world (for
example), but Angular is the more solid choice in my opinion.

I would recommend Angular over Ember at this point in time unreservedly for
making actual applications versus websites.

~~~
flylib
really it seems like other people argue the other way, I only know Angular and
prefer it over Ember but I have legit heard that same argument coming from
Ember "Gurus"

~~~
HNJohnC
While everyone's needs and background are undoubtedly different I'm coming at
this from the perspective of developing business software that is used
globally for over two decades now and I have a pretty good handle on most
technology in this area.

I invested a decent amount of time now in both Ember and Angular (also Meteor)
writing a proof of concept app for the next major release of our business
software.

Frankly most of the negative comments I've seen here either way are low on
actual knowledge and high on axe grinding and emotional reactions.

It's interesting when you see a post here that is in your domain of expertise
and then see the reactions to it. It really makes you wonder about all the
other stuff that you might not know so much about and how much you can trust
what people post about those topics.

------
drdaeman
I found Angular to be almost trivial (even more trivial than, say, Ember, due
to being more explicit), except for a bit messily structured documentation and
the constant need to monkey patch or duplicate some internals to make them do
the right thing (like removing broken sanitization with ng-bind-html, etc.)

~~~
camus
Can you read and understand AngularJS source code? can you explain in detail
how does the digest cycle works ? and how datas are updated during this cycle
? if yes congratulation , if not , stop saying AngularJS is trivial ,it is
not, past the exemples on the homepage. Doesnt mean it's a bad thing , but
let's call things "trivial" when they are not.

~~~
rdtsc
Bingo. That is kind of my benchmark of "should I use this?". If code is too
arcane and hard to understand (especially when docs a slightly lacking) I
usually pass it up.

It could reflect on my density and stupidity (can't read code too well) but so
far I've had good track record.

I tried understanding and learning Angular.js but got lost in directives,
dollar-sign prefixed identifiers, services and other custom terminology.

One way to make sense of it is to look at the source, and that was pretty
painful.

Anyway so far it fails my smell test so I'll pass it up. Maybe later will
revisit.

~~~
drdaeman
Very good point. The terminology is exactly the thing that's (in my opinion)
is weird with Angular.

When I had a first glance on it, I didn't really get it. Only after several
hours reading the docs and experimenting with code I got what they were
talking about things became somehow clear (lots of aha-moments "ahh, the
service is just a fancy name for an angular-managed singleton, now I see...").

------
EugeneOZ
Yesterday on ng-torronto meetup I saw picture with graph of AngularJS learning
steps - it was like up-n-down function and I absolutely agree :) Many times I
felt "it's hardest thing" but after understanding all these things looks
pretty simple and powerful. Last most challenging issue was with recursive
directive (tree) - it took 2 days, but I understand directives much better and
other issues looks trivial now :) But I think it was not last puzzle :)

In my current web app I have a lot of work with collections, and each change
should be reflected on UI - without directives and bindings it would be hell.
With AngularJS even code is clean.

------
d0m
I love angular.. I use it more and more every week.

Ironically, angular speeds up lots of things, but also makes me unproductive
in others. Yeah, the end resulting code is usually shorter and cleaner. But I
waste so much time with hard-to-understand errors that it's often not time
wisely invested so far.

Still, I use it and as I become more proficient with it I expect these random
hard to find errors to slowly disappear. (Hey, if one time in my life I was
good enough to parse C++ template error messages, I can do it for angular ;-)

------
KaoruAoiShiho
"Hard". All of egghead takes maybe 3 hours to go through. And then you're
done. The the price of 1 lecture you're maybe 85% of the way there to angular
use.

~~~
ebiester
That's only true until you have to stray away from the happy path.

------
jlongster
My coworker just posted this today:
[http://f.cl.ly/items/3R3C3S3j2R2Z2U072E24/skitched-20130926-...](http://f.cl.ly/items/3R3C3S3j2R2Z2U072E24/skitched-20130926-143446.png)

Angular is certainly a platform. I'm usually skeptical about platforms like
this, but after using it for a while there are enough wins to justify the
weirdness.

------
gfodor
When I read things like this coming from experienced smart engineers a little
voice in my head starts yelling "incidental complexity." When I see engineers
who are building web applications discussing the nuances of type theory and
the complexity of Javascript frameworks I wonder how much time they have left
to solve the actual problems their users have.

------
wildermuthn
AngularJS is more powerful than any other Javascript framework. That's reason
enough to use it, unless the application you need to write requires more than
Angular offers.

------
ChikkaChiChi
I'm still not convinced that forcing the client-side to build DOM elements is
the right way to go; especially in the mobile sector where CPU cycles are at a
premium.

------
flylib
I didn't find it too hard to learn but there is like 10x way to do the same
thing, finding best practices, best library's, etc. is more time consuming

------
junto
That font is absolutely unreadable on an iPad.

------
ffrryuu
Yup, you need to know your stuff, I freaking love AngularJS.

