Syntax & Semantics: JavaScript, Ruby & CoffeeScript
jQuery, CoffeeScript, Ruby
Seems like everyone is talking about how the web is moving to single page sites and much of the processing is moving to the client side. Frameworks like Ember.js and Backbone.js are what all the cool kids are talking about. Plus, Node.js is gaining popularity for the servier side. All this means JavaScript use is going to grow in the foreseeable future. I was initially put off JavaScript, but have grown to like the semantics, but not the syntax. Here are some of the reasons why.
JavaScript used to look like C
One of the first things that put me off JavaScript was that it looked too much like C and Java. For example, it seemed a little bizarre that we needed a var when it didn’t seem to add anything useful to the variable initialisation. C is a great language for writing things like device drivers that talk to hardware, but in the browsers we surely want something different. Ideally easier to use and closer to the problems we’re solving. The following code shows the same algorithm in three languages, I’m always impressed by how clean the Ruby code is. To me this indicates how much junk there is in the other languages cluttering up the code that I don’t really want to have to worry about.
JavaScript:
var array = [0,1,2,3,4];
var sum = 0;
for (var i = 0; i < array.length; ++i) {
sum += array[i];
}
C:
int array[] = {0,1,2,3,4};
int sum = 0;
for (int i = 0; i < sizeof(array)/sizeof(array[0]); ++i) {
sum += array[i];
}
Ruby:
array = [0,1,2,3,4]
sum = 0
array.each do |item|
sum += item
end
But in Ruby we’d typically not use each in this case, we’d do it with inject:
sum = array.inject(0){|sum, item| sum + item }
JavaScript with jQuery
One of the great things I love about Ruby is its use of “blocks” allowing the constructs like each and inject to be created within its core libraries for arrays. (I talk in more detail about blocks in Ruby vs Python.) JavaScript has blocks too, in the form of anonymous functions. The very widely used jQuery library defines some helpful functions, such as each, which can be used along the lines:
var array = [0,1,2,3,4];
var sum = 0;
$(array).each(function(item) {
sum += item;
});
Semantically this is very similar to the Ruby code above. However, I find the syntax less desirable as it’s more cluttered with vars, semicolons, and nested brackets. None of which seem to add anything particularly useful to the code. CoffeeScript is a language designed to provide a nicer syntax, but to compile down to JavaScript.
The CoffeeScript code is very similar to the Ruby code, with a couple of differences, such as using -> instead of do and whitespace is syntactically significant (like Python) instead of using end:
array = [0,1,2,3,4]
sum = 0
$(array).each (item) ->
sum += item
How important is syntax?
I think it’s very important. In these basic examples, it’s quite easy to write the code in any of these languages. However, as the code gets more complicated the less of my brain that get’s taken up by processing syntax the better. Every little helps. So, I think we should strive for a language that lets us focus on the important parts and removes any unnecessary clutter.
To use CoffeeScript or not?
One of the debates about whether using CoffeeScript is a good idea, is that it adds an extra layer of separation from the underlying JavaScript code, without providing significantly different idioms to program with. This perhaps makes most sense for programmers programming more heavily in in JavaScript, as they’ll be more familiar with the patterns, but for Ruby programmers I think it’s well worth taking the hit. I think because the idioms and semantics are similar to Ruby, having a similar syntax also means that the patterns are more familiar and hence less work for the programmer.
Using CoffeeScript can make debugging harder. For example, you can’t just copy and paste the code into the browser console. However, you can use the JavaScript the CoffeeScript produces and as it’s semantically similar, it’s not too hard to translate back to CoffeeScript. As frameworks and testing around the code running client side (in the browser) improves, I think this is going to be even less of an issue. Hopefully almost all bugs will be caught within the tests, rather than having to debug within the browser console.
The Future
Having used CoffeeScript on and off for over a year now, I have personally found it great to work with and plan to use it more in the future. I’m also excited about the JavaScript frameworks gaining popularity, the prospect of building more single page sites, and doing more coding on the client side. I think it has the potential to be a great age with great programming tools, frameworks, and libraries. I’m glad we have JavaScript in the browser and not Java!