8 ms·

Using AngularJS at Localytics

152 points by abuggia 14y ago

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.)

znt 14y ago
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 14y ago
  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 14y ago
    why?
    - euroclydon 14y ago
      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/uTirEtNLahwJ https://groups.google.com/forum/#!msg/angular/hePiqQA-MCI/uT...
      - lennel 14y ago
        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.
holic 14y ago
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.
olegp 14y ago
We've had a similar experience at https://starthq.com 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.
eranation 14y ago
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 14y ago
  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.
deleted 14y ago
[deleted]
ilcavero 14y ago
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.
rashthedude 14y ago
Angular is just so sweet
monkeyfacebag 14y ago
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/ 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."
- superfresh 14y ago
  I second this. The videos are really great and are delivered in a way (short, to the point) that really helped me connect the dots in the areas where the Angular documentation wasn't sufficient. Especially the directive api, John does a great job there explaining isolate scope which was confusing to me for a while. Once you get it down you begin to realize how powerful Angular is.
- platonichvn 14y ago
  I agree. I've been going through his tutorials and they are great. Fire up sublime with node.js running as a simple http server and you can quickly follow along building simple apps that will get you up to speed.
- zapnap 14y ago
  100% agree. Single best angular resource on the web. Especially w/r/t his isolate scope explanations.
- mike_ando 14y ago
  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 http://www.youtube.com/user/johnlindquist
swah 14y ago
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?
- deleted 14y ago
  [deleted]
- axelf 14y ago
  The first one requires a global method. The angular one is a method that is tightly scoped and easy to test.
  - jonahx 14y ago
    This too
- avolcano 14y ago
  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."
  - d0m 14y ago
    I think it's because needs evolved. When we went away from tables to use stylesheets, the goal was to keep the same html but alter the presentation with css and js (for the animations). But now, it's not just about presentation anymore. Real applications are built and maybe it doesn't make sense to keep the html and throwing away css/javascript on a full-rewrite. Basically, the html we code right now is way more tied to the javascript that it once was. So, having them in two separate files doesn't make that much sense. Oh, and, you can use $('#show-help-link').click(showHelp); instead of click(function() { showHelp(); }); ! : )
superfresh 14y ago
> 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.
channi 14y ago
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 14y ago
  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.
lukeasrodgers 14y ago
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).
marknutter 14y ago
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.
feniv 14y ago
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-angular-js/ http://coenraets.org/blog/2012/02/sample-application-with-an...
- Narretz 14y ago
  This post is is so popular, my fork from half a year ago (very few additions), still gets starred approx. once a week.
camus 14y ago
i dont know, built this with angular : http://markme.alwaysdata.net 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 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.
sgt 14y ago
"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.
jcromartie 14y ago
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.
jaredgeorge 14y ago
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
joelhooks 14y ago
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 14y ago
I'm a fan of Knockout.js. Has anyone used both and can comment on their merits?
conradfr 14y ago
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 ?
delambo 14y ago
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 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 http://nytimes.github.io/backbone.stickit/#custom-handlers ... and an example of setting up a global handler for Chosen: http://jsfiddle.net/px6UP/28/ http://jsfiddle.net/px6UP/28/

152 points by abuggia 14y ago

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.)

znt 14y ago

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 14y ago
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 14y ago
  why?
  - euroclydon 14y ago
    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/uTirEtNLahwJ https://groups.google.com/forum/#!msg/angular/hePiqQA-MCI/uT...
    - lennel 14y ago
      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.

holic 14y ago

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.

olegp 14y ago

We've had a similar experience at https://starthq.com 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.

eranation 14y ago

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 14y ago
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.

deleted 14y ago

[deleted]

ilcavero 14y ago

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.

rashthedude 14y ago

Angular is just so sweet

monkeyfacebag 14y ago

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/ 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."

superfresh 14y ago
I second this. The videos are really great and are delivered in a way (short, to the point) that really helped me connect the dots in the areas where the Angular documentation wasn't sufficient. Especially the directive api, John does a great job there explaining isolate scope which was confusing to me for a while. Once you get it down you begin to realize how powerful Angular is.
platonichvn 14y ago
I agree. I've been going through his tutorials and they are great. Fire up sublime with node.js running as a simple http server and you can quickly follow along building simple apps that will get you up to speed.
zapnap 14y ago
100% agree. Single best angular resource on the web. Especially w/r/t his isolate scope explanations.
mike_ando 14y ago
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 http://www.youtube.com/user/johnlindquist

swah 14y ago

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?

deleted 14y ago
[deleted]
axelf 14y ago
The first one requires a global method. The angular one is a method that is tightly scoped and easy to test.
- jonahx 14y ago
  This too
avolcano 14y ago
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."
- d0m 14y ago
  I think it's because needs evolved. When we went away from tables to use stylesheets, the goal was to keep the same html but alter the presentation with css and js (for the animations). But now, it's not just about presentation anymore. Real applications are built and maybe it doesn't make sense to keep the html and throwing away css/javascript on a full-rewrite. Basically, the html we code right now is way more tied to the javascript that it once was. So, having them in two separate files doesn't make that much sense. Oh, and, you can use $('#show-help-link').click(showHelp); instead of click(function() { showHelp(); }); ! : )

superfresh 14y ago

> 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.

channi 14y ago

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 14y ago
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.

lukeasrodgers 14y ago

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).

marknutter 14y ago

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.

feniv 14y ago

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-angular-js/ http://coenraets.org/blog/2012/02/sample-application-with-an...

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

camus 14y ago

i dont know, built this with angular : http://markme.alwaysdata.net 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 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.

sgt 14y ago

"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.

jcromartie 14y ago

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.

jaredgeorge 14y ago

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

joelhooks 14y ago

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 14y ago

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

conradfr 14y ago

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 ?

delambo 14y ago

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 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 http://nytimes.github.io/backbone.stickit/#custom-handlers ... and an example of setting up a global handler for Chosen: http://jsfiddle.net/px6UP/28/ http://jsfiddle.net/px6UP/28/