JavaScript vs CoffeeScript in Ruby on Rails Apps

Photo of Jakub Niechciał

Jakub Niechciał

May 30, 2016 • 4 min read

At Netguru, we regularly discuss technologies we use to make sure we are not lagging behind or losing some recently emerged features in the world of web development.

Here's a short rundown of our discussions on whether to use JavaScript or CoffeeScript in our projects (note that we are currently using CoffeeScript by default). Be aware that this list is Netguru-oriented and you might have different opinions - feel free to comment below.



  • ES2015 and ES7 are currently state-of-the-art web languages;

  • Ember and React are extensively using ES2015 and ES7 (!) features in their core features;

  • if we want to publish interesting content on either blog or Stack Overflow, we need to switch between Coffee and JS, as JS is a default way in modern work;

  • developing in JavaScript demands more knowledge and understanding of how the language works; it's easier to obtain new knowledge by no need to transpile and comprehend both syntaxes;

  • even though some people say that JS syntax is worse, the reason might be the lack of ES2015 knowledge, which makes simplifications like arrow functions the same as in Coffee;

  • better tools - we can easily add linters to our projects that are quite smart about JS code; ember has built-in linter config that fails tests if our code isn't proper; CodeClimate supports JS.


  • some people say that JS syntax is worse than Coffee;

  • it will bring confusion due to different syntax in different projects (older projects will stay in Coffee);

  • there is no easy and working transpiler between Coffee to JS (ES2015) and it demands simple transpiling to ES5 and changing by hand (error-prone);

  • we will have to maintain old coffee projects and new JS projects.



  • it's our default now, and all of us are familiar with coffee;

  • it's easier to work with and maintain due to a simple syntax;

  • staying with coffee won't demand any change and confusion while switching between old and new projects.


  • it doesn't support ES2015 features;

  • no support from CodeClimate or JSLint / ESLint, built in Ember as a default tests part;

  • due to the lack of ES2015 support, we cannot use some of the new features in Emberjs like: new computed property syntax using getters and setters, importing modules ES2015 style and others;

  • it's hard to work with the newest features and examples from Ember or React due to the fact that they are written in ES2015 and shown by JSBin that supports ES2015;

  • due to the ease of sharing scope using fat arrow and no need to declare variables, it's easy to forget about the basic concepts of JavaScript, e.g. the scopes mechanism and why it works this way, not another.

These pros and cons are highly opinionated and might be different for you, depending on projects you work on. We'd be happy if you could share your perspective in the comments section below.

Photo of Jakub Niechciał

More posts by this author

Jakub Niechciał

Jakub has obtained a Master’s degree at Poznań University of Technology in Control Engineering and...
How to build products fast?  We've just answered the question in our Digital Acceleration Editorial  Sign up to get access

We're Netguru!

At Netguru we specialize in designing, building, shipping and scaling beautiful, usable products with blazing-fast efficiency
Let's talk business!

Trusted by:

  • Vector-5
  • Babbel logo
  • Merc logo
  • Ikea logo
  • Volkswagen logo
  • UBS_Home