11 ms·

Rails 3.1 shipping with CoffeeScript

320 points by bjonathan 16y ago

bcrescimanno 16y ago
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.
        16y ago
  - jonsmock 15y 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 15y 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.
patio11 16y ago
Normally, I'm skeptical of "change the syntax and your life will magically get better, no matter how headachey interacting with the rest of the world will become", but then Thomas showed me Sass and it was lifechanging. (After you've gotten around Sass, CSS looks like Assembly code to a web programmer. I mean, sure, you could write it... but you'd need a damn good reason to. If you haven't tried it yet, make yourself an excuse for a weekend project -- it will make your life better.) Has anyone found CoffeeScript to be lifechanging?
- icey 16y ago
  Yes, CoffeeScript is amazing. No more headaches over missing semi-colons, callbacks feel significantly less "spaghetti-like". Syntactically it feels much cleaner and I've found that I end up staying much nearer to the left margin than I did with JavaScript. Debugging has not been a problem for me yet, the generated JavaScript is very clean and easy to navigate. That being said, I'm a Python fan, so I consider significant whitespace to be a feature, not an irritant.
  - DanielRibeiro 16y ago
    Second that. Coffeescript is really life changing. A very DSL friendly language, where beautiful code can rival python's[1] [1] http://metaphysicaldeveloper.wordpress.com/2011/03/31/354/ http://metaphysicaldeveloper.wordpress.com/2011/03/31/354/
    - icey 16y ago
      Now I have to put on my fruity hippie developer hat. I feel like it makes a big difference when a language implementor values beauty in code. CoffeeScript was created by someone who values the aesthetics of code, and it shows. The CoffeeScript documentation is a fantastic exposition of that: http://jashkenas.github.com/coffee-script/ http://jashkenas.github.com/coffee-script/
      - Cushman 16y ago
        Indeed. Newcomers usually describe CS as "Pythonesque" (because of significant whitespace) or "Rubyish" (because of optional parentheses) depending where they're coming from. I find that a little funny. Truth is, it's borrowed from both, and other languages besides, to synthesize a gorgeous syntax which is really its own.
caioariede 16y ago
By default, really? I don't like the idea neither I'm a Rails developer, but I think that this will increase the learning curve. Let it be just a choice.
- scottbessler 16y ago
  It being a default is not mutually exclusive with it being a choice. I like the move, defaults should be used to push forward positive change and very few if anyone seems to have said they would rather not use CoffeeScript.
- stanleydrew 16y ago
  Choices are kind of antithetical to rails's core philosophy of convention over configuration.
  - jarin 16y ago
    I think it is requiring the user to make a choice that is antithetical. You can change pretty much all of the defaults in Rails.
    - stanleydrew 16y ago
      Agreed, and that is indeed what I meant. Coffeescript has always been a choice in the sense that I could download the compiler and use the output in my rails project.
  - sabat 16y ago
    It will remain a choice. Rails doesn't obliterate choices, just makes it easier if you're willing to take defaults. On the other hand, replacements for default components (e.g. Rspec vs. default Test::Unit) are generally simple to drop in.
- jarin 16y ago
  Rails is a pretty huge learning curve in and of itself, as most developers need to learn MVC, unit testing, migrations, activerecord, callbacks, filter chains, routing, erb, view helpers, partials, layouts, etc. Of course, all of this stuff makes your life easier once you learn it. I would even be down with making Haml and Sass the default, since most Rails developers seem to use them anyway. Scaffolds would give newbies a good starting point to work with.
ddagradi 16y ago
Really? Everyone seems to be freaking out as if Rails will no longer serve your standard JavaScript files again. Rather, by default, the generator spits out CoffeeScript templates. If you don't want to use CoffeeScript, don't use CoffeeScript and write regular JavaScript instead. Will this confuse new users? Probably not, since the template file is going to include instructions and an explanation. Will the change break any existing sites? I really doubt it. In the end, encouraging a better default language is a great change. New users are already required to learn to write ERB/Haml to make a Rails app; this is no different, and easily ignored if you're not interested.
- KarlFreeman 16y ago
  Couldn't agree more with you. Good points.
- icey 16y ago
  Don't you feel it would have been more prudent to start by bundling CoffeeScript support and then changing the default in a later version? It seems like an overly aggressive goal to do both things at once.
  - jarin 16y ago
    One of the core strengths of Rails is that it is highly opinionated. That's why people talk about doing things "the Rails way". You can always change things if you like (a lot of people change the views to Haml, UJS library to jQuery, and test framework to Rspec), but it assumes sensible, working defaults.
    - icey 16y ago
      Excellent point. Not being a Rails guy I sometimes forget that being opinionated is considered one of its strengths. If any framework can get away with doing something like this, it'd be Rails. At any rate, I'm excited about anything that increases CoffeeScript adoption.
  - ddagradi 16y ago
