Saturday, May 25, 2013

Rails as a single-page app development environment

Why?

TL;DR: Rails is a great tool to set up a development environment for single-page apps, particularly if you already know the framework. Skip to How to get started.

When writing single-page apps using frameworks like Backbone.js or Ember.js, I found myself frustrated by the lack of development environment, coming from the Rails world where a lot of tools are provided to keep your code clean, organised and optimised.

I tried tools like rake-pipeline and Yeoman, but ultimately I was disappointed, craving a tool that would do just like Rails with its assets pipeline, but without the actual Rails stuff. Until a few days ago, my friend and colleague Kevin interrupted my rant: "Why not Rails"?

Here is what Rails can do for you, and I will show you how:
  • Splitting code into multiple file (readability): There is one eyesore I find common to all demos and tutorials of JavaScript frameworks: app.js. Somehow, learning to build a single-page app always seem to include cramming all of your code into one huge, disorganised, unmaintainable and overall disgusting JS file.
    You can't reasonably work like that, at least not for long. I want each model, each view, etc in a separate file.
  • Using SASS and CoffeeScript: Hardcore JS developers might argue against CoffeeScript, but I can't possibly go back. And I don't think anyone can argue against SASS. It's just awesome.
  • Joining and compressing JS/CSS (performance): If you split your JS and CSS files and then include them all in your app, you need to stop. Each additional link or script means an additional requests, which means more delay before rendering your app. And obviously, your assets need to be minified before hitting production.
  • Updating librairies (maintainability): All the common librairies and frameworks such as Backbone.js, jQuery, Bootstrap and Foundation are available as Ruby gems, which makes installing and updating them a lot easier than browsing all the websites regularly and downloading the new versions.
  • Watching for changes: In development mode, Rails will recompile your assets automatically if you change them, so you can skip between your code and your browser without stopping by the console first.
But isn't it overkill to use a complete web framework just to manage your assets? Maybe a little, but who cares? It's not like your Rails app is ever going to production, so nothing changes on that front, and Rails is as easy to install as the other tools you might find like Yeoman or Compass.

How?

I will assume you have Rails installed, and I will try to make this easy to follow for non-Rails developers, but you might want to read about the asset pipeline if that is the case.

At the time of writing, Rails 4 (RC1) still has some bugs affecting the assets pipeline, so I strongly recommend you stick to Rails 3. I tried to make this Rails 4 ready, but I might have forgotten some details. And besides, we won't use any of the cool new stuff from Rails, so there is zero advantage to living on the edge here.

First, let's create a new Rails app. We add flags to exclude stuff that we won't need, although it wouldn't hurt if it was there. Our built app will go in the public directory, so let's clean it out.
Next we open app/assets/javascripts/application.js, and remove what we don't need. Delete these lines:
We want the resulting files to be called application.js and application.css, but by default Rails adds a digest to that name. Change this line in config/environments/production.rb:
Finally, we can create our index.html. Place it in the public directory:
You can now work on your app like you would on a Rails app, except you will only modify the assets and not do anything in Ruby nor Rails! Start the server with rails server and open localhost:3000 to see that everything is working.

To build you app, just run rake assets:precompile. Everything will be built in the public folder. Remember to run rake assets:clean when you are done, or else Rails will continue to serve the files in public instead of your actual source files.

No comments:

Post a Comment