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…
RailsConf
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?
Q: There are some people out there who prefer the “pure” JavaScript syntax and don’t like this idea of precompiling it. Is it even a good idea to 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?
Oh yea – again, the same thing with Java to Ruby. I can write a lot less code; it’s much cleaner and easier to read; it’s easier to maintain. I get a lot of people saying that they hate the fact that CoffeeScript is whitespace significant. To them I always say: “Well, how are you formatting your JavaScript?” You should be doing that anyway – you should be formatting your code nicely. At that point the whitespace significance really becomes insignificant whitespace, as you’re doing that already.
Should you learn CoffeeScript first, or JavaScript?
Q: Should I learn JavaScript first, before CoffeeScript? I remember Wyatt Greene at that Boston.rb meeting did another great talk right before you, From Ruby to JavaScript. One of the things he said was that he wanted to learn JavaScript thoroughly first, before starting to learn CoffeeScript. Do you think that’s a good idea?
I think it’s a must-have idea. In my book, there are numerous places where I actually recommend to the reader: “Put the book down – go read something on JavaScript first and then come back again” if they don’t know it. It is very important that you know what it is doing. You will learn some really interesting things about JavaScript from CoffeeScript; I certainly did. It’s made me a better JavaScript developer, but I was a JavaScript developer first.
Q: Is it OK to be a casual JavaScript developer? Or do you really need to thoroughly understand it before trying to learn CoffeeScript?
You should be at least an intermediate JavaScript developer, because some of those concepts get a little hairy and CoffeeScript takes some of that stuff away from you. If you’re beginning and you don’t really understand what makes a function a function or how callbacks work or how prototypes work, you should brush up on all of that first.
Q: …because CoffeeScript might make it harder to understand?
Not harder, but it abstracts it all away. Knowing what JavaScript can do, and how to it, means you can really take more advantage of what CoffeeScript has to offer.
Q: It makes it easier not to learn JavaScript thoroughly, I guess.
Exactly. I can see people easily jumping into CoffeeScript and generating some pretty cool code without knowing what it’s really generating. The minute it generates something they don’t understand it’s going to really bite them in the ass, you know? When they don’t understand why the scope is not correct. Or, why something is not equal to another thing their lack of JavaScript is really going to hurt them.
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?
I think it’s ok just to use it inside the asset pipeline. Using it is more important than playing with it. That’s the way I feel about any language. I don’t learn a language by building tinker toy little apps, I learn by using it for an actual app. That’s how I learn: sink or swim. If you’ve got an application you’re building and you need JavaScript, just start using CoffeeScript! You can mix and mingle regular JavaScript and CoffeeScript files in the same application. You’ll learn more about CoffeeScript, or any language, by using it for real than you ever would just by creating a little “to do” app. You starting saying: “I really need to learn how to do X, Y and Z to solve this problem.”
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.
Testing CoffeeScript
Q: And do you want to tell readers about the presentation I saw at Boston.rb in March? I was struck how even Boston.rb members didn’t do much JavaScript testing…
At that talk, there were 100 people there, and I asked the room: “How many people test their Ruby code?” and 100 people raised their hand. And that’s very indicative of the Ruby community. And then I asked the room: “How many people write JavaScript code?” And again everybody raised their hand. Then I asked “How many people test their JavaScript code?” And just 6 people raised their hand.
Q: And I was not one of them, trust me.
That’s just an awful number. Only 6% of the Ruby developers in that room test their JavaScript? And they all write JavaScript! So why is it ok to test Ruby and not JavaScript?
Q: I think the reason why, in my opinion, is that JavaScript is the stunted little stepson of the family and no one really takes it seriously. And in the past few years most people did not write much JavaScript; there were just a few lines here or their for validation, a little Ajax, etc. So I’m answering your question – you’re supposed to be answering the questions! But now suddenly people realize: “I can write big apps just with JavaScript.”
I also think there’s a fear that JavaScript would be too difficult to test. If it needs to run in a browser, how am I going to do that? How am I going to test DOM interaction? How am I going to test AJAX?
Q: For Rubyists who have this fear… what should people do to learn how to test their JavaScript?
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.
One of the things that I’m very surprised at, to the point where if I had the time and the inclination I’d probably sit down and try to write a big pull request for Rails 4, is how Rails doesn’t include testing tools for JavaScript.
When they introduced the asset pipeline and CoffeeScript in Rails 3.1 – and I think CoffeeScript lowers the barrier to entry for testing in JavaScript because it feels so much more natural like you’re writing Ruby – why didn’t they include testing tools? That weighs in my mind. From very early on in Rails, there was a test framework right there and there was so much emphasis on: “Look how easy it is to test your code.”
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.
So why the team never put in testing tools for JavaScript blows my mind. What I demonstrated at Boston.rb should have been in the framework. And every time Rails generates one of these .coffee files for you, it should generate a test for you.
Thanks!
Q: Thanks for all your time, Mark!
Sure thing, thanks Pat.
Pat ShaughnessyPat Shaughnessy writes a blog about Ruby development and recently self-published an eBook called Ruby Under a Microscope. When he's not at the keyboard, Pat enjoys spending time with his wife and two kids. Pat is also a fluent Spanish speaker and travels frequently to Spain to visit his wife's family.
