Hacker News Reader

Oh wow, that is strange. Bundling CoffeeScript support is an great idea. Setting it as the default seems very non-user friendly to me. I love CoffeeScript, but if I was just picking up Rails and felt like I had to learn it I'd be pretty discouraged.

I know that you could always change it back to regular JavaScript, but I think many people's experience is that it's almost always recommended to use the defaults when learning a new framework.

For the record, SASS/SCSS is also slated to be the default CSS compiler.

http://twitter.com/joshpeek/status/58187372789104640

I'm actually more OK with this as simply because SCSS is a superset of CSS--you can continue to write plain CSS in an SCSS file and it will work exactly as expected. My understanding is that the same is not true of CoffeScript.

You can embed javascript if you want:

http://jashkenas.github.com/coffee-script/#embedded

Totally agree - and the HAML/SASS argument is perfect. We talk a lot about web standards and doing things that are "native" to the web, but abstracting things like HTML/CSS/javascript (by default) don't fit with that mindset.

I like CoffeeScript, and it does feel Rubyesque, but I just don't support it being the default.

That said, I'm sure a core member will post about the decision, and I almost hope they convince me otherwise. I do really like CoffeeScript, and patio11's comment about HAML/SASS is a good one.

Why doesn't it fit with the mindset? Is a program written in C less "native" because you didn't write it in bare machine language?

I find this argument totally bogus (at least, currently). 30 years ago; there were often very good reasons to write assembly over C when working on performance sensitive code. Before that, there were good reasons to write native binary for performance sensitive areas. As assemblers (and subsequently C-compilers) matured, they are often able to generate more efficient code than the vast majority of people could write by hand.

I'm not at all convinced that CoffeeScript has yet matured to the point where it can generate better javascript than any qualified JS developer. Now, it may get there some day--but I don't believe it's there yet.

Moreover, in this case, you're introducing an additional layer of complexity and source of errors--the compile time of CoffeeScript. Maybe it doesn't compile. Maybe it compiles such that the Javascript doesn't do what you intended the javascript to do. Maybe the javascript breaks in some browser environments and there's no way to cleanly work around that problem in CoffeeScript.

Again, it's not that I'm against CS--I'm simply against it being the default. It's an additional can of worms that I don't think the majority of Rails developers are ready and / or willing to open.

Actually, CoffeeScript does generate more efficient code than the vast majority of JavaScript developers write by hand -- that's one of the goals. There are a couple reasons why this is the case, for example:

Do you tend to write your "for" loops with an "each" ? If you're using "$.each", "_.each", or "[].forEach", your loops are running a good bit slower than they could be. This CoffeeScript:

    for item in list
      item.marked = true

Generates this JavaScript:

    var item, _i, _len;
    for (_i = 0, _len = list.length; _i < _len; _i++) {
      item = list[_i];
      item.marked = true;
    }

... where you have a nice length-cached loop that runs about as fast as JavaScript is capable of.

Similarly, lots of JS developers avoid using prototypes because they're such a pain in the ass to type out manually -- preferring to manufacture objects via closures instead. This has a huge runtime and memory cost. CoffeeScript's "class" keyword makes it easy to work with JS prototypes effectively, without having to type out "Klass.prototype.method = function ..." all the time.

You're using a comparison between an each method that takes a callback and for loop--that's a pretty weak comparison to draw as the implications are well-known. Moreover, in two of the 3 cases, they're library methods that aren't part of the Javascript language so the concept is a bit disingenuous. In this case, you're comparing two different types of syntactic sugar and saying that one produces better code than the other--far from making a case that for something more complicated than a single for loop, CS can produce higher quality code than an engineer writing javascript.

The point is that people writing real applications often avoid JavaScript's for-loop in favor of each-loops just because the latter are so much more readable and less bug-prone, and ease of reading the code is worth a little bit of performance in most people's minds. CoffeeScript gives you the readability without the performance tradeoff.

Yes, but many of us aren't 'Javascript engineers', we're more general developers. Learning CS and JS together has vasty improved my JS skills because every time I've gone 'why the heck did CS compile to that?' it's been because of some obscure JS idiosyncracy that would otherwise come back to bit me months or years later...

CS has immediately improved the performance of my code considerably.

Those 'each' examples aren't sugar, they're functions. They don't produce code, they are code. To make them faster, you have to use the more verbose for loops in their place.

Sure, a JS developer could write out the for loop each time, but doing so is less readable and more error prone. You could even stick with the each approach and replace with for-loops after profiling, but then you have to actually do the profiling and rewrite your code to get the benefit.

