I’d heard second hand for a long time that Mark Bates was a great public speaker, but it wasn’t until the March meeting of Boston.rb that I had a chance to find out for myself. He gave a great presentation called Testing Rich Client Side Apps with Jasmine, about how to use Jasmine and other tools to test web applications that use CoffeeScript on the client. It was informative, entertaining and thought provoking. Despite being an experienced Ruby developer I’d never taken the time to learn how to use CoffeeScript properly in my applications. But listening to Mark and seeing his examples inspired me; I thought to myself: “This is something I need to learn and use as soon as possible.”
I was excited a few weeks later when I had a chance to interview Mark myself – what better way to get started learning CoffeeScript! First I took the time to read his book, Programming in CoffeeScript, which was fantastic and very helpful. Then we spent about an hour talking about CoffeeScript: how it was invented, what other languages inspired and influenced CoffeeScript, how a Ruby developer should start to learn it, testing and more… I’ve typed in the highlights of our conversation here. If you’re a Ruby developer interested in learning more about CoffeeScript here’s your chance to hear from a well known developer, author and thought leader about how to get started.
Who Is Mark Bates?
Mark Bates is founder and chief architect of the Boston-based development and consulting company, Meta42 Labs. He has developed web applications since 1996. Since discovering CoffeeScript, he has become a leader in its programming community, presenting to user groups and speaking at high profile conferences around the world, such as RubyConf, RailsConf, and jQueryConf. He is the author of the books Distributed Programming with Ruby and Programming in CoffeeScript.
Q: Hi Mark – thanks for talking with me this morning…
You’re lucky I’m awake! I accidentally took a few Tylenol PM this morning, the fact that I’m sitting upright right now is amazing…
Q: I heard you did a great presentation CoffeeScript for the Rubyist at RailsConf on April 23rd. How did it go? How was the conference in general?
The talk went great, excellent reception. It helped that I had an excellent time slot, morning of the first day, most people were still sober, of course being drunk probably would’ve helped my presentation! Judging by the people who came up to me during the conference, and on even on the plane ride home, I must’ve done something right, because I’m sure I made a few converts.
The conference overall was really good. The theme that DHH put forth was progress. Keep looking towards the future, learn the new technologies, keep growing as a developer. CoffeeScript got quite a high profile mention during the keynote and it was mentioned, a lot, throughout a lot of the other talks I saw. I would say that I heard more people discussing CoffeeScript, Backbone, and Ember more than Rails itself. Really showed where people are heading with their development.
Should you even use CoffeeScript?
To them honestly I would say: “fine, if you want to keep writing it that way it’s up to you.” I look at it as very similar to why I moved to Ruby from Java. Ruby obviously has some features that Java doesn’t have, and Java has some features that Ruby doesn’t have – all languages do. I can write a web app in Java, just as well in I can in Ruby…
Q: We all used to do that…
But I prefer writing it in Ruby because I can write a lot less code to do the same thing. That’s the way I feel about CoffeeScript.
Q: Is there also something about the beauty or elegance of the CoffeeScript code?
Q: …because CoffeeScript might make it harder to understand?
How would you go about learning CoffeeScript?
Q: If you’re a Rails developer or a Ruby developer of some sort, what’s the right way to learn CoffeeScript?
I hope reading my book, Programming in CoffeeScript would be a great way to learn it. For Rubyists, there’s a little bit of Ruby in the book, but I wanted to make it accessible to everybody, not just Rubyists. I used Node.js to build the sample application in the last three chapters for a couple of reasons:
- Because Node.js and CoffeeScript are quite commonly linked together and you see a lot of Node apps being written in CoffeeScript.
- Because I could write the back end in CoffeeScript. It was a great way to just delve into the language and to see real examples of the language being used.
Q: I thought that was really cool! I kept thinking to myself: “I can’t believe I’m writing a server in CoffeeScript!”
Yea! It’s pretty cool. In the book we write the server and the front end in the same language, in CoffeeScript, which I thought was actually kind of fun and kind of cool. But if I had done it in Rails, then I would have alienated PHP people, Python people, Java people, and there was no need to write it in a different language because I could write it in the language of the book, which was a really fun exercise.
For Rails people, it’s pretty straightforward. You fire up Rails and the support for CoffeeScript is just there. Just start using it.
Q: I think that’s where I am: I’m a Rails developer but I’m not a CoffeeScript expert. I use it here or there; it just sort of works. Again, it’s almost too easy – you don’t really need to spend the time to learn it deeply.
It is easy with Rails to just start using CoffeeScript and get to a point where you think you know it and know it well. It’s not a horribly large language; it’s actually pretty simple. But there are a lot of really cool little hidden things in this language.
Q: If I’m a Rails developer, should I just install Node.js and learn it the way you present in the book? Or is it ok just to use it inside the Asset Pipeline?
Q: And so you have to learn about X, Y, and Z.
Exactly; it’s not a contrived problem. Your business is barking for this feature and you’ve got to learn how to do it.
Origins of CoffeeScript
Q: What inspired CoffeeScript? Was it inspired Ruby? Or by Python? Where are its roots?
It was inspired by both, and Lisp, Smalltalk, whatever excited Jeremy Ashkenas. Which is why if you look at it, it looks like a bunch of different languages. It’s got the significant whitespace of Python, and some things like the @ symbol and class definitions that are very Rubyesque. Jeremy wrote it originally because he had read How To Create Your Own Freaking Awesome Programming Language by Marc-André Cournoyer. He read this book and started tinkering with it. The original implementation of CoffeeScript was in Ruby – the original compiler.
Q: Is it all in C code now, or something?
No, it’s all written in CoffeeScript!
Q: It’s written in CoffeeScript itself? Sounds like Rubinius….
Yea. Exactly. It’s one of those things that always blows my mind. Rubinius blows my mind in that it’s a Ruby implementation written in Ruby that runs on Ruby. How the world doesn’t implode when someone starts up a Rubinius server I will never know.
With something like a compiler it’s a little easier because you write the first compiler in something else, and then you have the language to use to write the next compiler. The first compiler was written in Ruby. But then he took version X which was written in Ruby and then wrote the CoffeeScript compiler in version X of CoffeeScript. If you go to github, it’s all in CoffeeScript!
Q: With Rubinius it’s great how if you’re not sure how something works, e.g. “How does the String.slice method work?” – you can just go and look at the Ruby source code.
Yea with CoffeeScript it’s all in CoffeeScript. If you want to know how class support works in CoffeeScript – you just go read the CoffeeScript source code and you’ll see it right there. It’s actually pretty readable source code. It much more approachable than, for example, the Ruby source code.
Ember.js vs. Backbone.js
Q: I wanted to ask you about Ember.js vs. Backbone.js. I don’t know if that’s a controversy or not; they’re sort of just different things. You’ve said you use Backbone a lot – I’m curious why? And have you tried Ember? What’s the difference between them?
In some respects they are wildly different. I think a better comparison would be Backbone.js vs. Spine or Knockout. I like Backbone a lot – I find it incredibly simple, easy to use and easy to understand. It makes a lot of sense to me. Backbone let’s you create models, collections and views to manage your HTML, and deal with the events that happen on these models and collections, dynamically call functions to, say, re-render that once it’s been updated.
Ember takes a different approach and says that you have to mark up your HTML in a certain way. And if you do that, then auto-updating of attributes will happen automatically. If I mark up my <h1> correctly that has the name of a user, and in my User object I change the name of that user then that <h1> tag will get updated without me having to do anything else.
Q: So in Backbone you need to do that updating yourself?
Exactly. But I think Ember’s updating is simultaneously both slick and dangerous.
Q: Because it might be happening when you don’t expect it to?
There might be times when you don’t want to update elements on the page, for whatever reason. I’m also anti-adding-extra-markup to my pages, if I don’t need it, which is one of the reasons why I don’t like Knockout. Knockout works almost entirely by adding extra data elements to your HTML. If down the line you want to change something you end up with all of this extra cruft.
One of the things I like about Backbone is that it cuts down the amount of markup I have to put in there. I don’t need IDs so much any more or even class names, just so I can find a particular element. They all get scoped to views. If you write your views correctly you can do a generic search for a list element; you don’t need to worry about making sure it’s the right set of list elements.
I’m actually going to be writing a new Backbone eBook soon.
Q: Fantastic! By the way, how did you get your start writing books? It’s very impressive you’ve already published two…
I got started writing by getting Obie Fernandez drunk in a hot tub! Obie had seen me talk at RubyConf 2008 about distributed programming and we were in the hot tub hanging out with the Hashrocket folks, we were having a few drinks, and I mentioned to them that a couple people had asked me after my talk about where to get more information on distributed programming. Then Obie told me he was the Ruby series editor at Addison-Wesley and that distributed programming would be a great book topic… and it went from there.
Q: And I was not one of them, trust me.
That’s a great question! There’s a lot of great resources out there: look at Jasmine, look at Mocha, look at Chai. There are a lot of really great libraries that resemble the libraries you’re already using to test Ruby.
Q: Yea in your presentation I was struck how much Jasmine looks like RSpec.
Exactly. And same thing with Mocha and Chai: they look very much like RSpec.
Q: To be honest, that’s a big reason why it caught on – because it was there in the first place.
… and because it was easy to do. Rails made it super easy to do. I’ll be honest – in all my years of writing Java, ask me how many Java unit tests I wrote! It was not a lot; I’m not going to lie to you! And Rails came along, and wow there was Test::Unit, which I was not a fan of, but it was right there, baked right in and I could start testing easily.
Q: Thanks for all your time, Mark!
Sure thing, thanks Pat.