Poll: Have you moved from JavaScript to CoffeeScript?

135 points by ColinWright ↗ HN
Question asked over here: http://news.ycombinator.com/item?id=2683302

Not sure why it wasn't an actual poll - maybe they don't have enough karma. Anyway, here is an actual poll. Feel free to comment as to reasons or other possibilities.

177 comments

[ 2.1 ms ] story [ 206 ms ] thread
I still use javascript, but I am intrigued by CoffeeScript enough that I can see in myself starting to use it in the near future, once I get time to work through the PragProg CoffeeScript book.
Missing option: will be using CoffeeScript on my next project.
Missing option: have moved to CoffeeScript but switched back to JavaScript.
This is me. I love CoffeeScript and can't wait for all it's good bits to filter into JavaScript - but I hate having an "extra step". It's ok while you are actively working on a given project, but I tend to work on projects in big cycles and might not come back to something I was interested in for a year or two. The chances that my two-year-old coffeescript will run in the new versions of the compiler are slim (and my desire to port it low!)

The other day I found the code to a shoot-em-up I wrote in 2002 and it ran in Chrome with no changes required! Sure, the code was very "DHTML"-y, but that's pretty cool!

CoffeeScript is amazing, I use it for everything including writing native iPhone apps (using titanium). Search for Album Plus in the app store. or visit http://www.albumpl.us/
I checked out your app, very interesting how native it feels. Would you recommend Titanium, in general?
Titanium is a mixed bag. For simple applications, it's great, but as soon as you need to do something a little bit complicated, the learning curve goes up quite a bit.

For example, in my app (http://iphone.albumpl.us) I had to write a couple of small custom objective-c modules to get some camera/image stuff to have sufficient performance. But overall being able to write most of it in CoffeeScript, is so much better (enjoyment-wise and speed-wise) than having to write everything in objective-c.

Ah, very nice, thank you.
I've found Titanium great, and our entire app is CoffeeScript as well. Take a look at HotelTonight http://htltn.com/iphone to see what you think.
Nope. I like my parens, braces and keywords thanks.
I have nothing against CoffeeScript, and I've used it on a few things, but in general I find JS to be an enjoyable language to work in. If I had more issues with the syntax or something, I might find the switch to CoffeeScript worthwhile.
Agree. CoffeeScript has great syntax that I find very inspiring and might incorporate into my own language someday, but all in all, javascript is not that bad... at least not the parts that CoffeeScript can fix.
Yes, and why would I want less of JavaScript's syntax in my life when it has so much overlap with other languages I use like PHP?
Well, you do choose Javascript when you could have chosen PHP and had even more overlap. Presumably, because you believe it is better for the tasks. Similarly, Coffeescript authors believe that Coffeescript is better than Javascript -- even if there's less overlap.
Will understanding the CoffeeScript syntax help me learn another programming language like JavaScript did?
Syntactically? No. Ideologically? Absolutely.

Guess which is more valuable :)

I don't use JavaScript for anything for which I could have chosen PHP. Given that PHP runs in exactly 0 browsers, what do you mean? Few people are choosing server-side JavaScript over PHP, though it may happen occasionally.
How is other different from I don't use either?
This is going to be a very interesting poll result. Even 5 or 10% penetration is something remarkable, for a language as widely-used as JavaScript.

If you feel like providing any more color beyond your vote, your impressions after using CoffeeScript in anger -- I'd love to hear 'em.

This is a lame reason not to have tried it yet, but I need to first skim a short tutorial that shows how to integrate with jQuery and ideally also shows simple uses of Backbone and Underscore in coffeescript.

BTW I love Backbone and Underscore and thanks to them (and also node) JS is actually more fun than ever.

I'm actually about to make a dip into using Backbone so I've been holding off on transitioning to CoffeeScript to limit my shock.

I've played around with the editor at GitHub though and I really like how CoffeeScript reads. That being said, actually using it in the wild seems is road I'm not quite ready to cross yet.

I've started using Backbone.js in a very limited way for some of our existing apps.

What I'm doing is just using views as a way to provide some structure to what is currently a mess of jQuery event bindings and DOM manipulation. So instead of have a Backbone view that gets configured with a template and passed a model to render, I just do some setup code in the initialize function and then use Backbone's event function to setup all my event bindings for different DOM events that will occur within the element that is the root of that particular view.