The JavaScript that gets produced by CoffeeScript is pretty predictable and way more readable than I expected it would be when I first started using CS. Once you use it for a while, you pretty much know what your underlying JS is going to look like, and if you ever do run into any truly hairy sections that just have to be JS, you can write that JS in the same file.

Just out of curiosity, do you use CoffeeScript for all your underscore.js and bakckbone.js development?

Nope. Both of those are JavaScript libraries aimed towards widespread adoption by JavaScript users, and therefore aren't written in CoffeeScript.

That said, I did port Underscore.js to CoffeeScript once, and the resulting compiled JS ran (a little bit) faster than the original version.

Why does that stop you from writing them in CoffeeScript, especially if it's faster? Because you want contributions back to the projects from JS-only developers?

Yep. I'm a pragmatist at heart. I don't think that either Underscore.js or Backbone.js would have gotten the same sort of adoption they've seen (eg. github.com/popular/watched) if they had been written in CoffeeScript. Perhaps in a year or two it would be different.

I'm not trying to settle the argument once and for all with this single analogy, I'm just saying that compiling standards-compliant code instead of writing it directly does not violate the principle of complying with standards.

The reasons for writing C over asm are very different to writing CS over JS.

For one, CS doesn't abstract away any platform dependance in JS - it is syntactic.

which is fine, just that your argument isn't.

"The reasons for writing C over asm are very different to writing CS over JS."

I didn't say they weren't--I just said that generated or compiled standards-compliant code is still standards compliant.

After about a day of thinking on this, I think I've come around. I still don't think I would have pulled the trigger on this, but I respect the people that did.

And, again, I absolutely love CoffeeScript and support it 100%. I'm less infatuated with HAML and SASS, but it may simply be that I haven't used them enough. SASS in particular looks very useful.

Regardless, I agree with DHH's tweet yesterday [1] that Rails is a curated set of ideas/technologies. Pretty much by definition it's not one-size-fits-all. I think this is the first time I've found myself on the opposite side of a Rails technology switch decision, which is pretty amazing. I'm looking forward to giving it a chance, and I can always switch back, if it doesn't work out.

[1] http://twitter.com/#!/dhh/status/58286524151775232

Jose Valim commented on the commit:

This is going to be in your generated Gemfile only. It can still be swapped, removed or replaced as everyone is used to do when it comes to prototype/jquery.

I still believe my original comment stands; allowing it to be disabled is the wrong choice. Allowing to be enabled easily is a far better option, imo.

DHH seems fairly convinced that CS "lifts JS/CSS handling in Rails to a whole new level. Very excited to have this as part of Rails". So it would seem the point of making it default is to make it so one can't think of Rails and not CoffeeScript.

I don't really have an opinion either way as my JS skills are minimal and I know almost nothing about CS.

Arguably, newcomers to whom using CS instead of JS would be a challenge are precisely those who should be encouraged to switch.

That aside, yes, I do think you're reading it wrong— since CoffeScript compiles straight into JS, there isn't really any meaningful way for it to "replace" it. It's just adding a layer on top.

I've said before that CoffeeScript is not a "replacement" or "alternative' to JS since it "compiles" to javascript--but in this case you're talking about providing source that users will have to interact with in a language in which they may not be familiar. Yes, it ultimately becomes Javascript--but what about the javascript developer who wants to learn rails?

I'm sure coffeescript is a fine language in its own right--but the fact that it has to generate Javascript code rather than something lower-level is frustrating to me. I haven't dug into it enough to know; but my gut tells me that (like other examples of code attempting to "compile to another programming language") the output from the "compiler" is less than quality code. Maybe, in most cases, this is fine. In some environments though where performance is at a premium, I don't know that CS will output well optimized code.

All I can say is you should dig into it. Your gut is thoroughly misinformed.

Your gut feeling isn't exactly misguided, since it's generally a safe bet that $LANGUAGE generates suboptimal code, but it's wrong in CoffeeScript's case. CoffeeScript's generated code is much better optimized than 99.99% of the code you'll read out there.

BTW, I'm the one who accidentally downvoted you. Sorry about that. I need to be more careful with the clicking.

> default scripting language for Rails

I guess I'm somewhat out of the loop when it comes to Rails, but why does something written in a scripting language need a scripting language?

default frontend scripting language

It only affects the project skeletons that Rails emits when you tell it you want a new controller or whatever.

It's pretty minor, but you know how nerds get when they smell blood.