deleted 16y ago
[deleted]
bonzoesc 16y ago
Is Rails 3.1 going to depend on having both a ruby interpreter and a JS interpreter (presumably node?) capable of running coffeescript installed?
- sabat 16y ago
  CoffeeScript isn't interpreted; it's not its own language. You write CoffeeScript code, which resembles simplified and cleaned-up Javascript, and then run a parser over it which converts it to standard Javascript. You'll need CoffeeScript (gem) installed in this situation, but that's just another Rails dependency. EDIT: I should point out that Rails will use CoffeeScript for client-side (browser) code, not server-side code. That remains Ruby and associated DSLs.
  - bonzoesc 16y ago
    The coffeescript compiler is written in coffeescript (and compiled to JS), so in order to serve a .coffee file you'll need to compile it, which requires JS. The commits add a dependency to the coffee-script[1] gem, which requires the execjs[2] gem, which requires some way of running JS. 1: https://github.com/josh/ruby-coffee-script https://github.com/josh/ruby-coffee-script 2: https://github.com/sstephenson/execjs https://github.com/sstephenson/execjs
    - thenduks 16y ago
      If you don't have a method of running JS available then everything will be as it was. This change only introduces the default contents of a rails app's Gemfile (/bundle) and it's generators.
    - sabat 16y ago
      I didn't realize it was more than a parser; thx for the info.
- JonnieCache 16y ago
  No. Coffeescript is not going to be run inside the rails stack. That would be controversial. All that's happening is by default the scaffolding generator scripts will spit out boilerplate coffeescript rather then boilerplate javascript. All that's needed to change back is to comment out a single, clearly marked line of code.
djacobs 16y ago
I have no problem with Rails supporting CoffeeScript out of the box, as the abstraction is really good at showing the power of Javascript and not emphasizing its bad parts. (And, come on, list comprehensions in Javascript? Awesome.) No one is taking away your raw Javascript, it'll work just fine. This just makes it easy for people to use CoffeeScript when they first build an app. It's more of a statement than anything else.
- MatthewPhillips 16y ago
  I disagree. If someone is starting Ruby for the first time, the last thing they want is to be forced to learn another new language on top of learning Ruby. Then mix in Sass and Haml, and you're giving them a good reason not to even bother.
  - djacobs 16y ago
    Who's forcing? Javascript will work just fine.
    - billybob 16y ago
      It's a valid point, though. "So, it's your first Rails app, eh? Do you know Ruby? No? Do you know HAML and SCSS and Coffeescript? No? OK, step 1 in this new framework that you know nothing about is to figure out how to change the defaults." This change definitely has the existing Rails community in mind. Or as I told my friend: "Given that you already know how to create a blog in 5 seconds, how can we also make you not have to use semicolons in your JS?"
      - thenduks 16y ago
        Ok but you don't have to 'change' any 'defaults' to use regular plain javascript. You just don't write coffeescript. The new 'default' is to include the coffeescript dependency and generate script stubs with a .coffee extension. Write a js file and all will be as it was, with a slightly fatter bundle.
JonnieCache 16y ago
Calm down boys and girls, its opinionated software, remember? That's kinda rails' raison d'être. I'm just disappointed they didn't have the balls to make HAML the default templating engine.
- bcrescimanno 16y ago
  And the HN crowd is an opinionated crowd--just because Rails is opinionated doesn't mean that we can't disagree with it's opinions. :) Edit: Rails is also about "sensible defaults." I'm not sure that making CS the default is really the "sensible" choice.
  - JonnieCache 16y ago
    You raise a good point. Good thing rails is so modular since version 3, replacing bits of it like this is completely trivial. Personally I'm more interested in the real 3.1 goodness: flushed responses. The implementation is fascinating. http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/ http://yehudakatz.com/2010/09/07/automatic-flushing-the-rail...
- andycroll 16y ago
  I'm pretty sure DHH isn't a fan of HAML. Think he's make it clear on a 37s podcast or on Twitter in the past (tried searching but couldn't find a citation).
  - rbxbx 16y ago
    I know I personally have argued with him about it. He's very much in favor of ERB.
    - stephth 16y ago
      could you share the gist of his opinion?
      - 16y ago
MatthewPhillips 16y ago
Am I the only one who thinks they are propping up their successor? If you're going to learn Coffeescript, why bother with Rails at all? Just write cs both server and client side. When some one builds a mature node.js MVC framework, Rails is going to be in trouble.
- ascendant 16y ago
  Express is on the right path. I picked it up for the first time last weekend and liked it.
  - MatthewPhillips 16y ago
    It's not MVC though, right? I prefer something more lightweight like Express/Sinatra, but a lot of people are in love with MVC.
    - JonnieCache 16y ago
      It's pretty damn MVC. Just because it doesn't make you define classes with 'Controller' in the name doesn't mean it isn't MVC.
      - MatthewPhillips 16y ago
        I'm with you now. The example on the homepage isn't MVC, but I see from the further documentation that you can incorporate views. Nice.
        ascendant 16y ago
        Yeah, and the default template language (Jade) is a lot like HAML. In fact, I think there's HAML/SASS plugins, but I'm pretty new at Express so don't take that as gospel.
    - deleted 16y ago
      [deleted]
danest 16y ago
"Yes, it's true, Rails 3.1 is going to ship with CoffeeScript and SCSS in the box for use with the new asset pipeline. It's bad ass." @dhh http://twitter.com/#!/dhh/status/58207700672200704 http://twitter.com/#!/dhh/status/58207700672200704
deleted 16y ago
[deleted]
Aqua_Geek 16y ago
If nothing else, the core team's decision to make it default has piqued my interest in learning CoffeeScript. Anyone know of any good resources off-hand to start digging in to it? I assume their website is the best place to start... (http://www.coffeescript.org http://www.coffeescript.org)
- swaits 16y ago
  Yep, just play around with the "Try CoffeeScript" interface they have right on the site. You can actually get pretty far with it right there. Open another window for reference, and start hacking away. Watching the transformations as you code is really interesting.
