

Using AngularJS at Localytics - abuggia
http://www.localytics.com/blog/2013/angularjs-at-localytics/
This is the story of how we rewrote our Backbone-powered web application in AngularJS, using nearly half the lines of code.  (It is a love story.)
======
eranation
Anyone thinking they made a mistake using Backbone, please read this: I've
been using backbone for about 1 month, refactoring a huge jQuery spaghetti
project, and I have few observations:

1) If you have a new project, I would go with Angular (or even Ember if you
are from a Rails stack)

2) If you want to refactor an existing one, check Backbone, it might be a bit
less causing a rewrite rather than a refactor

My tips if you still choose backbone:

\- learn it first inside and out, spend at least 2 days doing any tutorial out
there, even if it's a few dollars (code school, peepcode, tutsplus etc)

\- make sure you learn 1.0, older examples might be confusing

\- read the backbonejs.org documentation from start to end, and read the
annotated source, especially read the FAQs and also read the github issues,
jashkenas (the author) is sometimes responding himself

\- I tried to avoid any plugins at first (no Marionette, deep model, BB-
relational etc) if you see you need too many plugins, just ask youself if it's
worth it, you might want to give Angular (or even Ember) a chance. I found out
that for anything that looks hard, there is a way to do it in Backbone the
"backbone way"

\- Last: remember that Backbone is simply helping you get code from the form
of document on load God function with tons of event listeners, that trigger
ajax calls, that trigger dom manipulation, to about the same code, but in
models and views, so you can make sense of all of it, that's all.

Yes, you need to clean up your listeners, and when using the 1.0 listenTo and
stopListening (which are automatically called when you remove a view or
destroy a model) then you are going to be ok with the zombies.

Backbone taught me a lot of JavaScript, it was more perhaps harder than
Angular but the code is readable to anyone without even learning backbone, it
just makes sense

so don't expect Backbone to do any magic, it doesn't, but it is still a very
relevant and valuable utility library, and I think it's a must have step in
any front end developer's life to do at least one BB app before moving to
Ember or Angular (just my humble opinion)

~~~
pixel67
Backbone has taught me a lot too, I like that it doesn't do any magic. Angular
is pretty amazing though at how simple it is to do things with, I'm a bit
worried about the magic part. What happens when things start growing and the
magic breaks, do you have to read the code base to figure out where it went
south? I started playing around with ember too. It's a bit tricky, I found I
had to compile it to get it to work, the starter kit wasn't cutting the
mustard for me.

------
monkeyfacebag
For those commenting on the poor quality of Angular's documentation (a
complaint I share), check out John Lindquist's videos at <http://egghead.io/>
. They're not comprehensive, but John spends a great deal of time explaining
the nuances of directives, especially isolate scopes and transclusion and his
explanations are clear and intuitive. Prior to finding John's videos, I
watched all of the "official" Angular videos which I found more often
frustrating than illuminating, but John set me straight. Can't recommend
enough.

And if you're struggling to ramp up on Angular, I would recommend sticking it
out. The learning curve is steep (or is that gradual?--I never understood this
analogy), but once it clicks, your productivity will go through the roof.
Angular has redefined what I mean when I say "rapid prototyping."

~~~
mike_ando
I couldn't get your link to work, but it appears that his egghead.io videos
are on his youtube channel.

<http://www.youtube.com/user/johnlindquist>

~~~
aespinoza
Mike, thanks for the link. I just asked about egghead being down.

------
swah
_We used to write things like_

    
    
        <a href=”#” onclick=”doSomething()”>
    

_Then we realized it was bad to couple presentation and behavior, so we made
our Javascript unobtrusive, keeping our templates clean. But now we’re back at
it again, writing_

    
    
        <a href=”” ng-click=”doSomething()”>. 
    

_Have we learned nothing?_

\---

This seems like a good point that I can't refute - anyone?

~~~
avolcano
Honestly, there's not a huge amount of difference between

    
    
      <a href="#" id="show-help-link">Show Help</a>
      <script src="text/javascript">
        $("#show-help-link").click(function() { showHelp(); } );
      </script>
    

And

    
    
      <a href="#" ng-click="showHelp()">Show Help</a>
    

I mean, HTML has behavior in it. A link in itself is "behavior": when you
click this tag, go to the page defined in the src attribute. So, as the author
says, it's not really a bad thing that templates have behavior in them. In
Ember.js, for example, you have an {{action}} handler that is essentially the
same as ng-click - "run a function on the controller when this is clicked."

~~~
sgt
You don't need the src="text/javascript". Only <script> ... </script> is
required.

~~~
avolcano
Heh, I meant to specify "type" and not "src", but you're right regardless.

------
marknutter
My angular story:

My team was at a similar crossroads a few months back when trying to decide
which javascript framework to pick for our mobile app. It came down to
Backbone, Angular, and CanJS (because we had previously used JavascriptMVC on
a project). It really came down to Backbone vs. Angular and we were leaning
heavily towards Backbone. We all built demos using each of the three
frameworks.

