Going Angular

Lately at work I've been doing a lot of research and not a lot of blogging. I am going to make an attempt over the course of the next few days to update my blog to reflect the massive amount of new stuff my brain has absorbed over the past few weeks. h2. Background The first thing I want to touch on is javascript. Our current mobile application is on the Apple App Store and the Android Market. What most people don't realize is that 90% of our code is javascript and html. 90% being a number solely fabricated in my mind, but I assure you the guts of the app is in fact JS, HTML and CSS. This can be accomplished with the help of projects like "Cordova":https://cordova.apache.org/ and "PhoneGap":http://phonegap.com/ I won't go into detail to explain how these products work or how they are different, since the focus here is on the JS side. We had a very loose code base that was mostly hand-written from scratch with the help of some mobile libraries like "iScroll":http://cubiq.org/iscroll-5 and "Intel's App Framework":http://app-framework-software.intel.com/, which continues to get better and better. Our application is very data-driven and so it completely centers around grabbing information from web services and displaying it to the users. The javascript code was a little bit sloppy since it was originally written very quickly, with many rewrites of huge chunks of the code, and not much refactoring was done. There was no unit testing or any way to check for broken code when big changes were made. This was gradually slowing us down over time. This combined with a poor code organization and overall bad practices left me craving for some kind of structure so I went on a one-week journey to explore alternative, _structured_ solutions: javascript frameworks. h2. Possible solutions I won't go into detail about all of what I found but it all led to a showdown between "AngularJS":http://angularjs.org/ and "Backbone.js":http://backbonejs.org/. We chose Angular. If you want to see about other options check out "TodoMVC":http://todomvc.com/, a site dedicated to writing a todo app using javascript MVC libraries. h2. Why Angular? We chose angular _because_ the application was so heavily dependent on web services and Angular made this a breeze. In addition to the awesome support by Google and the rest of the community, the dependency injection and what appeared to be a wide enough adoption rate. AngularJS provides a lot of free functionality, and often times there is a solution available to common problems in the form of a community contributed AngularJS plugin. Some examples of AngularJS plugins: * Slide-In menus for mobile are possible using "angular-snap":https://github.com/jtrussell/angular-snap.js, an AngularJS wrapper to "Snap.js":https://github.com/jakiestfu/Snap.js. * Mobile device touch gestures are possible with "angular-gestures":https://github.com/wzr1337/angular-gestures, an AngularJS wrapper for "Hammer.js":http://eightmedia.github.io/hammer.js/ h2. Angularing So AngularJS by itself can be used just like a library, but like I said I was craving structure so I hunted around and found a couple of solutions. h3. angular-seed AngularJS references the "angular-seed":https://github.com/angular/angular-seed project in their documentation. They created it and it is highly recommended (by them). I created our first prototype using angular-seed. It was great but there were a few things I didn't like about it. Here's a list of what I liked and hated: h4. Cons * Initial setup requires editing multiple files * Default controller/services/filters/directives separation is hairy * No build process h5. Initial set up requires editing multiple files Multiple files need to be edited for the initial set up (things like your project name and the module names and so on) h5. Default set up for controllers and services is hairy The default configuration puts all controllers into a single @controllers.js@ file. The same thing is done for @directives@, @filters@, and @services@. They claim this is because most applications are small enough to pull this off. I call bullshit. I think it's sloppy and I don't like it. Of course you're not locked into using that style, but separating things out _is_ an extra step, after all. h5. There is no build process I forgot to mention before that I was looking to have a build process. The type of thing that would allow me to lint my code, check it for errors, minify it and compress it, and have everything set for deployment. This isn't really a problem with AngularJS, it's just that out of the box it is missing. h4. Pros * Project skeleton organizes everything for you (it's pretty well organized) * Fast kick start to your project * Works out of the box * Comes with sample unit tests out of the box! I won't go into details about the pros --- but trust me, it's good! (Even though I did complain about it) h3. Yeoman Building with Yeoman is another option, but requires a lot of dependencies (on the development side). So what is Yeoman? "Yeoman":http://yeoman.io/ is a "web scaffolding tool." Fancy mambo-jumbo aside, Yeoman is a project creation tool. It will create your project and help you manage it. It is a commandline tool so you cli junkies are gonna love it (_probably_). Yeoman uses several other tools, namely "Grunt":http://gruntjs.com/ and "Bower":http://bower.io/ to give you a full development work flow. If you are unfamiliar with these, let me give you a quick introduction. *Grunt* is a build tool, you can think of Grunt as the GNU @make@ of javascript. *Bower* is a package manager. It will download packages for you, tracing their dependencies, and dump them out on to your filesystem in a directory (default is @bower_components/@). Here's a quick guide I found to "Automate AngularJS With Yeoman, Grunt & Bower":http://newtriks.com/2013/06/11/automating-angularjs-with-yeoman-grunt-and-bower/, it's not my favorite but I can't find the link that I liked best at this time. h4. Cons * You have to install A LOT OF STUFF to get started * Learning what tools serve what purpose and how to use them * The default linter is @jshint@ (I prefer @gjslint@ for maximum control: you can suppress any linter message you want) * The template code style might not agree with your linter out of the box h4. Pros * Handles project creation (adding controllers, models, etc is all automated) * Has a build process (minifies your code and automatically makes appropriate replacements for you in your files) h2. Conclusion AngularJS is awesome, how you implement it is up to you. I don't have too much experience yet with the Yeoman method since I didn't find it until after prototyping using angular-seed. However, I do have a lot of faith that Yeoman is a good solution and I like the way it handles things for you. Next time I will try to publish some guide of my own with some sample code. I've also started learning objective-c and I will start posting on that as well.