mberning 16y ago
I love this kind of stuff, but at the same time, it presents a huge problem for software maintainability and building a scalable development team. When I go to hire somebody it is a near certainty that they are very proficient with CSS. Sass? Probably less likely. For the sake of argument let's say I could find somebody proficient in Sass, what about all the other boutique technologies I have in my product? At some point your product can devolve into an opaque and indecipherable hodgepodge of 'cool stuff'. Sometimes it really is better to keep things simple, even though you are causing yourself some personal pain.
- carbon8 16y ago
  The CSS person doesn't need to know Sass in order for the project to benefit from it. At the very least, you could just dump the CSS in an .scss file and just use the automatic output formatting feature. In my current project I take it a step further. I get the CSS from a designer, dump it in an scss partial, include that partial in the main sass/scss file where I then override and add styles. That way I can keep their CSS versioned and untouched while being able to automatically combine it with additional styles into a compressed CSS file. The point is that there are plenty of ways Sass is incredibly useful even if the main CSS person doesn't work with it directly. Obviously Coffeescript is a little different, but the advantage is that a Javascript developer is a programmer and it's not an unreasonable expectation for them to be able to get up to speed on Coffeescript.
- jarin 16y ago
  It really doesn't take much to gain basic proficiency with SASS, as long as you know how to use the tab and delete keys (or the sass-convert tool). With SCSS it's even easier, just rename the file and refactor it later if you're feeling lazy. On a practical note, I've subcontracted out design work before and convinced (strongarmed) the designer to learn SASS. They're usually pretty happy about it.
- dhh 16y ago
  Have you actually looked at SCSS? This is a good start: http://sass-lang.com/ http://sass-lang.com/. It's a superset of CSS. Very easy to learn. Also, this "huge problem" you talk about is the same that people used to argue against Ruby/Rails with. Hey, everyone knows Java/Struts -- let's just keep it simple for hiring drone purposes!
hoopadoop 16y ago
There is going to be some overlap of concerns once all of Sproutcore has been integrated into JQuery.
augustl 16y ago
Rails has a history of doing things with JavaScript that many developers disagree with. RJS is a prime example, where you would write Ruby code that generated JavaScript that assumed you used the Prototype.JS framework. And it wasn't until Rails 3.0 we got view helpers that didn't inline JavaScript. So in my opinion we had one minor version with JavaScript I could relate to, and now we're back to where we were. But I don't mind, I'll just avoid using it.
- dasil003 16y ago
  Yeah RJS was a clusterfuck, but hindsight is always 20/20. At the time it was a new idea that was being explored that just didn't pan out. The Prototype dependency dates back to 2004 when no framework had AJAX support, and the code just started getting stale from there and didn't get any attention until Rails 3. Anyway, I agree that Rails core has traditionally been far from the savviest of JavaScript developers, but the nice thing about Rails 3 is that they've finally achieved reasonable modularity with all the components, so there's not much pain in getting around Rails opinions anymore. As for CoffeeScript, I'm still on the fence, but it's clear that Jeremy Ashkenas knows his JavaScript, and his work is not done out of ignorance, so I'm glad for it to get more exposure.
  - bstar 16y ago
    I guess I'm just amazed that they (rails core) haven't learned from the RJS mistake. These 'fads' to get around JS syntax are terrible as standards. What is so wrong with writing idiomatic, unobtrusive JS? I personally don't care for JS syntax (compared to the beauty of ruby and haml), but that's life... JS syntax my be ugly, but it can be written elegantly.
    - dasil003 16y ago
      What's there to learn from the RJS mistake? RJS was fucked because it attempted to pretend JS didn't exist and muddled the separation of concerns between client and server-side; CoffeeScript makes no such mistake. CoffeeScript is much more like HAML/SASS in function, and while there are arguments against those in some environments (like if you need to hire a lot of designers without a dev mentality or environment), they've been proven to be very effective in practice, and I'm quite sure CoffeeScript will be the same.
aneth 16y ago
It's interesting that rails is headed toward whitespace significance in all its file formats, yet the most apparent difference between ruby and it's main rival Python is that whitespace is not significant. Between yaml, sass (although not scss), haml, and coffescript, is the next step a version of ruby getting rid of end statements in favor of whitespace? I've often dreamed of such a thing. module Foo module Bar class Fubar def boom p "I like monkey patches" end end end end Ick!
- generalk 16y ago
  > It's interesting that rails is headed toward whitespace > significance in all its file formats, yet the most apparent > difference between ruby and it's main rival Python is that > whitespace is not significant. That may be the most obvious difference at first glance, but it's also the most superficial. Idiomatic Python and idiomatic Ruby will be written completely differently.