I was the Angular advocate and after having experienced incredible joy
creating my demo I was desperate to get the rest of the team on board. After
much debate we were leaning towards backbone, until that is, I asked "how
would you go about making sure your views are updated and your forms
validated". After we walked through the work that would be needed to be done
maintaining the view state in real-time on a backbone app, and a few other
examples like retrieval of form data or validation of forms, it became clear
we'd need to write a lot more DOM manipulation glue-code using Backbone than
we would with Angular.

In the end, this was what pushed us over to the Angular side. The focus on
testing and the dependency injection throughout was another huge selling point
for us. And frankly, it wasn't clear to us how a Backbone app should be
structured. In fact, that variability appeared to be one of the main selling
points of the framework but it ended up paralyzing us with choice. Being first
time Backbone developers we weren't sure we could ever feel confident knowing
we were following best practices.

------
channi
My experience with Angular.js was not that good though. May be I am real dumb,
I can't see anyone with similar experience. I was totally frustrated with the
amount of things I had to handle to bind my backend API. And also there were
several issues like $scope.variables going wild. In short, it was a total mess
in my case. I rather decided to roll out with Jquery instead. The code got
totally cluttered I accept, but Angular.js frustrated to the point that
'elegant code' was least of my concerns, I just wanted to finish it somehow
and run away and never look back.

~~~
nek4life
Were you mixing dom manipulation into your controllers? That can make things
go haywire because they happen outside the standard compile and link phase.
Sometimes it works and sometimes it doesn't. Using the directives (which I
admit are super confusing at first) can alleviate this issue because they are
executed in the normal Angular update cycle so everything happens in the
correct order.

------
delambo
Stickit author, here. To be clear, stickit will not make your "zombie views
grow fatter" or contribute to any memory problems. In fact, stickit cleans up
all of its model and view bindings automatically on view.remove(), and
provides an optional api for manual cleaning view.unstickit().

The blog author's problem was a brief bug that was introduced and fixed
between releases for the rare use case when a data-bound view is re-rendered.
We fixed this problem and the author confirmed that the patch was "working
great."

<https://github.com/NYTimes/backbone.stickit/issues/66>

So even though the problem was fixed for the blog author before he moved onto
angular, he still claims that stickit causes memory problems. I guess a false
claim like that makes the story of moving to a new framework more
entertaining.

Another claim from the blog author is that stickit makes it hard to use third-
party plugins like Chosen. Around the same time he filed the github issue, we
were finishing and getting ready to release "handlers" and a new "initialize"
binding which give you the ability to create global handlers for setting these
kinds of bindings up. More on handlers here:

<http://nytimes.github.io/backbone.stickit/#custom-handlers>

... and an example of setting up a global handler for Chosen:

<http://jsfiddle.net/px6UP/28/>

------
znt
I decided to use AngularJS on a side project of mine, after considering
Backbone and EmberJS. I am not a JS expert, but I am pretty sure AngularJS
will be an industry standard in a few years.

~~~
lennel
I think as mobile becomes more dominant angular will have to find a way to
work tighter with the closure compiler in advanced mode (or something akin) to
remain relevant.

~~~
nicklovescode
why?

~~~
euroclydon
I'm not sure why the OP links advance compiling specifically to mobile. It's
good to have smaller, faster code on any platform that isn't quad Xeon with a
fiber connection.

The Closure ecosystem has their own templates (soy) which are compiled in
Advance Mode (with renaming) by the Closure Compiler. It's not possible to do
that with Angular attribute's which reference JS names.

See this conversation about Angular support in Closure:
[https://groups.google.com/forum/#!msg/angular/hePiqQA-
MCI/uT...](https://groups.google.com/forum/#!msg/angular/hePiqQA-
MCI/uTirEtNLahwJ)

~~~
lennel
you touched on several of the problems i forsee. angular parses templates
client side, which is expensive IMO, smaller better optimised code with proper
dead code elimination leads to a faster experience. as for mobile, i use it as
the final use case, where the bad decisions which you make get amplified the
most.

------
feniv
I've been using AngularJS for a few months on a side project of mine and it
greatly helped move a lot of the code complexity to the client side. Hooking
it up with a REST API was simple and got rid of almost all of the server side
rendering.

Here's a particularly useful sample app, implemented in both Angular as well
as Backbone.

