6 ms·

If I'm reading it correctly (and I'm not a Rails guy so I may be mistaken) they're making CoffeeScript the default scripting language for Rails. This strikes m

If I'm reading it correctly (and I'm not a Rails guy so I may be mistaken) they're making CoffeeScript the default scripting language for Rails. This strikes me as a really unfortunate decision. There's a world of difference between fully supporting something and making it your default. Making newcomers jump through hoops to get regular javascript instead of CS (another language in which they may not be familiar) just seems like a poorly thought out plan. As someone pointed out in the GitHub comments; this is just like making HAML and SASS the defaults over HTML & CSS. I'm not saying anything negative about these libraries; I'm certainly not an authority on them and can't speak to their effectiveness. However, the net result of a default change such as this one is reduced accessibility to newcomers. Of course, if I'm reading it wrong and this is really just adding support for CoffeeScript to Rails, then disregard everything I just said. :) Edit: well, don't disregard it--remember it for the future!

jonsmock 16y ago
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.
- philwelch 16y ago
  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?
  - bcrescimanno 16y ago
    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.
    - jashkenas 16y ago
      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.
      - bcrescimanno 16y ago
        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.
        chc 16y ago
        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.
        mmavnn 16y ago
  - nikcub 16y ago
    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.
    - philwelch 16y ago
      "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.
- jonsmock 16y ago
  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 http://twitter.com/#!/dhh/status/58286524151775232
Cushman 16y ago
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.
- bcrescimanno 16y ago
  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.
  - Cushman 16y ago
    All I can say is you should dig into it. Your gut is thoroughly misinformed.
  - chc 16y ago
    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.
icey 16y ago
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.
julianb 16y ago
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.
- bcrescimanno 16y ago
  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.
  - marcomonteiro 16y ago
    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.
jashkenas 16y ago
For the record, SASS/SCSS is also slated to be the default CSS compiler. http://twitter.com/joshpeek/status/58187372789104640 http://twitter.com/joshpeek/status/58187372789104640
- bcrescimanno 16y ago
  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.
  - jazzyb 16y ago
    You can embed javascript if you want: http://jashkenas.github.com/coffee-script/#embedded http://jashkenas.github.com/coffee-script/#embedded
jpr 16y ago
> 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?
- lenary 16y ago
  default frontend scripting language
- technomancy 16y ago
  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.

jonsmock 16y ago

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.

philwelch 16y ago
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?
- bcrescimanno 16y ago
  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.
  - jashkenas 16y ago
    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.
    - bcrescimanno 16y ago
      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.
      - chc 16y ago
        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.
      - mmavnn 16y ago
- nikcub 16y ago
  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.
  - philwelch 16y ago
    "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.
jonsmock 16y ago
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 http://twitter.com/#!/dhh/status/58286524151775232

Cushman 16y ago

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.

bcrescimanno 16y ago
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.
- Cushman 16y ago
  All I can say is you should dig into it. Your gut is thoroughly misinformed.
- chc 16y ago
  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.

icey 16y ago

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.

julianb 16y ago

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.

bcrescimanno 16y ago
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.
- marcomonteiro 16y ago
  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.

jashkenas 16y ago

For the record, SASS/SCSS is also slated to be the default CSS compiler. http://twitter.com/joshpeek/status/58187372789104640 http://twitter.com/joshpeek/status/58187372789104640

bcrescimanno 16y ago
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.
- jazzyb 16y ago
  You can embed javascript if you want: http://jashkenas.github.com/coffee-script/#embedded http://jashkenas.github.com/coffee-script/#embedded

jpr 16y ago

> 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?

lenary 16y ago
default frontend scripting language
technomancy 16y ago
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.