Angular doesn’t suck, you’re just holding it wrong.

First, full disclosure, I am a full blown recovering Ember.js zealot. Ember.js is an amazing framework for building ambitious applications. The problem that i’ve found with Ember (cli), Ampersand and even React is that they don’t play well with others. For the use case of building a backbone app, building an ampersand app, building an ember app or building a react app, each one shines as a stand out. The problem I run into is that I often want to write a Rails app or a Node app or a PHP with server side rendered templates.

Burn The Heretic

Its 2015, why the F*$@ would people render views on the server side. While this is going to open a whole off topic can of worms, its not that I always want to render server side, but sometimes it just makes sense. Plus we often end up support legacy applications or just want to go heads down using technology we are familiar with, Rails / HAML / Wordpress without bringing in a api overhaul or paying the cost of converting everything to client side.

AngularJS excels where jQuery leaves off. You can be massively productive at creating interactivity in your front ends using angular without changing anything about the way your app runs. You can get 2 ways data binding, move your truth out of the dom, and get a ton of well written angular modules to bring your interfaces to life without any real technology buy/lock in.

The same code will basically work between Rails, PHP, Node, insert server side technology here. It works with ERB, HAML, etc because your templates are just defined in your existing html.

Square Pegs Don’t Fit in Round Holes

First of all stop thinking of Angular in the same terms as Ember.js, think of Angular as Dom sugar to modernize your server side rendered application. Angular can be used as a cleaner and more capable jQuery.

Do: Use it to build islands of interactivity
Don’t: Use it to build Single page web applications

We need an Angular.js

Every time we reach for javascript we aren’t going to want to write our entire application in javascript. In a world where build tools can be a bit over kill for some applications, angular js is very accessible.

Unlike the “happy-path” of many of the other javascript frameworks on the market, angular doesn’t ship with a cli or a prescribed grunt/gulp/brunch/npm/bower/yeoman build stack.

As a rails developer I was able to get up angular up and running in a matter of minutes. I included the angular-rails gem in my Gemfile, added it to my application.js manifest and wrote my first angular class.

Writing the templates just made sense, I took my existing haml view and added the ng-class attribute to my page container and the mustache-esque templating spring to life. I was able to issue a few simple promise based ajax calls using the included HTTP library and my page was populated with data. Updating the page was as simple as modifying a few scope variables. What once would have taken hours with jQuery now took minutes. My data was bound to real POJSO and there were no strage router quirks, data persistance issues or blank pages with no errors, it just worked.

Angular is great to me because it reminds me of the simplicity of writing vanilla javascript while still having the power of a modern framework.

The baby and the bathwater

Does angular have some quirks that may not teach the best practices to junior developers. Maybe? This is such an odd statement. Personally I think this is comparing apples and oranges. Its a bit like saying Object oriented programming teaches bad habbits to junior developers who may work with functional programming languages some day. When I started writing Erlang/Elixir I brought over a ton of bad habits from rails, does that mean its bad to teach junior developers rails? Probably not. These “habits” in rails are considered best practices, in Elixir they are considered sin. Its not fair to say because angular has one way of build one type of program, that it teaches bad practices when building a different type of program in a different frame work.

The right tool for the job

I think too often as developers we try to use the wrong tools for the job, either because they are the hip new tool or because they are the tool we’ve become comfortable with. This is evidenced by writing web applications in rust and go while developing system agents with ruby. We need to become polyglots, spend less time shoe horning, and actually focus on cranking out quality software with the best tools for the job, rather than sitting around debating how bad blenders are at making coffee. I suppose baristas should stop learning to use blenders.

Send all hate mail to: justin@kohactive.com or shout loudly at me in all caps on twitter: @j_mcnally