Poll: Have you moved from JavaScript to CoffeeScript?
64 comments
I'm the author of the PragProg book on CoffeeScript: http://pragprog.com/titles/tbcoffee/coffeescript
It's heartening to see so many people responding to this poll. I hopped on the CoffeeScript bandwagon more than a year ago; a week of using it was enough to convince me to stop writing pure JS. It's become my favorite language, even overtaking Ruby. (Cue dhh at last month's RailsConf keynote: "Looking at CoffeeScript was the first time I got language envy.")
These last six months have been amazing: In December, CoffeeScript hit 1.0. In April, it officially became a part of Rails. In May, Jeremy Ashkenas gave a talk alongside Brendan Eich at JSConf. That same month, the beta of my book was PragProg's #1 direct seller.
So who knows what the next year holds for CoffeeScript? It's probably never going to take off in cubicle-land—and for that we should be grateful. But I would like to see it get more traction beyond the Ruby and Node.js worlds. (Pythonistas, represent!) And I'm sure we'll see far more high-profile projects written in it... and not just at 37signals.
For web developers, JavaScript is where the action is right now. And CoffeeScript is, in my opinion, the best way to write JavaScript.
It's heartening to see so many people responding to this poll. I hopped on the CoffeeScript bandwagon more than a year ago; a week of using it was enough to convince me to stop writing pure JS. It's become my favorite language, even overtaking Ruby. (Cue dhh at last month's RailsConf keynote: "Looking at CoffeeScript was the first time I got language envy.")
These last six months have been amazing: In December, CoffeeScript hit 1.0. In April, it officially became a part of Rails. In May, Jeremy Ashkenas gave a talk alongside Brendan Eich at JSConf. That same month, the beta of my book was PragProg's #1 direct seller.
So who knows what the next year holds for CoffeeScript? It's probably never going to take off in cubicle-land—and for that we should be grateful. But I would like to see it get more traction beyond the Ruby and Node.js worlds. (Pythonistas, represent!) And I'm sure we'll see far more high-profile projects written in it... and not just at 37signals.
For web developers, JavaScript is where the action is right now. And CoffeeScript is, in my opinion, the best way to write JavaScript.
[deleted]
I agree -- CoffeeScript is the best way to write JavaScript right now. I very recently had a great experience writing a mobile web application using it, and I'm pleased that it's now an official part of Rails.
Like most languages at 1.0, though, it has some growing to do. I still find myself needing to dive down into the compiled JavaScript to make sure it's doing what I think it's doing in some unclear situations (nested data structures we used in our tests, for example). I've seldom found a need to take similar actions in more mature languages and I'm sure that will improve as CoffeeScript development continues.
I warmly welcome any tool that makes my life as a developer easier or more enjoyable (CoffeeScript does both) and I hope its success continues to inspire the growth of client-side web development languages.
Like most languages at 1.0, though, it has some growing to do. I still find myself needing to dive down into the compiled JavaScript to make sure it's doing what I think it's doing in some unclear situations (nested data structures we used in our tests, for example). I've seldom found a need to take similar actions in more mature languages and I'm sure that will improve as CoffeeScript development continues.
I warmly welcome any tool that makes my life as a developer easier or more enjoyable (CoffeeScript does both) and I hope its success continues to inspire the growth of client-side web development languages.
After reading posts about it on here for maybe a year, I recently decided to try it for a small jQuery plugin. I enjoyed it so much that we immediately switched to writing all new code in CoffeeScript and have begun converting existing code as time allows.
The benefits over straight JavaScript are amazing—I’d been writing careful code that drew from the ‘good parts’ mentality and pre-declared all variables, etc. Now I hardly ever have to worry about it.
As I continue to write Rails code I wish I could skip commas in hashes. I didn’t really have an opinion on significant whitespace before (only briefly played with Python) but now I love it. It’s also the first time I’ve used splats, and I was delighted by the brevity it can achieve in combination with the erb-esque interpolation: http://cl.ly/2b371b380g3j071E2g0h
The integration with docco has rewarded my habit of trying to write good documentation. I’ve tried to enforce a policy that any new CS must be documented.
The benefits over straight JavaScript are amazing—I’d been writing careful code that drew from the ‘good parts’ mentality and pre-declared all variables, etc. Now I hardly ever have to worry about it.
As I continue to write Rails code I wish I could skip commas in hashes. I didn’t really have an opinion on significant whitespace before (only briefly played with Python) but now I love it. It’s also the first time I’ve used splats, and I was delighted by the brevity it can achieve in combination with the erb-esque interpolation: http://cl.ly/2b371b380g3j071E2g0h
The integration with docco has rewarded my habit of trying to write good documentation. I’ve tried to enforce a policy that any new CS must be documented.
Is it difficult to debug the resulting code?
Browser implementors are working on making easier to debug all compile-to-JS languages, including regular minified JavaScript code.
https://bugzilla.mozilla.org/show_bug.cgi?id=618650
https://bugs.webkit.org/show_bug.cgi?id=30933
In the meantime, CoffeeScript tries to make debugging easy by compiling to straightforward, readable JS, with meaningful variable names, normal indentation, and all that. Patches to make the output clearer/cleaner for specific bits are always welcome.
https://bugzilla.mozilla.org/show_bug.cgi?id=618650
https://bugs.webkit.org/show_bug.cgi?id=30933
In the meantime, CoffeeScript tries to make debugging easy by compiling to straightforward, readable JS, with meaningful variable names, normal indentation, and all that. Patches to make the output clearer/cleaner for specific bits are always welcome.
Strait forward and readable in many cases but beware:
http://jashkenas.github.com/coffee-script/#loops
To be clear, I think CoffeeScript is an impressive language/abstraction. I just get tired of people selling the Javascript output as always being "straightforward" and "readable".
http://jashkenas.github.com/coffee-script/#loops
To be clear, I think CoffeeScript is an impressive language/abstraction. I just get tired of people selling the Javascript output as always being "straightforward" and "readable".
Beware of what? It does look quite straightforward and readable to me. The JS actually helps me understand the CoffeeScript (note, I have never seen real CoffeeScript code before.) Even the class definitions and destructuring assignment further along are quite comprehensible. I don't even have to qualify that with "for what they do."
What's wrong with those compiled loops?
The only difference from a "hand-written" loop is that you would use `i` and `ln` instead of `_i` and `_len`, and something in context like `numbers` instead of `_results`.
The only difference from a "hand-written" loop is that you would use `i` and `ln` instead of `_i` and `_len`, and something in context like `numbers` instead of `_results`.
There are a total of 9 references to the `_vars`. I think line noise in the compiled javascript is a legitimate counter argument to the claim that its strait forward and readable.
12 if you count the declaration. You'd have exactly the same doing it yourself, you can at most reduce it to 10 by declaring i and ln inside for().
You're also overlooking the fact that this can be considered an advantage: variable naming for these transient uses is very consistent. When writing JS you could have names all over, even a different one for every loop.
You're also overlooking the fact that this can be considered an advantage: variable naming for these transient uses is very consistent. When writing JS you could have names all over, even a different one for every loop.
I've maintained the hoisted index variable and cached the length:
var i, foods = ['toast', 'cheese', 'wine'], foods_length = foods.length;
for (i = 0; i < foods_length; i++) {
eat(food[i]);
}
I didn't say the underscore is good - it's a necessary evil.
I said consistency is good. And you just proved my point.
I said consistency is good. And you just proved my point.
The reason why all declarations happen at the top of the current function body, instead of inline with the first assignment is because in JavaScript assignment is a statement, not an expression. You can't do this:
alert(var
alert
Aren't local variables scoped to be visible within the entire JavaScript function? I thought the recommendation to declare local variables at the top the function was a reminder (or to avoid accidental importing of global variables of the same name)?
I use coffeescript both clientside and serverside (node). Since semantically the coffeescript maps to javascript almost one-to-one, the only debugging difficulty is mapping line numbers in the error output to the location in the coffee file.
Client-side is zero problem because the chrome and firebug developer tools jump you right to the line in the JS file, and you can figure out where the error is there since the compiled coffeescript is very readable.
Server-side has a slight hassle since there's no clickable link, so the line numbers don't help much, but a quick look at the stack trace makes it pretty easy to find where in the coffeescript its referring to.
Client-side is zero problem because the chrome and firebug developer tools jump you right to the line in the JS file, and you can figure out where the error is there since the compiled coffeescript is very readable.
Server-side has a slight hassle since there's no clickable link, so the line numbers don't help much, but a quick look at the stack trace makes it pretty easy to find where in the coffeescript its referring to.
Have you tried using node-inspector for server-side code debugging? https://github.com/dannycoates/node-inspector
Wow this is incredible, thanks for the tip!
I might take this back later, but so far, not really. I thought it was going to be, I keep expecting to run into crazy debugging hurdles, but they just haven't showed up yet. Maybe I'm still at a naive point in my development, and just haven't done anything that would trip it up, but so far so good.
Hasn’t been so far. We’re using the barista gem, which dumps to a JS file.
Most of the problems we’ve dealt with have been due to using new syntax, figuring out when we need parentheses/how to pass anonymous functions, and so on.
Referring to the compiled output definitely helps, but we’re pretty familiar with JS at this point. Not sure how difficult it would be for those with less experience.
Most of the problems we’ve dealt with have been due to using new syntax, figuring out when we need parentheses/how to pass anonymous functions, and so on.
Referring to the compiled output definitely helps, but we’re pretty familiar with JS at this point. Not sure how difficult it would be for those with less experience.
I have used Javascript exclusively on client and server since late 2008. First Rhino and then Node. Before that I used Rails.
I can understand the syntax gripes that some people have towards Javascript but I think this has more to do with a Ruby notion of "elegance" coupled with a lack of familiarity with Javascript then it does with actual issues with Javascript. In fact, I prefer Javascript to Ruby.
I have gone the whole way with Prototype and then the whole way back. These days I prefer using just 20 or so functional DOM helpers rather than Prototype's Element extensions or JQuery's wrappers. A handful of DOM functions are significantly faster. As a result I have found it useful to keep third party dependencies to a minimum. A minimum of zero is working well for me so far. Writing raw Javascript is refreshing, even if it means a "prototype" here or there. I have written many "var" statements and have yet to see an undeclared variable pollute the global scope. I write for loops often. Sometimes I use forEach or reverse while loops. I don't seen any need for Coffeescript enumerators.
I keep checking up on Coffeescript from time to time but I prefer the explicit syntax of Javascript. After spending hours refactoring code the Rails way, I have come to prefer code that's big-O efficient, as fast as possible, as direct as possible, and if it takes a few lines less that's great.
I can understand the syntax gripes that some people have towards Javascript but I think this has more to do with a Ruby notion of "elegance" coupled with a lack of familiarity with Javascript then it does with actual issues with Javascript. In fact, I prefer Javascript to Ruby.
I have gone the whole way with Prototype and then the whole way back. These days I prefer using just 20 or so functional DOM helpers rather than Prototype's Element extensions or JQuery's wrappers. A handful of DOM functions are significantly faster. As a result I have found it useful to keep third party dependencies to a minimum. A minimum of zero is working well for me so far. Writing raw Javascript is refreshing, even if it means a "prototype" here or there. I have written many "var" statements and have yet to see an undeclared variable pollute the global scope. I write for loops often. Sometimes I use forEach or reverse while loops. I don't seen any need for Coffeescript enumerators.
I keep checking up on Coffeescript from time to time but I prefer the explicit syntax of Javascript. After spending hours refactoring code the Rails way, I have come to prefer code that's big-O efficient, as fast as possible, as direct as possible, and if it takes a few lines less that's great.
You may have been misinformed -- the values of direct, raw, fast code are a big part of the reason why CoffeeScript works the way it does, and why many scripts can end up running faster after getting ported to CoffeeScript. The golden rule of CoffeeScript is to avoid adding any library code to the runtime, and to avoid introducing any special calls, to the greatest extent possible.
Many folks rely on a "forEach" (or "each") iterator for all of their loops over arrays, because it's convenient. Unfortunately, it's also a very slow way to write an inner loop. CoffeeScript's comprehensions expand into regular JS loops over arrays and objects, so you get native speed, without the hassle. This:
Many folks rely on a "forEach" (or "each") iterator for all of their loops over arrays, because it's convenient. Unfortunately, it's also a very slow way to write an inner loop. CoffeeScript's comprehensions expand into regular JS loops over arrays and objects, so you get native speed, without the hassle. This:
for item in list
sum += item.amount
var item, _i, _len;
for (_i = 0, _len = list.length; _i < _len; _i++) {
item = list[_i];
sum += item.amount;
}I'd write that snippet the following way:
EDIT: fixed minor oversight
for (var i = 0, ii = list.length; i < ii; i++) {
sum += list[i].amount;
}
for (var i = 0, ii = list.length; i < ii; i++)
sum += list[i].amount;
EDIT: fixed minor oversight
And I'd write
I've used C and Java since high school, but I'm happy to be rid of that old `for` syntax. And I love that curly braces means only one thing in CoffeeScript: "I'm defining a new object with these key-value pairs."
for i in [0...list.length] by 1
sum += list[i].amount
I've used C and Java since high school, but I'm happy to be rid of that old `for` syntax. And I love that curly braces means only one thing in CoffeeScript: "I'm defining a new object with these key-value pairs."
Where are you setting `item` here?
I mean "direct" as in as few abstractions as possible, and "raw" as in as close to the metal as possible.
I am used to writing native loops in Javascript, so taking your example I would usually write:
And I know that forEach loops incur additional overhead so I use them when it's convenient, when the arrays are small. I don't need to compile my Javascript just to keep from accidentally using forEach in situations where native loops would be better. I usually try to think about these things when I code and I enjoy being able to decide when to use a forEach loop, when to use a reverse while or a vanilla for loop etc. Sometimes, it's good to be specific in how you write code.
Furthermore, I would write for loops more succinctly than the compiled CoffeeScript in your example. You can use a for loop to declare the "item", "_i" and "_len" variables inside the loop itself without writing them twice. There's no need for the temporary item variable and the for loop is then short enough to be on one line:
I don't mind typing a few more characters if it means I can get closer to the code and serve smaller, faster code to users (or servers). If it means just one less deployment step, or one less 3rd party dependency, or one less leaky abstraction, it's worth it. I think this proves true in the cases above, where CoffeeScript certainly makes the compiled code longer, slower than it needs to be.
I am used to writing native loops in Javascript, so taking your example I would usually write:
var length = list.length;
while (length--) sum += list[length].amount;
And I know that forEach loops incur additional overhead so I use them when it's convenient, when the arrays are small. I don't need to compile my Javascript just to keep from accidentally using forEach in situations where native loops would be better. I usually try to think about these things when I code and I enjoy being able to decide when to use a forEach loop, when to use a reverse while or a vanilla for loop etc. Sometimes, it's good to be specific in how you write code.
Furthermore, I would write for loops more succinctly than the compiled CoffeeScript in your example. You can use a for loop to declare the "item", "_i" and "_len" variables inside the loop itself without writing them twice. There's no need for the temporary item variable and the for loop is then short enough to be on one line:
for (var _i = 0, _len = list.length; _i < _len; _i++) sum += list[_i].amount;
I don't mind typing a few more characters if it means I can get closer to the code and serve smaller, faster code to users (or servers). If it means just one less deployment step, or one less 3rd party dependency, or one less leaky abstraction, it's worth it. I think this proves true in the cases above, where CoffeeScript certainly makes the compiled code longer, slower than it needs to be.
[deleted]
if order does not matter:
var sum=0,i=list.length; while(i--) sum += list[i].amount;
if it does: var sum=0,i=0,ln=list.length; while (ln-- && (sum += list[i++].amount));
but the for in syntax is nicer indeed.
var sum=0,i=list.length; while(i--) sum += list[i].amount;
if it does: var sum=0,i=0,ln=list.length; while (ln-- && (sum += list[i++].amount));
but the for in syntax is nicer indeed.
Yah but your example for Javascript uses some dubious code. Did you know that "for .. in" loops are also native to Javascript? Why not use one for JS, why only Coffeescript? Also, it seems like you are doing some useless variable declrations.
Let me rewrite it for you: 1)
var list = [{amount:2}, {amount:5}], i, sum = 0;
for (i = 0; i < list.length; i++) { sum += list[i].amount; }
console.log(sum);
2) Or let's go even more simple...
var list = [{amount:2}, {amount:5}], i, sum = 0;
for (i in list) { sum += list[i].amount; }
Personally, i don't find anything difficult about that.. Actually looks incredibly simple. What are you actually saving by using Coffeescript...? Some brackets, parens and a semi-colon? I don't know, those are just second nature for me. I've never really stopped and thought, "wow, if only I didn't have to type these extra parens, this is really killing me..."
Not once.
Let me rewrite it for you: 1)
var list = [{amount:2}, {amount:5}], i, sum = 0;
for (i = 0; i < list.length; i++) { sum += list[i].amount; }
console.log(sum);
2) Or let's go even more simple...
var list = [{amount:2}, {amount:5}], i, sum = 0;
for (i in list) { sum += list[i].amount; }
Personally, i don't find anything difficult about that.. Actually looks incredibly simple. What are you actually saving by using Coffeescript...? Some brackets, parens and a semi-colon? I don't know, those are just second nature for me. I've never really stopped and thought, "wow, if only I didn't have to type these extra parens, this is really killing me..."
Not once.
JavaScript's for-in construct is not the same as iterating through all elements in the array as it will enumerate over all of the object's properties (see here: http://stackoverflow.com/questions/500504/javascript-for-in-...)
The other "complexities" in the compiled JavaScript are there for perf reasons (not accessing the "length" properties in the condition portion of the for loop, for example).
Your comment underlies why some users find CoffeeScript useful in dealing with some of the idiosyncrasies and performance minutiae associated with JavaScript.
The other "complexities" in the compiled JavaScript are there for perf reasons (not accessing the "length" properties in the condition portion of the for loop, for example).
Your comment underlies why some users find CoffeeScript useful in dealing with some of the idiosyncrasies and performance minutiae associated with JavaScript.
Right, for..in is not the same as iterating through all elements in an array. Understood. But it works excellent in the example the OP created and in my follow-up example.
And I agree that accessing the length property in the conditional is not ideal.
I guess it comes down to this for me: I don't feel that Javascript has an unduly burdensome list of common idiosyncrasies to justify developing in a 'different language'/syntax that compiles into javascript and changing my development workflow to reap said questionably useful benefits.
Perhaps I am simply not the intended audience.
And I agree that accessing the length property in the conditional is not ideal.
I guess it comes down to this for me: I don't feel that Javascript has an unduly burdensome list of common idiosyncrasies to justify developing in a 'different language'/syntax that compiles into javascript and changing my development workflow to reap said questionably useful benefits.
Perhaps I am simply not the intended audience.
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.
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.
That shouldn't be surprising. A willingness to learn new and esoteric languages is one of the hallmarks of HN-ers. See also: The Python Paradox (http://www.paulgraham.com/pypar.html).
[deleted]
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.
When I first saw CoffeeScript I thought it was the best thing since sliced bread. I mean, it's beautiful to look at (and enjoyable to write). I was positive that it was going to replace JavaScript in my toolbox. Except, for whatever reason, it never did. It may just be because regular old JavaScript is already familiar, but whenever I needed to knock out any client-side code I'd have half the thing written in JS before I'd even think about CoffeeScript.
I guess at the end of the day syntax didn't end up being a killer feature that I needed. I still think CoffeeScript is awesome, but it doesn't solve problems that I can't already solve in JavaScript.
I guess at the end of the day syntax didn't end up being a killer feature that I needed. I still think CoffeeScript is awesome, but it doesn't solve problems that I can't already solve in JavaScript.
you can try js2coffee which will convert all existing js file to coffee-script.
I see no need to convert my js to coffee just so I can compile it back to js.
FWIW, I used js2coffee on a 400-line JS file powering an app today and the compiled version of the code (js->coffee->js) was noticeably faster than the straight JS version. The for-in efficiency is probably part of that.
A quick way to port once: http://ricostacruz.com/js2coffee/
A quick way to port once: http://ricostacruz.com/js2coffee/
agree. I've never really considered anything about Javascript's syntax to be cumbersome. I've written server-side Ruby and appreciate the syntax...
But two points:
1) The syntax wasn't the only thing that drew me to Ruby. 2) I just don't see an any real need morph my JS code into a similar syntax. Writing JS is pretty easy.
But two points:
1) The syntax wasn't the only thing that drew me to Ruby. 2) I just don't see an any real need morph my JS code into a similar syntax. Writing JS is pretty easy.
SyncPad switched its webclient from JS to CoffeeScript.
In terms of human-readable code, we reduced the lines of code by ~30%. It's cleaner and more concise. I feel our code is more managable because of CoffeeScript.
In terms of the generated JS, I really appreciate that CoffeeScript creates an abstraction that will implement JS best practices and consistency
At this point, any JS work I do is done with CoffeeScript
In terms of human-readable code, we reduced the lines of code by ~30%. It's cleaner and more concise. I feel our code is more managable because of CoffeeScript.
In terms of the generated JS, I really appreciate that CoffeeScript creates an abstraction that will implement JS best practices and consistency
At this point, any JS work I do is done with CoffeeScript
My projects have been the same way; I spend less time writing "function" and more time making stuff happen.
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.
If you feel like providing any more color beyond your vote, your impressions after using CoffeeScript in anger -- I'd love to hear 'em.
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).
* 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).
For debugging, see node-inspector: https://github.com/dannycoates/node-inspector
For details about modules: http://nodejs.org/docs/v0.4.8/api/modules.html
Use the same site for the rest of the API too of course.
I like vows.js for unit testing: http://vowsjs.org/
For details about modules: http://nodejs.org/docs/v0.4.8/api/modules.html
Use the same site for the rest of the API too of course.
I like vows.js for unit testing: http://vowsjs.org/
* npm + bowserify or stich or others
* in firebug / web inspector
* qunit, jasmine etc
repl for node
* 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}/") ; returnThank you both for these links, I am off to a very good start.
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.
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 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.
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 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.
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.
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.
You should really learn Javascript first. Coffeescript is not (yet) a replacement for it, more like a tool.
http://jashkenas.github.com/coffee-script/
http://coffeescriptcookbook.com/
Tutorial/screencast links: http://stackoverflow.com/questions/5124706/is-there-a-screen...
A talk by Jeremy: http://ontwik.com/javascript/jeremy-ashkenas-on-coffeescript...
http://coffeescriptcookbook.com/
Tutorial/screencast links: http://stackoverflow.com/questions/5124706/is-there-a-screen...
A talk by Jeremy: http://ontwik.com/javascript/jeremy-ashkenas-on-coffeescript...
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.
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.
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.
Other than that I see a lot to like in CS though.
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:
https://github.com/languages/CoffeeScript
https://github.com/languages/CoffeeScript
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.
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.
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.
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.
Like many, I read about the cool kids using CoffeeScript for months before I finally tried it.
(I mostly work with Objective-C native apps and Ruby backends, so I'm not a JavaScript programmer--more like a user. A web view needs to frob the DOM or do some AJAX or something.)
A project came up where I needed to write the skeleton for a simple single-page web app component of a larger system. The window has a few panes which need to do AJAX, swap subviews in and out, and react to various inputs. Simple, but it has a few different view controllers and different kinds of data objects, so I decided to use this project to try CoffeeScript.
Comapared with JS, CS is much more concise and instantly readable. I think basically everybody agrees about that. It makes even Ruby feel a bit clunky with all the extra typing. ;-)
But surprisingly, there are no significant drawbacks. Debugging, the issue I had been wondering about, turned out to not actually be a problem at all. Two lines of CS code might be compiled to a sixteen lines of JS, but it's obvious what is going on, and debugging is effectively just as easy as ever.
So, two weeks in, I am reasonably sure that I will never write in raw JavaScript again. I just can't imagine why I would ever again type "function() {" three times to write one spec, or write my own for loop just to iterate a collection, or spend my time mentally filtering out all those braces and semicolons.
Granted, I am not mainly a JS coder, so my perspective is not the same as, say, a frontend dev to whom JS is second nature and 'the good parts' are deeply ingrained. My hunch is, though, that even if I was I would still switch.
The end result is the same, but the process of reading (and writing) the code is much nicer.
(I mostly work with Objective-C native apps and Ruby backends, so I'm not a JavaScript programmer--more like a user. A web view needs to frob the DOM or do some AJAX or something.)
A project came up where I needed to write the skeleton for a simple single-page web app component of a larger system. The window has a few panes which need to do AJAX, swap subviews in and out, and react to various inputs. Simple, but it has a few different view controllers and different kinds of data objects, so I decided to use this project to try CoffeeScript.
Comapared with JS, CS is much more concise and instantly readable. I think basically everybody agrees about that. It makes even Ruby feel a bit clunky with all the extra typing. ;-)
But surprisingly, there are no significant drawbacks. Debugging, the issue I had been wondering about, turned out to not actually be a problem at all. Two lines of CS code might be compiled to a sixteen lines of JS, but it's obvious what is going on, and debugging is effectively just as easy as ever.
So, two weeks in, I am reasonably sure that I will never write in raw JavaScript again. I just can't imagine why I would ever again type "function() {" three times to write one spec, or write my own for loop just to iterate a collection, or spend my time mentally filtering out all those braces and semicolons.
Granted, I am not mainly a JS coder, so my perspective is not the same as, say, a frontend dev to whom JS is second nature and 'the good parts' are deeply ingrained. My hunch is, though, that even if I was I would still switch.
The end result is the same, but the process of reading (and writing) the code is much nicer.
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.
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.
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.
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?
> 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.
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:
But I wasn't using click(), I was using load(), which has a different syntax:
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.
click() works because the callback is given parameter:
.click( handler(eventObject) )
But I wasn't using click(), I was using load(), which has a different syntax:
.load( url, [data,] [complete(responseText, textStatus, XMLHttpRequest)] )
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!
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
});
};
$(".account").click( (function(that) {
return function(e) {
// 'that' now holds a reference to AccountView
})(this);
});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.
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?
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
[deleted]
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).
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'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 think CoffeeScript looks quite cool, but I'm afraid introducing a compilation layer will complicate my life and lead to weird issues which will cancel out any productivity gains. And while Javascript may not be perfect, it's good enough to get the job done.
What's the problem with the extra compilation step?
You can simple use coffeescript by adding "script type=text/coffeescript" tags to your code while developing, and when you are done, just compile and deploy. Or you can simply authomate the task (google for instructions).
Yeah, and what happens when it introduces a weird bug?
As a developer who really loves JS (not because of its syntax - which is fine - but because what I'm able to do with it) I just don't really get CS.
I wan't to be able to debug the code I'm writing in the code I'm writing. The extra layer of sugar seems sickly sweet, nice for a taste but overpowering in bulk.
I think I'm prone to wanting to go lower and seeing how things work in the layer beneath. I'm fascinated by C and assembly languages and how my JS ultimately sits on top of those. I think if CS was interpreted at the same level as JS I'd be more interested.
I guess it really depends on how much you use JS and whether CS makes your work easier. I'm always looking at what complexity I can throw away, I think CS may be just that.
I wan't to be able to debug the code I'm writing in the code I'm writing. The extra layer of sugar seems sickly sweet, nice for a taste but overpowering in bulk.
I think I'm prone to wanting to go lower and seeing how things work in the layer beneath. I'm fascinated by C and assembly languages and how my JS ultimately sits on top of those. I think if CS was interpreted at the same level as JS I'd be more interested.
I guess it really depends on how much you use JS and whether CS makes your work easier. I'm always looking at what complexity I can throw away, I think CS may be just that.
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.
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.
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:
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 + xI'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.
Couchbase shipped coffeescript as an officially supported language for couchdb design documents (views, filters, show and list functions, etc...). I started using it when Jan committed that and have enjoyed it quite a bit since.
As I'm learning couchdb and plan to use it for a project, the coffeescript addition for map/reduce certainly gave me cause to look more closely at coffeescript
I love coffee script. With coffee script and backbone I've been able to take an extra step in creating manageable complexity on the client side. I was never the greatest javascript programmer, and coffeescript allows me to not worry about all the things that tripped me up (prototypical inheritance and all the different ways to implement classes/inheritance) and concentrate on the problems I'm trying to solve with a clear set of rules.
Coffeescript curates the good parts of javascript for you and adds the syntactic sugar that cleans up the gnarliness of javascript.
Coffeescript curates the good parts of javascript for you and adds the syntactic sugar that cleans up the gnarliness of javascript.
If you're interested in checking it out, there's a great ebook on github. https://github.com/autotelicum/Smooth-CoffeeScript
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!
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!
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.
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!
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!
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.
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'd like to use CoffeeScript. Since it's just dabbling, I haven't actually managed to install it. I got caught up on the whole 'watch out NPM is capable of hacking you be wary!' part of the node/coffee install process.
Positive about it, though. I'll be using it in the future but not quite the 'next opportunity'.
Positive about it, though. I'll be using it in the future but not quite the 'next opportunity'.
Funnily enough I started doing some stuff to in CoffeeScript for the first time today. So far it's been a lot of fun. As a Python guy, any language that has meaningful indentation gets a plus in my book. I'm still getting the hang of it, but so far I am considering switching heavily.
I'm currently learning JS, but am preferring to not learn CoffeeScript or jQuery yet, because I feel like I would be avoiding the nitty-gritty of the language with convenient frameworks that pave over some ugly spots. I know that JS is a bit of an aberration in that it has been around for so long in so many places yet has so many fundamental flaws, but it feels wrong that I would have to learn a framework that wraps around the language to protect me from the ugliness of the language. I'd rather face JavaScript full on first, suffer through the process, instead of jumping into CS.
Also, I never understood why some people advocate learning C++ before C. But that's a different debate...
Also, I never understood why some people advocate learning C++ before C. But that's a different debate...
I don't recommend learning CS before JS, because it's a different interpretation of JS, it isn't its own language. In fact, I'm glad I boned up on my Javascript skills (read "The Good Parts" and some solid tutorials) before moving to CoffeeScript.
Moved back from coffee-script because event though all its syntactic sugar is really helpful to program faster, it seems to me that CS lacks clarity and still has too many ambiguities.
YES! And we've never looked back. Indepth blogpost here: http://9elements.com/io/?p=551
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'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.
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 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.
I love cs with all my heart. It makes client-side programming fun and enjoyable. It made me forget my dream of having someday python running in the browser. Cs is just as good. My only criticism is that sometimes, leaving out parens mames the code hard to decipher. I feel that explicit parenthesis make everything clear, but that's probably because I come from python...
At HotelTonight we use CoffeeScript everywhere we'd normally use JavaCript. This includes our "native" (Titanium) iPhone app.
Being a Ruby shop, CoffeeScript (CS) has been a choice for us. We simply find it is a good fit for our minds and how we like to write code, makes it that much easier to structure and organize code nicely, and is more pleasant to look at day in and day out.
Being a Ruby shop, CoffeeScript (CS) has been a choice for us. We simply find it is a good fit for our minds and how we like to write code, makes it that much easier to structure and organize code nicely, and is more pleasant to look at day in and day out.
I suspect CoffeeScript will have a fairly high adoption on people that do use JavaScript only from times to times (like me).
At HotelTonight we are 99% Coffeescript, including our "native" (Titanium) iPhone app.
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.
Anyway, CS would be my second choice but that’s just because I work in .NET environment.
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?
As far as I know CoffeScript requires node.js, npm and cygwin. Am I wrong?
You can compile CoffeeScript's on Windows with this tool:
https://github.com/alisey/CoffeeScript-Compiler-for-Windows
And it doesn't require cygwin. I haven't tried it myself but it's the route I would go.
https://github.com/alisey/CoffeeScript-Compiler-for-Windows
And it doesn't require cygwin. I haven't tried it myself but it's the route I would go.
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.
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.
If you're using CoffeeScript without Node, you're missing out. Fortunately, Cygwin-free Windows support is on the roadmap for Node 0.6.
Using CoffeeScript and not looking back.
class Awesome extend JavaScript
Primarily I use GWT, but occaisionally I'll do some pure js just for fun. Coffeescript doesn't have any particular features that I need, and I'm perfectly happy using js.
Missing option: will be using CoffeeScript on my next project.
It sounds such a simple change I don't feel the need to learn it, just to give myself a bit of time before I next plan to use javascript.
[deleted]
I never got my hands warm with JavaScript but CoffeeScript opened up a huge new world for me :)
Yes I have, I'm even creating all my plugins in CoffeeScript from now one.
No, I still use Java Script and not CoffeeScript
I still don't see the bloody point.
I still don't see the bloody point.
Dude, this poll is useless.
If someone is voting here, chances are that he was looking for info on coffeescript, so he is already aware of this slanguage and is interest in it. The rest of mankind may not know wtf is coffeescript...
Use both, but have a tendency to start new things in coffee
for new projects yes, haven't started migrating old stuff yet. Rails 3.1 will be when I migrate my client's javascript.
I am moving to it. So far so good.
Considering CoffeeScript
No. Mostly because of the egregious use of significant whitespace :(
yupp i have. coffeescript is gr8!
Intending to use CoffeeScript really soon!
No, I do not use CoffeeScript.
How is other different from I don't use either?
yes
What no JQuery option?
Yes
I started writing some of my code in coffeescript a while ago, but then I started a coffeescript project that grew into a file of 2000 lines and it became very hard to skim the code and gather meaning from it because of the lack of parenthesis and the indentation-based nature of it.
If your file is disorganized, I bet spaces and parentheses have very little to do with it.
You can still use parenthesis if you find them more readable. Coffeescript won't complain.
In what language do you routinely find 2000 lines files that are skimmable? Best to split it up logically, problem solved.
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.
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.
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.
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.
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.