

Why does Angular.js rock? - Foxandxss
http://angular-tips.com/blog/2013/08/why-does-angular-dot-js-rock/
Why does Angular.js rock? Is the first article on the new angular-tips blog!
======
jacques_chester
Angular is god's gift to programming bloggers. The documentation is so
famously patchy, contradictory and impenetrable that an entire cottage
industry of talmudic literature has sprung up around it overnight.

I've spent the last two weeks slicing and dicing the developer guide and all
the directly related API documentation -- this one-page demo is better than
the entire Angular tutorial. It also covers the most important 20% of the
Developer Guide.

Based on my current understanding, I'd explain Angular in a different
direction. Everyone starts with the binding, introduces a few inbuilt
directives, then possibly writes a directive.

I'd start with the $digest() loop, then build out to the runtime loop
generally, then explain how link()ing makes the $digest() loop possible via
$watch().

There is an enormous amount of Angular that is damn near liable to cause you
to scratch your head clear through to your grey matter unless you spend 15
minutes reading the $digest() source code and eyeballing the dev guide in a
few places. The docs _by themselves_ simply will not teach you how Angular
works, which rather falls short of the purpose of having documentation.

~~~
mgkimsal
"The docs by themselves simply will not teach you how Angular works."

Well said, and I agree, but I wonder why this is? There's some cred to be
gained by making and using something so impenetrable that only a select
handful of people 'just know' how something works, and everyone aspires to be
like them?

I've found plenty of people/blogs/sites telling me I'm doing angular 'wrong'
(and not just angular - other frameworks/libraries) but precious few people
can demonstrate a 'right' way to do things which actually accommodates real
world use cases. On top of that, what was canonical at one point is later made
obsolete via a single patch/push, but the blogosphere/google never quite catch
up.

Less an angular-specific rant, more an observation as to how more projects
seem to be heading. As I become one of the 'older' generation, I'm seeing more
younger devs (under 25, less than 3 years of professional experience)
embracing this code lifestyle, and seem to think it's great, and old fogeys
like me just 'can't keep up'. Maybe I can't, but perhaps if you'd document
your stuff a bit more, we could just _use_ the library instead of having to
read every single line of code, commit, watch for patches, finagle and beg to
get pull requests taken and used, and pray that the next point release doesn't
break everything. Obviously not all projects are like this, but it seems
there's a growing trend among younger projects to work this way. Or maybe I'm
just getting old...

~~~
ams6110
What these "younger devs" don't realize is that in most cases they are simply
reinventing stuff that has existed for years. Even today, the best JS MVC
frameworks only just provide the capabilities to build UIs that (for example)
were trivial in PowerBuilder 20 years ago.

The fact that it's considered "gee whiz" that you can enter a value into a
form field and have that value automatically validated and bound to an
attribute in a "model" shows how little we have really advanced.

Web UIs offer a lot in the way of visual styling and easy distribution... but
the actual building of apps hasn't really advanced much.

~~~
jacques_chester
I sometimes wonder what the world would look like if somehow it was all
hypercards or DCOM or OpenDoc or NeWS or just about anything other than a
simple document format painfully hammered into the shape of an applications
platform.

~~~
jfb
It's fun to run the counterfactuals, but ultimately, we go to war with the
lousy technology stack we have, not the mediocre one we want. I'm just
overjoyed that, thanks to Android and iOS, people are writing native
applications again.

~~~
SimHacker
There are known IKnowns: there are APIs we know that we know. There are known
IUnknowns: that is to say, there are APIs that we now know we don't know. But
there are also unknown IUnknowns: there are APIs we do not know we don't know.

------
sahrizv
I am just starting up web development and have decided to use Django for
backend. However, this Angular vs Ember comparisons have lowered my confidence
as I think whatever choice "I" make, will turn out wrong in the long run. Can
the experienced people here tell me what I should choose? I am fine with
either style of approach to HTML(template vs declarative) and I just want a
batteries included framework, which I can use in production, with no severe
limitations which may haunt me later.