oomkiller 16y ago
I don't understand what the big deal is here. All this patch does is make a application.js.coffee instead of application.js, and add support for actually generating JS from this. One of the recurring arguments I've seen is that this change will make it harder for people to get started with Rails. I really don't understand how this is the case, because if you understand what public/javascripts is for and what javascript_include_tag does, you should also be able to write normal javascript all day long. Hell, you don't even need that, adding your own HTML to include a script into the page works too (as always). There is no need to write CoffeeScript if you don't want to/don't know how to; write all the js you want. In reality, the only outcome of this will be more people discovering and learning CoffeeScript. I seriously doubt this will discourage anyone from learning Rails. If it does, they were bound to find something that discouraged them eventually.
jaekwon 16y ago
i know what i'm using for my next project now.
trustfundbaby 16y ago
I don't like that its the default, it seems like something the 37signals guys like (pow was written in coffee script) so "goshdarnit! all of you have to use it". Yes I know, you can change it. Yes. I know its impact is probably minimal if I don't care for it. But, I really would like to see a strong argument made for why this should be a default for Rails, especially when SASS and HAML, which have wider adoption and facetime with the Rails community aren't the default (and I think, rightfully so)
smoody 16y ago
IMHO, this smells like a marketing move -- in the same way that merging Rails and Merb was a (brilliant) marketing move. If Rails wants to stay "cool" (and if you believe that "cool" is a zero sum game), then Rails has to stay buzzword compliant. Yes, Rails has a lot of support but the Rails team isn't stupid and they know, by definition, that it's just a matter of years before Rails itself becomes something of a relic -- one kids know of only because their daddies and mommies used to use it.
- dasil003 16y ago
  You're stuck in 2004, when DHH poked Java in the eye to get attention; that was a marketing move. It's been years since Rails had to do any marketing. The Merb merge was about bringing incredible ideas into Rails, and it shows in Rails 3. Similarly, CoffeeScript is being defaulted because DHH believes it's a better way to write JS. He has better things to do than make contrived technical decisions to stir up controversy. If you disagree than I pity your paranoia.
digispaghetti 16y ago
Shameless self-promotion here, but if you want to try CoffeeScript and are using the Cloud9 IDE I wrote an extension so you can see your coffeescript output live: https://github.com/tanepiper/cloud9-livecoffee-ext https://github.com/tanepiper/cloud9-livecoffee-ext
nightlifelover 16y ago
Just wondering is there a framework like Rails written in JS? Using JavaScript and V8 on the server side makes a lot of sense since V8 is much faster then the Ruby interpreter..
- nevinera 16y ago
  Express is fairly rails-like (for node.js).
  - telemachos 16y ago
    Maybe a fairer comparison is Sinatra? That is, Express is a lot slimmer than Rails and works via a DSL based around the HTTP verbs[1]. Another JS framework to look at is Backbone[2]. [1] http://expressjs.com/guide.html#routing http://expressjs.com/guide.html#routing [2] http://documentcloud.github.com/backbone/ http://documentcloud.github.com/backbone/
    - nevinera 16y ago
      That would definitely be a fairer comparison, but he was asking for 'a framework like rails'; Express is the closest.
- CWIZO 16y ago
  Have you tried node.js?
  - te_chris 16y ago
    Node isn't really a framework. It's a server-side runtime environment for javascript. You could totally do something cool with it, Express js providing controllers, some sort of orm to your favourite DB providing Models and a template engine for views. Or, develop a backbone.js app for your frontend and make it talk to the api exposed by your controllers....no easy full stack like rails...yet...but it'll come, however I can't imagine it'll look too much like rails.
- 16y ago
chubs 16y ago
That's fantastic news! I can't wait for coffee to become widespread.
kapso 16y ago
Did not see this coming. IMHO one problem does not kill another problem. Dont see CS as a solution at all.
joubert 16y ago
Isn't CoffeeScript bad for perf on mobile because, for example, its extensive (over-)use of closures?
weixiyen 16y ago
On that note, why bother writing Ruby, just have CoffeeScript full-stack with CS compiling to Ruby. That way developers don't need to deal with 2 languages.
deleted 16y ago
[deleted]
apgwoz 15y ago
Disclaimer: I don't use Rails or Ruby. Wouldn't including CoffeeScript create a new dependency on Java (to run in Rhino or what not) or Node.js? How is the CoffeeScript compiled to JavaScript if this is not the case?
djhworld 15y ago
I'm a Java/Scala/Ruby developer at heart and I have very little input into front-end development. While I've written some javascript, I wouldn't say it's very good and I'm not really that well versed in the features of Javascript either. Would you say it's better to a) Learn to do Javascript properly then learn CoffeeScript b) Learn CoffeeScript and forget about Javascript?
- geraldalewis 15y ago
  CoffeeScript's golden rule is "It's just JavaScript". You need to learn JavaScript (or, more importantly, understand JavaScript) before moving on to CoffeeScript. JavaScript is a weird language, especially if you're coming from a backend language (even dynamic ones like Ruby). Without understanding why things happen in JavaScript (such as: a block doesn't create scope; functions/lambdas do), you won't understand why things are happening in CoffeScript, either. Debugging is CoffeeScript's biggest weakness; you'll often have to dig into the JavaScript it outputs in order to fix bugs, and (for the moment) you won't necessarily know what line of CoffeeScript maps to which line of output JavaScript. ( I believe this is actively being worked on: https://github.com/jashkenas/coffee-script/issues/558 https://github.com/jashkenas/coffee-script/issues/558 ). Here are some good resources that have helped me: http://yuiblog.com/crockford/ http://yuiblog.com/crockford/ http://eloquentjavascript.net/contents.html http://eloquentjavascript.net/contents.html http://ejohn.org/apps/learn/#1 http://ejohn.org/apps/learn/#1
  - djhworld 15y ago
    Hey thanks man, that's cleared things up for me!
MatthewPhillips 15y ago
I converted some of my javascript to coffeescript last night, and the one thing that I still feel weird about is not having void functions. I have been instead ending those functions with null, but it feels weird. Is it not the "coffeescript way" to have void style functions at all? I should try to convert these to expressions?
- jashkenas 15y ago
  Ideally, every function you write returns a meaningful value ... even if that function is used for nothing more than side effects, and that value is just "true", or "null". To create a void function in CoffeeScript, just add a naked "return" as the final line. sideEffecty = -> do something do somethingElse return