This is working really well so far. It doesn't require completely rewriting the app to be a single-page client side heavy application, but does provide a significant amount of structure to the code making it much more manageable. It also lets me reuse some views (sort of like widgets) that were previously tied directly to specific elements in the DOM.

You won't be needing underscore.js in coffeescript. Most of the underscore.js provides sequence abstractions and coffeescript does them out of the box. Things which aren't provided by coffeescript(and there aren't many) can be easily done in coffeescript directly.
Used it. Not extensively, but I have. It adds nothing of real value for me; I have no fundamental beef with the Good Parts of JavaScript and get nothing from a Ruby-inspired hat on top.

I'd like to see something like MileScript gain some traction--not to replace JavaScript, but as another tool in the toolbox. MileScript adds new value that you don't really get with plain JS; CoffeeScript doesn't.

I'd be shocked if Milescript got traction without it being inflicted on developers from above.

Milescript turns Javascrpit into Java. Whilst many developers don't have a problem with static typing, none I know of like the verbosity of Java.

An ML or Haskell styled Javascript might fare better.

I'm not sure I agree--it's certainly verbose, but to me it feels more like C# verbosity (which I find helpful and often nice) than Java (which is often obfuscatory).
I've never done front end before (I just hate the JS syntax, so I've avoided it, besides a few jsonp requests) but with CoffeeScript I was persuaded to give it a try.

Here is my problem. Nothing is Google-able. Even basic things that I get caught up on the answer on IRC is usually "look up how to do it in JS, and then reform it to CS". Maybe I'm starting on the wrong stuff, but even though the syntax is wonderful, actually using libraries is a pain. I'm only on my 2nd day though, so maybe this is just the normal language growing pains.

Interesting. I'd gone through the first link before, but the second is quite good. Still doesn't change the fact that most libs you are using are written in JS (not to mention a whole new platform, the browser) and therefore harder to Google for, but thanks for your help.
2 days? Give it 2 weeks and you won't look back. I do think it's more suitable to writing a "new big app from scratch" -- fixing up some consulting client's website with some new JS widget and 5-20 lines of integration scripting or some such isn't the use-case where CoffeeScript gives you a notable advantage.
> "actually using libraries is a pain"

Maybe that is your source of confusion.. when you write CS code, you can use any existing JS library. The syntax is just different for what you write.

You should really learn Javascript first. Coffeescript is not (yet) a replacement for it, more like a tool.
Maybe this sounds nitpicky but I'm just not a fan of languages that use indentation to denote block structure. It turns trivial code manipulations into tedious line-by-line exercises. I don't like it in Python or Haskell either.

Other than that I see a lot to like in CS though.

For some reason Python's indentation really bugs me, but I am totally ok with it in haml, sass, and yaml.
You must be a Ruby programmer.
Unfortunately, this poll isn't scientific and you won't be able to trust the results no matter what it says. I expect the poll will show much higher CoffeeScript penetration than it has in reality.
I'd roughly estimate that 5% to 10% penetration on HN means 1/10% in the larger population.
I have pretty much moved to using CoffeeScript exclusively over JavaScript. One of the minor complaints I have (overall, it is magnificent) is that the looseness of the syntax sometimes leads me to doing a kind of guess-and-check style of programming where I write something, then try to compile it to see if it did what I expected. An example of this is when calling a function, you need a comment to continue the function arguments onto the next line, unless the argument on the next line is an object literal.

The only real problem is that debugging with CoffeeScript adds an extra layer of complexity. I know that this is more or less inevitable, but it is really the only major pain point that I encounter on a day-to-day basis.

I am strictly a server side programmer and have a problem doing front end work. I want to learn it, but it feels like a sheer cliff to me. The low level CoffeeScript documentation is excellent. What I am looking for and not being a JavaScript programmer this is admittedly difficult for me, is some hand holding on the mechanics.

* packaging, how do I import modules or packages? Do these even exist?

* debugging, how do I do this?

* unit testing?

I installed CoffeeScript via node, then npm (node package manager) and am using it via the command line.

