
On launching AngularJS 1.2: what we learned, what we're changing - cleverjake
http://blog.angularjs.org/2013/11/on-launching-angular-12-what-we-learned.html
======
adamtulinius
I really really want to try loving AngularJS, and to some extent i really do
-- but when I need to look at the documentation, I feel like shedding tears.

Angular-team: You have an awesome product. Please fix your documentation, and
include examples usable with angular-seed, instead of the standalone-examples.

Has the documentation improved with 1.2?

~~~
mackwic
Documentation got waaay better these last weeks. Hope that continue.

About examples, we can't point enough the awesome work of the Angular-ui team.
I think their code is near the state of the art of Angular. But yep, a big
complete applications using Angular in which we can digg into would be nice.

In my experience, Code Scalings THE problem you got with your real world
application. Restangular helps. A lot. Services are not that useful, Factories
even less (but when they are, it's a neat feature), and Providers are simply
something internal that we can optionally use if we want do some meta-meta-
programming (factories do the first meta).

I hope the guideline for the next release will be to get rid of the over-
engineering that makes everything complex when you need to do something UI-
dynamic (ever try to attach dynamically a tooltip ?). Sometimes Angular just
go on your way and don't want to move.

The things I would want to be changed:

\- Remove Providers. that's just redundant with factories, with the only
exception as some complex internals we shouldn't use anyway

\- Remove $rootScope. It's an internal thing that should not be used.

\- Make $q better. It's a pain to use. Really.

\- Better control to digests (monitoring, postponing mostly)

\- Angular binding with CSS would be awesome. But it needs some work to make a
clean separation.

\- Directives. Seriously: the way to declare them really should be changed.
Returning this starnge object, what the point ? What about Directives
Factories for all the multiple ways to declare them, and in last resort _only_
, using the weird object when you need that fine grained control. Mixing all
together like the current state is not viable.

~~~
aidos
Could you explain a bit more about the tooltip issue you've mentioned? I'd be
interested to explore to understand what the limitation is and how I (or
others) might approach it.

I'm not sure I agree with all of your comments.

I find that services are relatively essential building blocks for my
applications.

Providers are there so that you can preconfigure your modules. It's a
legitimate use case. Take Restangular, for example - it's so useful to you
because it's a provider that you can configure for your app.

I can see how $rootScope could be perceived as code smell but after examining
how angular uses it internally I'm ok with the way I use it.

Directives are confusing the first time you see them. You need to see a few
examples. Though I don't think there's a problem with the api for declaring
them. There's a lot to configure - it's mostly optional, but you may well need
all of it eventually.

Angular gives you a framework to build on. You can create really amazing
components that are totally reusable on your other projects. Sometimes they
come in the form of directives, sometimes they're other types of module. Often
when you start abstracting that out you'll need to get a bit closer to the
metal. Angular provides an api for you to work with in those cases and it's ok
to take advantage of that.

~~~
mackwic
> Could you explain a bit more about the tooltip issue you've mentioned?

Say that you have a dynamically generated form where an input should display a
tooltip only in specific cases.

Using tooltip="" will not do the trick, you have to do some sorcery to attach
dynamically your tooltip, aKa: using compiler in your controller to replace
dynamically the DOM region with the DOM elements returned by $compile and
jQuery.

> I find that services are relatively essential building blocks for my
> applications.

But they doesn't help much against the issue of feature scaling.

Some UI logic just can't be factorized. Some other data handling is to
specific to be re-used elsewhere. In a large business application, logic is
poor but corner cases are legion. We made the choice to keep our specific
logic near the place they are used against using services because that doesn't
add any value.

> Providers are there so that you can preconfigure your modules

Again, thats what the rest of the world call 'a factory'. You can perfectly
imagine a Factory that register in $injector it's instances. IY think Provider
should stay something internal and not be documented as a feature everyone can
use. It's not.

> I can see how $rootScope could be perceived as code smell but after
> examining how angular uses it internally I'm ok with the way I use it.

I am too. But I don't want anyone else than hackers to use it.

> Directives are confusing the first time you see them.

They are confusing because everything is blend together. Separate the
different use cases and everything will be simpler. Even if it's the same
internal thing (that you can use directly if you need). My point is that if
you provide different handlers, noone will ever fear the directives.

> You can create really amazing components that are totally reusable on your
> other projects.

If only...

In the real world, there is no way my current employer will accept I'll reuse
his code for my next project. Only FLOSS libraries can do that.

------
nemothekid
I'm currently working on a project with Angular right now updating a current
product largely built on Backbone to Angular.

Overall I'm super impressed with it, when you know what to do its almost like
magic. Callbacks, events? What are those? But like others in this thread - I
wish the documentation was better - atleast with examples on more of the doc
pages. It has been improving however.

------
ghostdiver
I can't do history.back from this website. Was it made with AngularJS?

~~~
defen
It appears to be hosted on blogger and does not use AngularJS.

~~~
danabramov
I can't believe Blogger still does not change this redesign. It lags when I
scroll _text_. It has this silly layout dropdown. The top bar obscures
content. Why.

------
moomin
Nothing about the value of accurate documentation, then.

~~~
scotth
I've been deep in the docs for the past couple months, and I have never found
them to be inaccurate. A bit sparse sometimes, but on the other hand the
source code is very well commented. Between the two you can find your way
without too much effort.

~~~
johnbm
There are two kinds of developers... those who want a single framework that
will solve all their problems and which they never have to look into... and
those who like to understand one or more abstraction levels below where
they're actually working.

Digging into a framework's source code is natural to the latter group, but
utterly alien to the former.

Documentation written for the latter group describes mechanisms, design
principles, APIs, etc. The former group instead requires examples and step by
step tutorials.

Both will call documentation terrible if it doesn't conform to their
expectations.

~~~
cheshire137
You described that nicely. I didn't realize there was such a split, but I'm
definitely of the former group. Ugh, I just want to write my own cool stuff
and understand it. If I wanted to write and understand the inner workings of
AngularJS, that's what I'd be doing.

~~~
johnbm
Until you need to do something with WebGL and you realize you have no idea how
to write fast code because you're more than a dozen abstraction layers removed
from the silicon.

------
pramodliv1
I'm pretty new to angular. Which medium/large-scale open source project do you
recommend to learn writing idiomatic code.

------
Xelom
I only see a blank page. Did they learn nothing?

~~~
Narretz
I see a blank page because the blog is hosted with blogger and that's blocked
by my firewall.

~~~
oomkiller
Just curious, why do you block Blogger?

~~~
taude
willing to bet it's his corporate firewall that blocks it at work...

