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.
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.
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).
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.
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'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).
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.
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.
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.
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.
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.
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.
Sure, no HN poll is ever accurate, but as a rough sense, it's still quite useful. For more measured results, you can look at language popularity on GitHub:
If you feel like providing any more color beyond your vote, your impressions after using CoffeeScript in anger -- I'd love to hear 'em.