Something like the ipython (http://ipython.scipy.org/moin/) shell along with pdb (http://muffinresearch.co.uk/archives/2008/04/27/python-debug...) would help immensely in my adoption of CoffeeScript.

In a perfect world the repl/debugger would be built into the webapp and open a websocket to another webapp so I could introspect/debug the page from another page while it was running (turtles all the way down). This is similar to the workflow for developing server side software (Jython, Python, Java).

* npm + bowserify or stich or others

* in firebug / web inspector

* qunit, jasmine etc

repl for node

    ### REPL ###
    repl = require 'repl'
    r = repl.start 'REPL> '
    r.context.client = -> exec("open http://localhost:#    {config.port}/") ; return
Thank you both for these links, I am off to a very good start.
Hey. I voted 'use Coffeescript a lot and JS a little'. I like to use the best tools, so to me learning JS was just a step on the way to learning Coffeescript as soon as I had heard about it. It always boggles me when people don't want to use better tools.

In terms of complaints, I'd say the main one is a few things missing from the big page of documentation that's on coffeescript.org - #'s are comments, function calls with multiple arguments need to have the left paren start immediately after the function name, how to pass anonymous functions. Those cost me a few hours taken together starting out.

Thanks -- if you want to open a ticket listing the documentation missing bits you've run into, we can get those taken care of.
I totally moved from JS to CS. I still do JS on projects that don't use it, but generally CS is the way to go and makes things super easy.
Yes, all new code in CoffeeScript. I don't know why to use plain javascript.
I've added CoffeeScript support to the client-side of Appleseed, and I couldn't be happier. Building out the client-side framework used to be drudge work with Javascript, now I prefer it to server-side work (which is in PHP).

It's amazing what a more concise and logical syntax can do. While I think the language isn't perfect, it does just enough clean up on Javascript to make a huge difference.

I use it for both client- and server-side. Do not skip learning JavaScript before learning CoffeeScript, if only to be able to debug CoffeeScript. The JavaScript equivalent of a 1-line CoffeeScript function can be over 20 lines, not because CoffeeScript compiles into bloated JavaScript, but because it is very 'expressive'.

A trivial example (ignore style), project euler problem 1:

  (x for x in [0..999] when x % 3 is 0 or x % 5 is 0).reduce (xs, x) -> xs + x
Initially, coming from a Python background, I looked at Coffeescript as a fix for all of JS's woes. In particular, I mistakenly though the fat arrow syntax would mean I never have to do any 'that = this' hacks again.

In practice, though, I frequently need/want to call a method as a callback. And inside that function, I might want to get something from whatever initiated the callback, and save it to the object I'm a method of. Ie, I want to access both forms of 'this'. So I still need to do the ;that = this' hack, ugly as it may be.

It would be super awesome if there was something that always referred to the topmost class object, and something else that always referred to the initiating object if one exists.

That said, I still like Coffeescript, was surprised to see how much Brenden Eich likes and supports the project at JSConf, and wouldn't be surprised if they addressed niggles like this in future.

Do you have an example of a real-world piece of code that wants to access both the lexical and dynamic "this" ... and isn't a jQuery callback?
What's wrong with jQuery callbacks? ;)
jQuery generally abuses (or takes advantage of, depending on your perspective) the value of "this" in its callback functions, in places where it would really be better to have an explicit argument. For example:

    AccountView.prototype.render = function() {
      $(".account").click(function(e) {
        // `this` is now the same as `e.currentTarget`
        // But `e.target` is also useful.
        // And you what you really want is for `this`
        // to still point at the AccountView instance.
      });
    };
@jashkensas what you want though would break the way closures are handled in javascript. What you should do if you still want access to Accountview is to trap a variable with a reference to it in the closure. Using your jquery example:

  AccountView.prototype.render = function() {
    $(".account").click( { that: this }, function(e) {
      // 'that' now holds a reference to AccountView
    });
  };
If you don't want to use (or you are using an older version of jquery without the eventData) you could use a closure:

  $(".account").click( (function(that) {
    return function(e) {
      // 'that' now holds a reference to AccountView
    })(this);
  });
No, it's a jQueryism. How would it break the way closures are handled in JavaScript?

You realize you're replying to the author of CoffeeScript?

LoL I did not realize that. To me, I think I've just made my peace with the way it is. I don't think that jQuery needs to be changed in the way mentioned though - to me, 'this' is context sensitive and in this case, it would refer to the current object and not the container
Yes, functions in JavaScript have dynamic "this" instead of lexical "this" -- that's part of the point we're discussing. It helps when defining ad-hoc prototypes, but hurts when writing callback functions (or any nested function, really) ... and is an active point of concern for the ES committee.
(comment deleted)
> Do you have an example of a real-world piece of code that wants to access both the lexical and dynamic "this"

Yes.

> and isn't a jQuery callback?

No :^). And I wish JQuery ran the callback with a parameter too, so I could access 'this' to refer to the class and use the argument to refer to the object I'm going to run the callback on.

