Rails is omakase; so is AngularJS

April 27, 2014 Nigel Pepper


DHH, one of the creators of Rails wrote a seminal blog post about Rails’ configurability and design to permit choice, while still presenting opinions on application structure. This sits well with my general sense of what’s right. I like things that don’t force me to make arbitrary decisions early on in development. This helps keep the app I’m building, simple and flexible to change at a later date. I like being able to make decisions at the point they matter, rather than because i’m using framework ‘X’. Want to use coffeescript? Fine, include the Gem, you’re away. Rspec instead of Minitest? Fine. You get the picture.

A thin veneer of JavaScript

Developing most web applications these days, involves at least some amount of JavaScript. There are a number of JavaScript frameworks available, with considerable overlap of feature set. I generally start from the position of ‘you don’t need a framework’ until a user-valuable feature comes along where it will be easier/clearer/more maintainable to use a framework whereby another developer will be able to pick up the codebase and, with knowledge of the framework used, be able to pick things up and be productive with minimum ramp-up time.

The project I’m currently working on is using ElementalJS and to date, it has served us pretty well. I like Elemental JS because again, it doesn’t impose strong opinions on anything other than the JavaScript under it’s control. It’s pretty simple to use. In essence, you decorate your markup with an HTML5 data attribute:

<div data-behavior="Mybehavior">

After load, ElementalJS will look for any elements with the data-behavior attribute and run the function named, passing in the element as a variable:

MyBehavior = function(element) {

We’re gonna need a bigger boat

We’ve recently picked up some stories which now demand some more advanced JavaScript behavior. Having been able to defer the decision to this point, me and my pair started taking a look a couple of options for a framework which would help us:

After some deliberation we arrived at Ember JS and Angular JS. We went with AngularJS. Why? Permissiveness. That’s not to say that Ember JS isn’t. Just on first evaluation, we found Angular to be a bit less tightly coupled. Being built around the principle of dependency injection, it makes it a pleasant experience test-driving the features you build. You’re not fighting the framework.

AngularJS’s architecture allows for nicely isolated, highly testable, modular design of JavaScript components and over the next few blog posts, I’d like to go into how we integrated Jasmine tested, AngularJS behaviors into the app.

That is all. Thanks for reading :)

About the Author


More Content by Nigel Pepper
6 Easy Steps: Deploy Pivotal's Hadoop on Docker
6 Easy Steps: Deploy Pivotal's Hadoop on Docker

Pivotal HD engineer Jun Aoki shares how to set up Hadoop with SQL on Docker by setting up Pivotal HD and HA...

Stand back! I'm going to try science.
Stand back! I'm going to try science.

For your entertainment. A vignette from my pre-pivotal days. I wake up, bleary-eyed, and roll out of bed. ...

Enter curious. Exit smarter.

Register Now