jorangreef 15y ago
Rails 4.1 will drop Ruby and change the default language to Javascript. It's more DRY.

320 points by bjonathan 16y ago

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.
      - 16y ago
- jonsmock 15y 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 15y 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.

patio11 16y ago

Normally, I'm skeptical of "change the syntax and your life will magically get better, no matter how headachey interacting with the rest of the world will become", but then Thomas showed me Sass and it was lifechanging. (After you've gotten around Sass, CSS looks like Assembly code to a web programmer. I mean, sure, you could write it... but you'd need a damn good reason to. If you haven't tried it yet, make yourself an excuse for a weekend project -- it will make your life better.) Has anyone found CoffeeScript to be lifechanging?

icey 16y ago
Yes, CoffeeScript is amazing. No more headaches over missing semi-colons, callbacks feel significantly less "spaghetti-like". Syntactically it feels much cleaner and I've found that I end up staying much nearer to the left margin than I did with JavaScript. Debugging has not been a problem for me yet, the generated JavaScript is very clean and easy to navigate. That being said, I'm a Python fan, so I consider significant whitespace to be a feature, not an irritant.
- DanielRibeiro 16y ago
  Second that. Coffeescript is really life changing. A very DSL friendly language, where beautiful code can rival python's[1] [1] http://metaphysicaldeveloper.wordpress.com/2011/03/31/354/ http://metaphysicaldeveloper.wordpress.com/2011/03/31/354/
  - icey 16y ago
    Now I have to put on my fruity hippie developer hat. I feel like it makes a big difference when a language implementor values beauty in code. CoffeeScript was created by someone who values the aesthetics of code, and it shows. The CoffeeScript documentation is a fantastic exposition of that: http://jashkenas.github.com/coffee-script/ http://jashkenas.github.com/coffee-script/
    - Cushman 16y ago
      Indeed. Newcomers usually describe CS as "Pythonesque" (because of significant whitespace) or "Rubyish" (because of optional parentheses) depending where they're coming from. I find that a little funny. Truth is, it's borrowed from both, and other languages besides, to synthesize a gorgeous syntax which is really its own.

caioariede 16y ago

By default, really? I don't like the idea neither I'm a Rails developer, but I think that this will increase the learning curve. Let it be just a choice.

scottbessler 16y ago
It being a default is not mutually exclusive with it being a choice. I like the move, defaults should be used to push forward positive change and very few if anyone seems to have said they would rather not use CoffeeScript.
stanleydrew 16y ago
Choices are kind of antithetical to rails's core philosophy of convention over configuration.
- jarin 16y ago
  I think it is requiring the user to make a choice that is antithetical. You can change pretty much all of the defaults in Rails.
  - stanleydrew 16y ago
    Agreed, and that is indeed what I meant. Coffeescript has always been a choice in the sense that I could download the compiler and use the output in my rails project.
- sabat 16y ago
  It will remain a choice. Rails doesn't obliterate choices, just makes it easier if you're willing to take defaults. On the other hand, replacements for default components (e.g. Rspec vs. default Test::Unit) are generally simple to drop in.
jarin 16y ago
Rails is a pretty huge learning curve in and of itself, as most developers need to learn MVC, unit testing, migrations, activerecord, callbacks, filter chains, routing, erb, view helpers, partials, layouts, etc. Of course, all of this stuff makes your life easier once you learn it. I would even be down with making Haml and Sass the default, since most Rails developers seem to use them anyway. Scaffolds would give newbies a good starting point to work with.

ddagradi 16y ago

Really? Everyone seems to be freaking out as if Rails will no longer serve your standard JavaScript files again. Rather, by default, the generator spits out CoffeeScript templates. If you don't want to use CoffeeScript, don't use CoffeeScript and write regular JavaScript instead. Will this confuse new users? Probably not, since the template file is going to include instructions and an explanation. Will the change break any existing sites? I really doubt it. In the end, encouraging a better default language is a great change. New users are already required to learn to write ERB/Haml to make a Rails app; this is no different, and easily ignored if you're not interested.

KarlFreeman 16y ago
Couldn't agree more with you. Good points.
icey 16y ago
Don't you feel it would have been more prudent to start by bundling CoffeeScript support and then changing the default in a later version? It seems like an overly aggressive goal to do both things at once.
- jarin 16y ago
  One of the core strengths of Rails is that it is highly opinionated. That's why people talk about doing things "the Rails way". You can always change things if you like (a lot of people change the views to Haml, UJS library to jQuery, and test framework to Rspec), but it assumes sensible, working defaults.
  - icey 16y ago
    Excellent point. Not being a Rails guy I sometimes forget that being opinionated is considered one of its strengths. If any framework can get away with doing something like this, it'd be Rails. At any rate, I'm excited about anything that increases CoffeeScript adoption.
- ddagradi 16y ago

deleted 16y ago

[deleted]

bonzoesc 16y ago

Is Rails 3.1 going to depend on having both a ruby interpreter and a JS interpreter (presumably node?) capable of running coffeescript installed?