You're totally right that would be neater. Alas Coffeescript is a lot newer than JQuery, so despite technical neatness (or lack thereof in JQuery), Coffeescript has to work with JQuery to grow in popularity.

PS. Thanks for making Coffeescript. It's got me excited about JS again and I absolutely love it.

You're in luck then. This is precisely what the fat arrow in CoffeeScript is for: creating a function where the value of "this" is bound lexically. So:

    class Widget
      render: ->

        $(".widget-title").click (e) =>
          # `this` is still the Widget instance. 
          # `e.currentTarget` is the DOM element.
I was using the fat arrow, and wanted to keep using it, but switched to thin arrow (using @ to access the element and 'that' to access the class). Here's why:

click() works because the callback is given parameter:

    .click( handler(eventObject) )
Cool. You access @ for the class, and eventObject for the thing you clicked.

But I wasn't using click(), I was using load(), which has a different syntax:

    .load( url, [data,] [complete(responseText, textStatus, XMLHttpRequest)] )
I may be missing something - I only started doing JS seriously last year - but 'complete' doesn't seem to be provided with any parameters, like the element I just loaded. So my only choice, AFAICT, is to use 'this' to access that element. I'd be delighted if that was wrong though. :^)

Background: I was trying to get the width of an image file that wasn't in the document, so I could use it to size another image (which happened to use the first image as a webkit mask). Great fun.

Correcting self: that's the documentation for the wrong .load()! (yes, there's two). The proper docs are http://api.jquery.com/load-event. Which indeed allows the event to be passed to the callback explicitly, so inside the callback @ refers to the object and 'event' (or whatever) .target refers to the image. Problem solved!
I evaluated CS but ended up using Script# in my latest project at my day job, mainly because we are Microsoft shop and it will be easier for other C# developers to jump in if the need arises without learning a new syntax.
Trying to use a language that's vastly different to JavaScript to compile to JavaScript is an impedance mismatch that is destined to create more problems than it solves.
So far I’ve been very happy with how the project is turning out and I already see a lot of productivity gains; there seems to be much less run/test/debug cycles. The tooling/intellisense is so much better than the plain JavaScript and a lot of the typos and errors are caught at the compile time. Plus, writing C# on client and server is such a nice change.

Anyway, CS would be my second choice but that’s just because I work in .NET environment.

I just did my first tiny project in coffeescript and found it to be an odd experience. I was far too aware that I was programming in tokens that needed to map to JavaScript. Far too often I had to go back to the interactive "Try CoffeeScript" form on the website to peck things into until the parser errors went away.

To those more experienced: at some point does thinking in pure coffeescript take over, and the JavaScript transforms disappear?

It is worth noting, my final coffeescript code is a thing of beauty!

Why not use the REPL for pecking things ? The need to do that for syntax issues has almost disappeared for me over the first few weeks of use, but I consider the REPL to be a valuable tool even after I am quite accustomed to any language.
Yep - it goes away. When I started coffeescript I'd check the output of every statement I wrote (and had heaps of parser errors). Once I had a good idea of how it was being converted I stopped checking... I'm still not a fan of some of the output (I wouldn't write my JS like that, that's for sure!) but damn it's fun!
Thanks for creating the poll for me. I dont think i have enough karma to create a poll. There's no option on my login to be able to do that(?)
I use Coffeescript almost exclusively now.

However, if someone told me that Coffeescript was going to vanish forever from tomorrow on, I don't think I would be heartbroken.

You may want to add "What is CoffeeScript?" option.
I started using it last month, on production code. I work as a Javascript programmer in an otherwise all-Java software shop. I come from a Python background. I really love it.

I have Vim all set up to auto-complete it, to syntax highlight, and to auto-compile whenever I save. The bad news is: No Eclipse plugins, no notepad++ plugins. etc. So the only other devs who can work on it are on Mac and Linux (which to be fair, half of my company are on Ubuntu, but there's that 1/3 of the company on Windows that just can't practically work on coffeescript code).

