Rails & Spine.JS - Using The CoffeeScript Source
Our options for JavaScript MVC frameworks are numerous these days. While working on the third major rewrite of my personal bookmarking application, HomeMarks, I decided to learn Backbone.js. Thankfully a local friend of mine recommended that I try Spine.JS. I was immediately hooked!
Why Spine.JS?
Spine.JS is is authored in CoffeeScript and that is a big deal for me. I will never write raw JavaScript again, which I consider, the deprecated syntax. So a JavaScript MVC framework that is written in CoffeeScript means I can read the source, learn from it and even debug it if necessary. Sure, I can read raw JavaScript or just rely on documentation. But nothing beats reading source code. A practice I think good developers follow. So here is an example of the Backbone.js model source compared to reading Spine.JS model source and I think you will see the difference.
Source code legibilty is not the only reason to use Spine.JS. It is also very lightweight and requires no other JavaScript dependencies. Take for example Backbone.js which requies the use of Underscore.js and think for a moment why. Underscore.js makes mundane tasks in JavaScript like itterators and event binding much more friendly. But this is all moot when you are using CoffeeScipt's loops and comprehensions. And take my advice, CoffeeScript has so much more to offer. One of my personal favorites is the existential operator!
Coffee Time!
So, are you with me and want to try out Spine? Great! But do not rush in and use the spine-rails gem. Sure it gives you a nice way to require the Spine JavaScript files in the asset pipeline and some fancy generators. But when you break it down, there are better ways to get Spine's source files and who the hell uses generators? I mean, the only useful one is the initial rails g spine:new generator. Past the initial project setup, the spine-rails gem really does nothing but lock you down to an explicit version of Spine tied to that gem release.
I highly advise that new-comers to Spine start off with the spine-rails gem and its new project generator. Then quickly switch to just including the spine source using a git submodule. This will give you the benefit of using the source CoffeeScript files and tracking Spine's git repo which is getting good active development. So let's live on the edge and read some source. First uninstall the spine-rails gem if you have it and add the Spine project as a git submodule to your git repo.
$ mkdir -p vendor/assets/javascripts
$ git submodule add git://github.com/maccman/spine.git vendor/assets/javascripts/spine
This adds the Spine project to your vendor/assets/javascripts/spine directory. Which means it can now be leveraged by Rails asset pipeline using Sprockets. So if you had used the spine-rails generator above and had your spine requires in app/assets/javascripts/app/index.js.coffee, you would now be able to change what should have looked like this:
#= require spine
#= require spine/manager
#= require spine/ajax
#= require spine/route
To something like the following. Since the spine/src directory is where the source CoffeeScript files from our submodule above and Sprockets will render these just fine, it all just works!
#= require spine/src/spine
#= require spine/src/manager
#= require spine/src/ajax
#= require spine/src/route
So now you can easily update your Spine dependency using a simple git workflow with the added benefit that you can open up any of the source CoffeeScript files and learn Spine from the inside out. You can even change the source or put in console debugging to see what is happening and your application files will recompile via Sprockets on the next request.
Related
- Rails & Spine.JS - Using The CoffeeScript Source
- Rails & Spine.JS - Jasmine Testing Part 1
- Rails & Spine.JS - Jasmine Testing Part 2
- Pretty Console Logging With Guard::Jasmine & BlackCoffee