[http://coenraets.org/blog/2012/02/sample-application-with-
an...](http://coenraets.org/blog/2012/02/sample-application-with-angular-js/)

~~~
Narretz
This post is is so popular, my fork from half a year ago (very few additions),
still gets starred approx. once a week.

------
superfresh
> _Working with isolate scope and transclusion is tough, and Angular’s
> documentation on the subject doesn’t make it easier. We found that before
> jumping into writing an ambitious directive, it’s best to start by not
> writing a directive — just using normal templates and controllers — and then
> roll that code into a directive once you really figure out what your
> requirements are, or once you start repeating yourself.._

Directives are, IMO, the most powerful parts of angular. They're also the most
confusing. OP makes a great suggestion here that I'd recommend as well: Start
with a normal template & controller then refactor into a directive later. In
my experience, I've found that it's been useful to focus less on the DOM
manipulation that needs to take place and more on the where the data collected
needs to flow. In this way the directive just becomes the "glue" between a
tiny area of the DOM and a parent controller and/or scope.

I guess you could liken them to the behavior/logic you'd have in a backbone
view? That may be a stretch though. Powerful nonetheless.

------
olegp
We've had a similar experience at <https://starthq.com>. One thing we noticed
when writing directives is that it's often faster and easier to implement them
from scratch rather than wrapping a jQuery plugin. Also, we've pushed a couple
of fixes upstream and had them appear in a stable release within a few weeks
due to the quick release cycle.

------
conradfr
Love AngularJS. My grips so far :

\- Directives : I'm no JS ninja so even after those egghead.io I'm still lost,
but it gets better !

\- jQuery : Angular kinda want to kill it whereas I think it should play nicer
with it, especially for plugins. AngularUI jQuery Passthrough (or custom
directives) should not be necessary IMO.

\- Expressions : they are powerful but there is almost no documentation about
them and I feel like an idiot sometimes. Thank god for Stack Overflow ...
(where in the Angular doc can I learn that I can do ng-click="[action_1,
action_n]" ?).

\- Views helpers are usually put in the controller. That doesn't seem the best
approach, or maybe people put them in a service and inject it in the scope
from the controller ?

\- Providing initial data : I usually put data in javascript variables and get
them in the controller and assign them to services or the scope. Is there a
better way ?

------
sgt
"Directives are hard. Working with isolate scope and transclusion is tough,
and Angular’s documentation on the subject doesn’t make it easier. We found
that before jumping into writing an ambitious directive, it’s best to start by
not writing a directive — just using normal templates and controllers"

I have the same experience. I also tend to do the occasional DOM manipulation
from the controller, using jQuery. I know it's frowned upon in the Angular
community, but it at least allows me to experiment and, as the quote implies,
figure out what I want before I know exactly what I need.

That being said, I'm starting to use directives more and more, and they are
certainly a powerful tool that cannot be ignored if you are going to build an
Angular app.

------
jaredgeorge
Our team in finishing a project to refactor a custom form builder in our app
(similar to WuFoo) and our struggles sound very similar. We are adding plugins
like Backbone Relational to fight with issues, and fighting issues with the
plugins... And in fact, our tech lead has actually forked Backbone (still
unsure as to the exact reason). At any rate, we have shattered (what used to
be) a ~1,000 line jQuery/JavaScript file into nearly 130 individual fragments
of models, views, collections, templates, and helpers. Throw RequireJS into
the mix... We can't be Doing It Right (TM), can we? Or are we, and I just
don't get it?

[edit] spelling

------
lukeasrodgers
Nice, thorough write-up. For people considering Backbone, though, I will say
that I've written several non-trivial Backbone apps, and negotiating the form
view re-rendering problem is not that difficult and certainly does not require
an extra data binding library. Also I've had no problem integrating the Chose
plugin into Backbone apps.

Dealing with deeply nested views can still be a bit of a headache, but I
prefer the extra control over view rendering that I get with Backbone vs. soem
other frameworks (I have no experience with Angular).

------
holic
Good write up! I've been on the look out for examples of larger migrations
from Backbone to Angular. I'm about to tackle one myself, but wanted to make
sure it was the right decision before diving in.

------
ilcavero
I have been working in the past few months with angular and have nothing but
good things to say other than complaints about the docs and the complexity of
directives/transclusion. He doesn't mention it but the coolest thing for me so
far is the transparent use of promises in the templates. The unit testing
support with testacular/karma is good as well, but I'm not sold on the e2e
testing with angular-mocks, would like to hear more on this subject.

------
jcromartie
Is it just me or is Backbone just not that hard? I don't quite understand
their data binding situation. You should not need to look at the DOM for
elements with specific IDs, unless you have truly singular views at the top
level.

I get the feeling that their form re-rendering headaches had to do with parent
views that were listening to unnecessary events, like a collection view that
listens to individual model events.

------
joelhooks
We've got a very large app built on Angular, and it has been a real pleasure
to work with. The directives are the killer feature for me. There are some
definite esoteric bits that can be puzzling at first, but after you crest the
hump it is rad. I love it.

------
tlrobinson
I'm a fan of Knockout.js. Has anyone used both and can comment on their
merits?

------
rashthedude
Angular is just so sweet

------
camus
i dont know, built this with angular : <http://markme.alwaysdata.net>

it works , i like the DI stuff though i always used my little lib for that
before( <https://github.com/Mparaiso/Pimple.js> ) .the 'dirty checking' always
felt like a hack , i'm glad Google is working on it with Object.observe. as
for the code inside the html, since it is a "scoped" eval with its own dsl
it's fine.

But i still use backbone especially for games and non dom related apps.

what matters is choice , and angular is still light weight compared to beasts
like Sencha.