P.S I am very new to HN and I cant do Ask HN posts :(

~~~
ams6110
_whatever choice "I" make, will turn out wrong in the long run_

Get used to that feeling if you want to be a web developer. You are in one of
the most "churning" areas of software technology. None of today's popular JS
frameworks were around even a few years ago, and in a few years time I expect
we'll see an entirely new set of popular frameworks.

Forget about the "long run." Pick something with a decently-sized community of
users and support. Learn it well enough to do what you want to do. Expect to
throw that away and learn something else next year. The era of actually
achieving "mastery" of any development tools is long gone, at least in the
world of web front-end development.

~~~
mgkimsal
" None of today's popular JS frameworks were around even a few years ago, and
in a few years time I expect we'll see an entirely new set of popular
frameworks."

You're right, but what needs also to happen is for many others to lose the
attitude that others are "doing it wrong" if they don't immediately intuit
every nuance of some new library that's 3 months old and was only written for
one use case, but touted as the latest hotness which suddenly you're forced to
use at work (for example).

I'm fine with understanding the churn and rapid pace - what I don't appreciate
is the attitude that just because everything's not 100% obvious to me that
somehow it's my fault, when there's little to no docs, no test cases, and a
README file that shows a trivial hello world.

------
at-fates-hands
The issue I've consistently had with a lot of the "frameworks" coming out
recently, is the lack of subject matter experts. It's like someone throws this
stuff together, makes an attempt to sketch out some documentation and then
just lets the developers have at it. Most of the developers who make videos or
tutorials simply do a few basic ones, and leave the rest up to the community
to figure out after that.

It would be nice if there was a team of developers who actually incubated this
stuff so they could write some decent documentation, along with a gamut of
examples from simple to highly complex so these frameworks didn't always
looked like a half baked rush job on getting it out.

I know our industry moves fast, but I think we'd be better served with a
complete set of documentation, with people who've been using these for some
time and who can lay out a solid road map for developers interested in
utilizing these frameworks.

~~~
ricardobeat
That's one of the reasons I prefer Backbone. It was born out of a business
project, still maintained by it's creator, and usage examples and production
apps abound:
[http://backbonejs.org/#examples](http://backbonejs.org/#examples)

------
mcgwiz
Certainly amusing demo.

What might actually have a chance at winning me over (having deep real-world
experience with and trust of other tools) is an account of more complex usage:

\- deep look at componetization/composition techniques,

\- how it plays with CommonJS/AMD/Harmony,

\- honest accounting of drawbacks, pain points, non-ideal usage scenarios,

\- explanation of all the magic, e.g. what's happening under the covers to do
data-binding, does the global namespace get polluted by DI features, etc...

------
MattStopa
I spent most of the last 4 months doing all my front end work in Angular. The
biggest problem I for me is that A) there are a lot of nooks an crannys and B)
the views end up being pretty ugly.

I've been doing more with Ember recently, and while some things are not as
easy, some other important things are much easier. On top of that the views
are easy to read. So at least for now I feel like Ember is better for me.

~~~
Alphasite_
i've found i prefer angular + ui-router to plain old angular routing, it makes
the views much easier to handle. That said, i could never put enough time into
ember to really understand it.

------
hayksaakian

        It works great but what if we want the input to have the focus when the page loads? jQuery right? We grab the input and we call the focus() method in it. NO.
    
        With directives we want our HTML to be as self-descriptive as possible so we are going to create a focus directive.
    

Or you could use html5's autofocus

