Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Rails is omakase; so is AngularJS


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

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *

Share This