sabat 16y ago
CoffeeScript isn't interpreted; it's not its own language. You write CoffeeScript code, which resembles simplified and cleaned-up Javascript, and then run a parser over it which converts it to standard Javascript. You'll need CoffeeScript (gem) installed in this situation, but that's just another Rails dependency. EDIT: I should point out that Rails will use CoffeeScript for client-side (browser) code, not server-side code. That remains Ruby and associated DSLs.
- bonzoesc 16y ago
  The coffeescript compiler is written in coffeescript (and compiled to JS), so in order to serve a .coffee file you'll need to compile it, which requires JS. The commits add a dependency to the coffee-script[1] gem, which requires the execjs[2] gem, which requires some way of running JS. 1: https://github.com/josh/ruby-coffee-script https://github.com/josh/ruby-coffee-script 2: https://github.com/sstephenson/execjs https://github.com/sstephenson/execjs
  - thenduks 16y ago
    If you don't have a method of running JS available then everything will be as it was. This change only introduces the default contents of a rails app's Gemfile (/bundle) and it's generators.
  - sabat 16y ago
    I didn't realize it was more than a parser; thx for the info.
JonnieCache 16y ago
No. Coffeescript is not going to be run inside the rails stack. That would be controversial. All that's happening is by default the scaffolding generator scripts will spit out boilerplate coffeescript rather then boilerplate javascript. All that's needed to change back is to comment out a single, clearly marked line of code.

djacobs 16y ago

I have no problem with Rails supporting CoffeeScript out of the box, as the abstraction is really good at showing the power of Javascript and not emphasizing its bad parts. (And, come on, list comprehensions in Javascript? Awesome.) No one is taking away your raw Javascript, it'll work just fine. This just makes it easy for people to use CoffeeScript when they first build an app. It's more of a statement than anything else.

MatthewPhillips 16y ago
I disagree. If someone is starting Ruby for the first time, the last thing they want is to be forced to learn another new language on top of learning Ruby. Then mix in Sass and Haml, and you're giving them a good reason not to even bother.
- djacobs 16y ago
  Who's forcing? Javascript will work just fine.
  - billybob 16y ago
    It's a valid point, though. "So, it's your first Rails app, eh? Do you know Ruby? No? Do you know HAML and SCSS and Coffeescript? No? OK, step 1 in this new framework that you know nothing about is to figure out how to change the defaults." This change definitely has the existing Rails community in mind. Or as I told my friend: "Given that you already know how to create a blog in 5 seconds, how can we also make you not have to use semicolons in your JS?"
    - thenduks 16y ago
      Ok but you don't have to 'change' any 'defaults' to use regular plain javascript. You just don't write coffeescript. The new 'default' is to include the coffeescript dependency and generate script stubs with a .coffee extension. Write a js file and all will be as it was, with a slightly fatter bundle.

JonnieCache 16y ago

Calm down boys and girls, its opinionated software, remember? That's kinda rails' raison d'être. I'm just disappointed they didn't have the balls to make HAML the default templating engine.

bcrescimanno 16y ago
And the HN crowd is an opinionated crowd--just because Rails is opinionated doesn't mean that we can't disagree with it's opinions. :) Edit: Rails is also about "sensible defaults." I'm not sure that making CS the default is really the "sensible" choice.
- JonnieCache 16y ago
  You raise a good point. Good thing rails is so modular since version 3, replacing bits of it like this is completely trivial. Personally I'm more interested in the real 3.1 goodness: flushed responses. The implementation is fascinating. http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/ http://yehudakatz.com/2010/09/07/automatic-flushing-the-rail...
andycroll 16y ago
I'm pretty sure DHH isn't a fan of HAML. Think he's make it clear on a 37s podcast or on Twitter in the past (tried searching but couldn't find a citation).
- rbxbx 16y ago
  I know I personally have argued with him about it. He's very much in favor of ERB.
  - stephth 16y ago
    could you share the gist of his opinion?
    - 16y ago

MatthewPhillips 16y ago

Am I the only one who thinks they are propping up their successor? If you're going to learn Coffeescript, why bother with Rails at all? Just write cs both server and client side. When some one builds a mature node.js MVC framework, Rails is going to be in trouble.

ascendant 16y ago
Express is on the right path. I picked it up for the first time last weekend and liked it.
- MatthewPhillips 16y ago
  It's not MVC though, right? I prefer something more lightweight like Express/Sinatra, but a lot of people are in love with MVC.
  - JonnieCache 16y ago
    It's pretty damn MVC. Just because it doesn't make you define classes with 'Controller' in the name doesn't mean it isn't MVC.
    - MatthewPhillips 16y ago
      I'm with you now. The example on the homepage isn't MVC, but I see from the further documentation that you can incorporate views. Nice.
      - ascendant 16y ago
        Yeah, and the default template language (Jade) is a lot like HAML. In fact, I think there's HAML/SASS plugins, but I'm pretty new at Express so don't take that as gospel.
  - deleted 16y ago
    [deleted]

danest 16y ago

"Yes, it's true, Rails 3.1 is going to ship with CoffeeScript and SCSS in the box for use with the new asset pipeline. It's bad ass." @dhh http://twitter.com/#!/dhh/status/58207700672200704 http://twitter.com/#!/dhh/status/58207700672200704

deleted 16y ago

[deleted]

Aqua_Geek 16y ago

If nothing else, the core team's decision to make it default has piqued my interest in learning CoffeeScript. Anyone know of any good resources off-hand to start digging in to it? I assume their website is the best place to start... (http://www.coffeescript.org http://www.coffeescript.org)

swaits 16y ago
Yep, just play around with the "Try CoffeeScript" interface they have right on the site. You can actually get pretty far with it right there. Open another window for reference, and start hacking away. Watching the transformations as you code is really interesting.

mberning 16y ago

