Skip to main content

JavaScript on Rails 2016

Whilst I am primarily a JavaScript programmer, my framework of choice is Ruby on Rails. A lot of JS guys like Node or other frameworks which are JS all the way through, but there's a lot to like about Rails, even in 2016 and it's worth learning another language (Ruby) or two (SQL) in order to get the best environment on which to write your JavaScripts.

Before I say what I like about Rails though, I will take you through what I don't like just to balance things out.

What I don't like about Rails

Asset Pipeline still does not let you use ES6 Modules. 

Even at this late stage, one still cannot access ES6 Modules in Rails in a "Railsy" manner. You can either bypass the whole Asset Pipeline or else separate out the JS using Webpack or whatever, but in a standard Rails project, the fact that the asset is generated with unique hash in the file name before the extension pretty much nullifies its use for ES6 Modules which need a static location to store the files. You can probably try putting the library files directly in the public directory, but nowadays a lot of these need to be built first which means some kind of build system needs to be involved. DHH, please get on this!


Turbolinks works great in theory, but in practice, as soon as you try to use some third party code which depends on document.ready, you are up a certain creek without a paddle. Not only that, but your JS will live on in memory between pages and if you are not careful about how you write your code, the browser's memory could end up filling up and slowing the user's experience to a crawl (but this is a problem most SPAs face).

Gem versions of JavaScript libraries

This is really a convenience thing that is only convenient if you don't mind running out of date code. Because the asset pipeline makes it harder to pull in 3rd party libraries and their dependencies, some nice people out there will create gem packages of these JS libraries which you can install into your Rails app and voila! They (mostly) just work! Until you want to access a new feature of the library and the gem maintainer has decided to go on an extended holiday. Then you end up trying to pull it in yourself and find out you need to change all the embedded stylesheet links because of the Asset Pipeline (see above)


I love coffee, I love scripts, but I hate CoffeeScript. Thankfully this seems to be on its way out as ES6 becomes more prominent (and ES6 did pull a few good things from CoffeeScript) but CoffeeScript is not JavaScript and it used to be the "defacto" Rails standard

What I like about Rails

Now that we are done with all the things I don't like about Rails (as a JavaScript programmer), I can talk about the things I do like.


Wait, wasn't that in the dislike section? Yes it was, but there a number of things to like about Turbolinks as well.

Turbolinks allows you to (almost) get the speed benefits of an SPA (Single Page App) without the complexity. It also means you don't have to pivot techniques mid stream. Often when you start writing a Rails app you leave out the JavaScript sprinkles just to make sure your models and assumptions are interacting correctly and using Turbolinks, you can add in the JS goodness without having to rewrite everything as services.

It's very thin

Compared to a lot of other web frameworks, Rails pretty much gets out of the way. If you spend the time modelling your data properly, the Rails layer should be very very thin. They say fat models and skinny controllers, but you can even get away with relatively thin models too if you are going to push a lot of the logic up to JavaScript layer.


Ruby as a language is a dream to work with and a lot of the functionality of underscore and lodash were inspired by Ruby's Enumerable methods (things like each and first and last and reject and I could go on...). Also the ActiveRecord framework ties in directly to how models in 3rd normal form relate to each other so that when you do have to work in the Rails layer it's quite simple.

React-rails Gem

The react-rails gem is more or less plug and play. The only problem is the lack of ES6 Module support.

Jasmine Gem

The jasmine gem ( is beginning to show it's age a little bit (still no ES6 support) but it's a very handy way to test your JavaScript components (react or otherwise). If you assume all the JS is available in memory as objects and then only instantiate instances as needed (which is indeed the way Rails works with Ruby objects) when you are golden.


Even as a modern Rails developer, you will find yourself writing lots of JavaScript. Vice versa, there is plenty to like about Rails if you are a JavaScript developer. What you lack in monolingualism, you gain in terms of having each language perfectly suited to its task. This is akin to listening to Italian Opera and Norwegian Death Metal.


Popular posts from this blog

Freezing Gems

What is a gem and why would you want to freeze it? In Ruby, there are times when you want to access pieces of functionality that other people of written (3rd party libraries) and you normally have 2 options. You can install a plug in or install a gem. Normally the method you use is determined by which ever is made available by the author. Gems are installed on the host machine and are pretty handy when you want to run things in the command line or else across lots of projects, but their downside is that if you use a gem in a Rails project there is no automatic publishing mechanism when you deploy your site. You will need to log onto the remote host machine and install the gem manually. Plugins are specific to Rails and are similar to gems in that they are also 3rd party libraries. However they are associated with your Rails project as opposed to your machine so they will get posted to the server on a regular deploy. Freezing a gem is the process of transforming a gem into a plug in. Es

Elixir - destructuring, function overloading and pattern matching

Why am I covering 3 Elixir topics at once? Well, perhaps it is to show you how the three are used together. Individually, any of these 3 are interesting, but combined, they provide you with a means of essentially getting rid of conditionals and spaghetti logic. Consider the following function. def greet_beatle(person) do case person.first_name do "John" -> "Hello John." "Paul" -> "Good day Paul." "George" -> "Georgie boy, how you doing?" "Ringo" -> "What a drummer!" _-> "You are not a Beatle, #{person.first_name}" end end Yeah, it basically works, but there is a big old case statement in there. If you wanted to do something more as well depending on the person, you could easily end up with some spaghetti logic. Let's see how we can simplify this a little. def greet_beatle(%{first_name: first_name}) do case first_name d

Responsive Web Design

I wanted to go over Responsive Web Design using CSS. In the old days of web development, we had to code to common screen sizes (i.e. 800 X 600, 1024 X 768) and we patiently waited for people to upgrade their computers to have a decent amount of screen real estate so we could design things the way we really wanted. We also took on semi stretchy web layouts etc to expand and contract appropriately. Then about 2 or 3 years ago, Apple released this little device called an iPhone with a 320 X 480 resolution which took the world by storm and suddenly a lot of people were viewing your website on a tiny screen again... Anyways, as it can be difficult to design a site which looks good on 320 X 480 AND 1680 X 1050, we need to come up with some kind of solution. One way is to sniff the client and then use an appropriate stylesheet, but then you are mixing CSS with either JavaScript or server side programming and also potentially maintaining a list of appropriate clients and stylesheets. Also, you