[http://davidwalsh.name/autofocus](http://davidwalsh.name/autofocus)

and cut the JS

\-----

Otherwise great article, I'm really leaning hard towards angular now, over
ember

~~~
Foxandxss
True, but the directive will reach to those places where html5 is not a
welcome guest.

But to be sincere, I picked one thing to a directive, there are infinite ideas
but I needed one easily enough for a "hello-world" type of post.

~~~
hayksaakian
Is there some way to make a shim with angular, that only applies the directive
if autofocus is not supported

------
occam65
Once, just once - I want to read an article like this and in the conclusion
read "It doesn't rock. This framework just really sucks."

Anyway, I've been using Angular for a couple of weeks now, and happen to
really enjoy it.

------
overgard
So those are some neat features but I guess my overall question with all these
client side frameworks is: what problem are they solving? I see like these
lists of interesting features but I don't see a coherent message behind "why I
need this".

Usually I go seeking out a library when it does something that I really don't
want to have to do on my own, so what's the thing this is preventing me from
having to do?

~~~
forkhammer
Here's the brief answer, as I understand it: they're frameworks that provide
model-view data binding, ease data/presentational decoupling, and (in some
cases) provide single-page app (SPA) infrastructure in the mode of MV*. In
short, they're designed to tackle some of the common complexities that arise
when writing feature-rich multi-part SPAs.

You can do it all on your own, for sure, and I actually think that writing a
complex front-end-heavy application without anything but jQuery is a really
great way to show yourself the potential use of these libraries. It's not
really super hard to write decent, well-structured and segregated code... but
it does begin to feel, after a while, like you're spending your time hooking
up wires you've hooked up before.

At that point, you either write your own abstraction, or you go looking for an
abstraction that someone else (preferably smarter than you) will maintain.

~~~
overgard
That's just more buzzwords though. I mean, why do I even need model view data
binding? I'm not saying it's not nice to have, but I've written some pretty
complicated applications and I never really found data binding to be some sort
of killer feature. It's generally struck me as a great demo feature that in
reality I'll pretty much never use.

I guess I'd find these things more convincing if they showed me some sort of
problem they're solving by showing how awful it would be without what they're
doing -- because without seeing the actual problem they're solving, it kinda
strikes me as the work of architecture astronauts. It all sounds great on
paper, but when I go to use it I can't imagine even needing most of the
features this article describes.

~~~
forkhammer
Well, they are buzzwords, yeah, but it's important to note that buzzwords
become so because of their popularity and prevalence.

Why do you need model-view data binding? Emulating the responsiveness of
desktop apps, for one, or having live-update capability. I wrote an app
recently that let you add line items to an object, and the client wanted the
cumulative fiscal information to auto-update without reload. I'd agree that
the standard 'Hello, <your input content here>' example is overly contrived,
but what about a field that calculates and updates tax owing as you type?
That's not hard to write with just javascript, but when you do that about
fifty different times in an application, having a convenient data binding
mechanism is really convenient.

The other utility that I find quite convenient is DRYing up insertion logic--I
hate that I often have duplication between server-side templates for existing
objects, and some sort of client-side template for dynamically inserting new
objects. Rendering it all client-side makes my life a lot easier when I want
to add or change the surrounding template, and having the ability to do the
initial render with a minimum amount of boilerplate is phenomenally helpful.

Those are two very real, very frustrating problems with which I feel any one
of these frameworks helps a lot. I'm happy to go into greater depth if you'd
find that helpful or revelatory.

------
stevewilhelm
> Angular has a lot of built-in services, managing $http requests, $q for
> promises, etc. But in this part we are not going to talk about any built-in
> service, because they are more complex to explain and that belongs to a new
> article.

Statements like this worry me. Authenticated requests to REST API's should be
drop dead simple in any JS framework.

~~~
Foxandxss
Well, not that complex, I just tried to show the minimum things possible. My
first idea for a service was a twitter search but that implies an explanation
of $http and things related with it. Auth request are not that bad, it is
certainly not as simple as we want (but that happen in every client side
framework) but not bad. I want to cover auth in a future article.

------
caioariede
What are the alternatives to Angular.js that does not use this Dependency
Injection magic?

~~~
bsaul
Dependency Injection can really be done in a dark magic way (the java / spring
way), but after reading the source code, i can tell you angular.js way of
doing it is really not that dark. More importantly, is extremely easy to use.
No .xml file, no configuration file, just put the service in that function
signature, done (unless you want to minifiy, which means you'll also have to
add it as a string right next to it).

~~~
piranha
Well, in my option DI is one of the worst parts of Angular. It's a module
system which can't be integrated with anything. Doing something like
commonjs/amd would be much nicer:

app.controller('Name', function(require) { var $scope = require('$scope'); var
y = require('some-service'); });

And suddenly, no problems and no weird syntax!

~~~
joelhooks
Require is a service locator, so you are getting some of the inversion of
control benefits, but I greatly prefer the injections of the dependencies I
need instead of relying on a locator.

In practice the DI approach is very nice, and works consistently. It also
makes unit tests more straight forward.

------
Bahamut
I like this article - there is a huge need for content on how to do things in
Angular.

I personally love Angular quite a lot, and often help people in #angularjs on
Freenode - stop by if you ever have a question, a lot of us are helpful!

------
ErikAugust
Good breakdown of some of the useful built-in directives as well as an easy-
to-understand guide to creating a directive.

Top commenter is definitely right that Angular's own docs create a cottage
industry for bloggers and others willing to bang their heads against stuff
until they figure it out.

Just started an Angular directive that allows for reusable Flot charts:
[https://github.com/ErikAugust/flang](https://github.com/ErikAugust/flang)

I'll be adding the barChart directive as well as adding dynamic option setting
in the next day or two.

~~~
jacques_chester
There's something about those docs that seem to inspire blunt skull trauma
analogies. Me the other day, for example:
[https://news.ycombinator.com/item?id=6140406](https://news.ycombinator.com/item?id=6140406)

------
hoverbear
Good article, interesting site, terrible choice in background. Every time I
scroll it flickers due to the pattern.

~~~
Foxandxss
It came with the theme, I lack design skills but so far is not that bad and I
don't have any flickering...

~~~
mcintyre1994
Fair enough, I get the flickering too. Firefox 22 on Ubuntu 13.04 if it helps
at all.

------
throwa
Similar article about why emberjs rocks:

[https://news.ycombinator.com/item?id=6153917](https://news.ycombinator.com/item?id=6153917)

[https://kerricklong.com/articles/why-ember-js-
rocks.html](https://kerricklong.com/articles/why-ember-js-rocks.html)

------
devasiajoseph
This is actually the best and simplest introduction to Angular.js I have ever
seen. You rock too!

------
gedrap
A good summary, although I found a title a bit misleading - expected some sort
of comparison 'why it's better than XYZ'

~~~
Foxandxss
Hello, I am the author of the post.

I think that there is a lot of comparison out there to create yet another one.

On the other hand, I don't have a deep knowledge of the competence to compare
and I don't want to shot myself in the first post :P.

About the title, something can "rock" by its own.

Thank you for the comment :)

~~~
gedrap
I am not saying that it's bad that it's not a comparison, I love it!

Thanks for your post!

------
AydinSakar
great post!, keep going :)

------
avty
I love AngularJS

------
_random_
Because you have not heard of Knockout.js?