I love this kind of stuff, but at the same time, it presents a huge problem for software maintainability and building a scalable development team. When I go to hire somebody it is a near certainty that they are very proficient with CSS. Sass? Probably less likely. For the sake of argument let's say I could find somebody proficient in Sass, what about all the other boutique technologies I have in my product? At some point your product can devolve into an opaque and indecipherable hodgepodge of 'cool stuff'. Sometimes it really is better to keep things simple, even though you are causing yourself some personal pain.

carbon8 16y ago
The CSS person doesn't need to know Sass in order for the project to benefit from it. At the very least, you could just dump the CSS in an .scss file and just use the automatic output formatting feature. In my current project I take it a step further. I get the CSS from a designer, dump it in an scss partial, include that partial in the main sass/scss file where I then override and add styles. That way I can keep their CSS versioned and untouched while being able to automatically combine it with additional styles into a compressed CSS file. The point is that there are plenty of ways Sass is incredibly useful even if the main CSS person doesn't work with it directly. Obviously Coffeescript is a little different, but the advantage is that a Javascript developer is a programmer and it's not an unreasonable expectation for them to be able to get up to speed on Coffeescript.
jarin 16y ago
It really doesn't take much to gain basic proficiency with SASS, as long as you know how to use the tab and delete keys (or the sass-convert tool). With SCSS it's even easier, just rename the file and refactor it later if you're feeling lazy. On a practical note, I've subcontracted out design work before and convinced (strongarmed) the designer to learn SASS. They're usually pretty happy about it.
dhh 16y ago
Have you actually looked at SCSS? This is a good start: http://sass-lang.com/ http://sass-lang.com/. It's a superset of CSS. Very easy to learn. Also, this "huge problem" you talk about is the same that people used to argue against Ruby/Rails with. Hey, everyone knows Java/Struts -- let's just keep it simple for hiring drone purposes!

hoopadoop 16y ago

There is going to be some overlap of concerns once all of Sproutcore has been integrated into JQuery.

augustl 16y ago

Rails has a history of doing things with JavaScript that many developers disagree with. RJS is a prime example, where you would write Ruby code that generated JavaScript that assumed you used the Prototype.JS framework. And it wasn't until Rails 3.0 we got view helpers that didn't inline JavaScript. So in my opinion we had one minor version with JavaScript I could relate to, and now we're back to where we were. But I don't mind, I'll just avoid using it.

dasil003 16y ago
Yeah RJS was a clusterfuck, but hindsight is always 20/20. At the time it was a new idea that was being explored that just didn't pan out. The Prototype dependency dates back to 2004 when no framework had AJAX support, and the code just started getting stale from there and didn't get any attention until Rails 3. Anyway, I agree that Rails core has traditionally been far from the savviest of JavaScript developers, but the nice thing about Rails 3 is that they've finally achieved reasonable modularity with all the components, so there's not much pain in getting around Rails opinions anymore. As for CoffeeScript, I'm still on the fence, but it's clear that Jeremy Ashkenas knows his JavaScript, and his work is not done out of ignorance, so I'm glad for it to get more exposure.
- bstar 16y ago
  I guess I'm just amazed that they (rails core) haven't learned from the RJS mistake. These 'fads' to get around JS syntax are terrible as standards. What is so wrong with writing idiomatic, unobtrusive JS? I personally don't care for JS syntax (compared to the beauty of ruby and haml), but that's life... JS syntax my be ugly, but it can be written elegantly.
  - dasil003 16y ago
    What's there to learn from the RJS mistake? RJS was fucked because it attempted to pretend JS didn't exist and muddled the separation of concerns between client and server-side; CoffeeScript makes no such mistake. CoffeeScript is much more like HAML/SASS in function, and while there are arguments against those in some environments (like if you need to hire a lot of designers without a dev mentality or environment), they've been proven to be very effective in practice, and I'm quite sure CoffeeScript will be the same.

aneth 16y ago

It's interesting that rails is headed toward whitespace significance in all its file formats, yet the most apparent difference between ruby and it's main rival Python is that whitespace is not significant. Between yaml, sass (although not scss), haml, and coffescript, is the next step a version of ruby getting rid of end statements in favor of whitespace? I've often dreamed of such a thing. module Foo module Bar class Fubar def boom p "I like monkey patches" end end end end Ick!

generalk 16y ago
> It's interesting that rails is headed toward whitespace > significance in all its file formats, yet the most apparent > difference between ruby and it's main rival Python is that > whitespace is not significant. That may be the most obvious difference at first glance, but it's also the most superficial. Idiomatic Python and idiomatic Ruby will be written completely differently.

oomkiller 16y ago

I don't understand what the big deal is here. All this patch does is make a application.js.coffee instead of application.js, and add support for actually generating JS from this. One of the recurring arguments I've seen is that this change will make it harder for people to get started with Rails. I really don't understand how this is the case, because if you understand what public/javascripts is for and what javascript_include_tag does, you should also be able to write normal javascript all day long. Hell, you don't even need that, adding your own HTML to include a script into the page works too (as always). There is no need to write CoffeeScript if you don't want to/don't know how to; write all the js you want. In reality, the only outcome of this will be more people discovering and learning CoffeeScript. I seriously doubt this will discourage anyone from learning Rails. If it does, they were bound to find something that discouraged them eventually.

jaekwon 16y ago

i know what i'm using for my next project now.

trustfundbaby 16y ago

I don't like that its the default, it seems like something the 37signals guys like (pow was written in coffee script) so "goshdarnit! all of you have to use it". Yes I know, you can change it. Yes. I know its impact is probably minimal if I don't care for it. But, I really would like to see a strong argument made for why this should be a default for Rails, especially when SASS and HAML, which have wider adoption and facetime with the Rails community aren't the default (and I think, rightfully so)