There's a 3rd party plugin for PyCharm which has coffee script syntax highlighting. And I think WingIDE for windows supports coffee script as well.

I'm using the former. It's usable, but lacks somethings like fixing indentation errors automatically, and auto-completion. Also the default colors under twilight theme are unreadable, so you have to modify those yourself.

I don't like the Windows experience of CoffeScript. That's what's holding me back. I think I would use it if it had better Windows support.

As far as I know CoffeScript requires node.js, npm and cygwin. Am I wrong?

You're fully wrong. The CoffeeScript compiler is written in CoffeeScript and you find it in the extras/coffee-script.js JavaScript file. If you can load that in some JS runtime environment, no need for Node/NPM.

Cygwin is the current way of "Node on Windows" but there will be much better / "more native" Node support for Windows coming in the next 4-20 months ;)) anyway, you don't need Node for Coffee. It only provides the Node integration pieces because the developer(s) do a lot of Node work themselves and it's a great way to write server-side code for Node for people coming from Python/Ruby etc.

It's true that tools for compiling CoffeeScript on Windows are lacking, though the compiler runs fine in the browser as well as on Node—try it yourself at http://coffeescript.org—and also in various JS runtimes for Java, .NET, and of course Ruby.

If you're using CoffeeScript without Node, you're missing out. Fortunately, Cygwin-free Windows support is on the roadmap for Node 0.6.

I've recently begun porting a small canvas game that I'd been working on into Coffeescript. It definitely helped me create cleaner code. Also using it on a real project and I was able to prototype the basic functionality a lot more quickly than when I was using pure JS.
I think you guys obsess too much about programming languages. I doubt that anybody doing something useful cares about THAT "wohooo expressiveness".

JS is alright, dammit. You don't need CS, you need to get your shit done.

I used to think like that. Then I found the next logical iteration from "just get it done" is "get more done faster with less code". Hence, CS works better than JS for getting that youknowwhat done.
Alright, I buy your argument. Now go and do everything in assembler, right now. Deadline is yesterday. What are you looking at?? Go!!!
You are exaggerating.

Is it only me who likes JS better than CS? :( It's stylish.

Now seriously, it's not just the way it looks. If you never spent at least half an hour playing with a language such as python or ruby, you will probably never know what is it that makes programmers all warm and fussy about their languages. Just take a look at array comprehensions (or list comprehensions in python) to know how succint and powerful they are, and how much clear the code looks. It's about replacing four or more lines of js with just one, readable line of coffeescript (or python).

It's all about power, flexibility, succintness and readability, all things that make programming more enjoyable and fun.

But better expressiveness is exactly what you need to get your shit done. Being able to say what you mean concisely lets you focus on solving your problem and move on to the next task faster rather than getting bogged down into getting some petty details right.
One of the interesting things on doing some analytics on our customer base was seeing just how wide the gap is between the usual HN fare and reality:

http://blog.directededge.com/2010/05/30/what-programming-lan...

The core message being: things like Scala, Erlang, et al still represent a tiny portion of the actual tech world. (And our customers tend to be biased towards being techy anyway.) Just because CoffeeScript gets a lot of mentions in the ultra-early-adopter demographic doesn't mean that it's measurably popular yet.

This is one of the reasons I've transferred most of my enthusiasm for new languages into new problem domains. I've been studying machine learning and DSP for most of the last year and it's done a lot more to revive my passion for programming than learning another new language could have.
Wish I could upvote you more than once. I find the language fetishism - especially for new/"hip"/esoteric languages - in HN and other geek echo chambers kinda annoying and, frankly, silly. There's only so many times one can express the same algorithm using basically different symbols until it gets old. Mastering new problem domains is a better time investment and more satisfactory than learning yet another way to write the Fibonacci function or a String class.
Same here, language fetishim gets old really fast. I think it comes mainly from the new generation of programmers who have not been programming for that long or have not worked on hard enough problems were the language makes very little difference. After having to work on a really hard problem it should hopefully become apparent that what really matters is the algorithm, not the language it is written on. Being obsessed with a language because it saves you a couple of seconds with its unique syntax is frankly quite silly. What takes most of the time is the actual design and figuring out of the algorithms involved. Also debugging takes quite some time. The actual programming shouldn't take that long. A couple of seconds saved because of some syntax will not make an iota of a difference.