smoody 16y ago

IMHO, this smells like a marketing move -- in the same way that merging Rails and Merb was a (brilliant) marketing move. If Rails wants to stay "cool" (and if you believe that "cool" is a zero sum game), then Rails has to stay buzzword compliant. Yes, Rails has a lot of support but the Rails team isn't stupid and they know, by definition, that it's just a matter of years before Rails itself becomes something of a relic -- one kids know of only because their daddies and mommies used to use it.

dasil003 16y ago
You're stuck in 2004, when DHH poked Java in the eye to get attention; that was a marketing move. It's been years since Rails had to do any marketing. The Merb merge was about bringing incredible ideas into Rails, and it shows in Rails 3. Similarly, CoffeeScript is being defaulted because DHH believes it's a better way to write JS. He has better things to do than make contrived technical decisions to stir up controversy. If you disagree than I pity your paranoia.

digispaghetti 16y ago

Shameless self-promotion here, but if you want to try CoffeeScript and are using the Cloud9 IDE I wrote an extension so you can see your coffeescript output live: https://github.com/tanepiper/cloud9-livecoffee-ext https://github.com/tanepiper/cloud9-livecoffee-ext

nightlifelover 16y ago

Just wondering is there a framework like Rails written in JS? Using JavaScript and V8 on the server side makes a lot of sense since V8 is much faster then the Ruby interpreter..

nevinera 16y ago
Express is fairly rails-like (for node.js).
- telemachos 16y ago
  Maybe a fairer comparison is Sinatra? That is, Express is a lot slimmer than Rails and works via a DSL based around the HTTP verbs[1]. Another JS framework to look at is Backbone[2]. [1] http://expressjs.com/guide.html#routing http://expressjs.com/guide.html#routing [2] http://documentcloud.github.com/backbone/ http://documentcloud.github.com/backbone/
  - nevinera 16y ago
    That would definitely be a fairer comparison, but he was asking for 'a framework like rails'; Express is the closest.
CWIZO 16y ago
Have you tried node.js?
- te_chris 16y ago
  Node isn't really a framework. It's a server-side runtime environment for javascript. You could totally do something cool with it, Express js providing controllers, some sort of orm to your favourite DB providing Models and a template engine for views. Or, develop a backbone.js app for your frontend and make it talk to the api exposed by your controllers....no easy full stack like rails...yet...but it'll come, however I can't imagine it'll look too much like rails.
16y ago

chubs 16y ago

That's fantastic news! I can't wait for coffee to become widespread.

kapso 16y ago

Did not see this coming. IMHO one problem does not kill another problem. Dont see CS as a solution at all.

joubert 16y ago

Isn't CoffeeScript bad for perf on mobile because, for example, its extensive (over-)use of closures?

weixiyen 16y ago

On that note, why bother writing Ruby, just have CoffeeScript full-stack with CS compiling to Ruby. That way developers don't need to deal with 2 languages.

deleted 16y ago

[deleted]

apgwoz 15y ago

Disclaimer: I don't use Rails or Ruby. Wouldn't including CoffeeScript create a new dependency on Java (to run in Rhino or what not) or Node.js? How is the CoffeeScript compiled to JavaScript if this is not the case?

djhworld 15y ago

I'm a Java/Scala/Ruby developer at heart and I have very little input into front-end development. While I've written some javascript, I wouldn't say it's very good and I'm not really that well versed in the features of Javascript either. Would you say it's better to a) Learn to do Javascript properly then learn CoffeeScript b) Learn CoffeeScript and forget about Javascript?

geraldalewis 15y ago
CoffeeScript's golden rule is "It's just JavaScript". You need to learn JavaScript (or, more importantly, understand JavaScript) before moving on to CoffeeScript. JavaScript is a weird language, especially if you're coming from a backend language (even dynamic ones like Ruby). Without understanding why things happen in JavaScript (such as: a block doesn't create scope; functions/lambdas do), you won't understand why things are happening in CoffeScript, either. Debugging is CoffeeScript's biggest weakness; you'll often have to dig into the JavaScript it outputs in order to fix bugs, and (for the moment) you won't necessarily know what line of CoffeeScript maps to which line of output JavaScript. ( I believe this is actively being worked on: https://github.com/jashkenas/coffee-script/issues/558 https://github.com/jashkenas/coffee-script/issues/558 ). Here are some good resources that have helped me: http://yuiblog.com/crockford/ http://yuiblog.com/crockford/ http://eloquentjavascript.net/contents.html http://eloquentjavascript.net/contents.html http://ejohn.org/apps/learn/#1 http://ejohn.org/apps/learn/#1
- djhworld 15y ago
  Hey thanks man, that's cleared things up for me!

MatthewPhillips 15y ago

I converted some of my javascript to coffeescript last night, and the one thing that I still feel weird about is not having void functions. I have been instead ending those functions with null, but it feels weird. Is it not the "coffeescript way" to have void style functions at all? I should try to convert these to expressions?

jashkenas 15y ago
Ideally, every function you write returns a meaningful value ... even if that function is used for nothing more than side effects, and that value is just "true", or "null". To create a void function in CoffeeScript, just add a naked "return" as the final line. sideEffecty = -> do something do somethingElse return

jorangreef 15y ago

Rails 4.1 will drop Ruby and change the default language to Javascript. It's more DRY.