
Rails 3.1 shipping with CoffeeScript - bjonathan
https://github.com/rails/rails/compare/9333ca7...23aa7da
======
patio11
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?

~~~
bad_user
I'm using LessCSS, not Sass. And I wouldn't consider Sass life changing.

    
    
        CSS looks like Assembly code ... you could 
        write it... but you'd need a damn good reason to
    

I think LessCSS is better because it keeps syntax compatibility, and you can
take an existing CSS file and then gradually improve it. It's also, well,
simpler.

That said, I can live without the improved CSS features. When I'm working on
design-stuff, what really gets in my way is the lack of talent.

As for CoffeeScript, the language looks really interesting, but IMHO, it's
just another tool that you need to add to an already HEAVY stack, another tool
that breaks and needs special care from time to time, another tool to be
learned.

And I'm not sure that CS is so life-changing. Does it fix browser
incompatibilities for you? Does it optimize Javascript to run faster? Is it
easier to debug? Does it have a kick-ass library that's optimized for it?

IMHO, syntactic sugar (without new paradigms) doesn't get you further than
changing your text-editor / adding some newer snippets to it for the
boilerplate.

~~~
chc
Can you explain why the syntax resembling CSS while having a different meaning
is a good thing? I sincerely don't understand why so many people see that as a
benefit. The syntax isn't actually _compatible_ with CSS, in the sense that
you can write Less or SCSS and a layout engine will be able to parse it and
come out with a halfway correct result. It just _looks like_ CSS.

~~~
bad_user
The syntax of LessCSS is a superset of CSS, meaning it maintains backwards
compatibility. It doesn't just look like CSS, it is CSS but with additions.

That means you can use that CSS file provided by the designer directly, and
gradually improve it, or you can copy/paste examples given all across the web.

------
bcrescimanno
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
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
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
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
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
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
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.

------
ddagradi
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.

~~~
icey
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
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
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.

------
JonnieCache
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
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
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-
rail...](http://yehudakatz.com/2010/09/07/automatic-flushing-the-
rails-3-1-plan/)

------
augustl
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
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
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
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.

------
oomkiller
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.

------
caioariede
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.

~~~
stanleydrew
Choices are kind of antithetical to rails's core philosophy of convention over
configuration.

~~~
jarin
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
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.

------
MatthewPhillips
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
Express is on the right path. I picked it up for the first time last weekend
and liked it.

~~~
MatthewPhillips
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
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
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
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.

------
djacobs
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
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
Who's forcing? Javascript will work just fine.

~~~
billybob
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
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.

------
danest
"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>

------
mberning
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.

~~~
dhh
Have you actually looked at SCSS? This is a good start: <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!

~~~
mberning
Yes, I have looked at it, and I agree that it is very convenient that it is a
superset of CSS. The problem still remains once I become deeply entrenched in
SCSS it will have drifted pretty far from plain CSS.

The argument about rails vs struts may have been similar, but I don't think
the comparison holds water. Web development frameworks are different than
markup and stylesheet standards. We have standards that define HTML, CSS,
Javascript, etc. There is no one standard that governs MVC frameworks.

So while I would expect any competent web developer to know HTML, CSS, and
Javascript, I would not expect them to be competent in my particular choice of
web framework since there is necessarily less standardization in that area.

My core point is that you need to exercise some caution before jumping into
all these different technologies with both feet. There are considerations that
extend beyond your personal coding pleasure.

~~~
mberning
Edit:

Also, my point was not to argue against one single technology. I am arguing
against building an application with 20 different gee-whiz packages that
causes a nightmare when training new developers.

It is an effective way to make sure you can never be fired from your current
job though.

~~~
martinc
I'm in agreement. I'm already 10x faster with HTML and CSS so it defeats the
point switching to an abstraction language such as Haml or Sass.

~~~
nclark
try haml for two weeks, you will not go back.

------
nightlifelover
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
Express is fairly rails-like (for node.js).

~~~
telemachos
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>

[2] <http://documentcloud.github.com/backbone/>

~~~
nevinera
That would definitely be a fairer comparison, but he was asking for 'a
framework like rails'; Express is the closest.

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

------
djhworld
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
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> ).

Here are some good resources that have helped me:

<http://yuiblog.com/crockford/> <http://eloquentjavascript.net/contents.html>
<http://ejohn.org/apps/learn/#1>

~~~
djhworld
Hey thanks man, that's cleared things up for me!

------
Aqua_Geek
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>)

~~~
swaits
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.

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

------
trustfundbaby
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)

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

~~~
sstephenson
The coffee-script gem (<https://github.com/josh/ruby-coffee-script>) uses
ExecJS (<https://github.com/sstephenson/execjs>) to invoke the CS compiler.
Rails 3.1's asset pipelining system will use these gems by way of Sprockets 2
(<https://github.com/sstephenson/sprockets>) to compile and serve CoffeeScript
to the browser.

If you're on Windows or Mac OS, ExecJS will use the JS runtime already
installed on your system (Windows Script Host or Apple JavaScriptCore). You
can also install a gem like therubyracer (V8 for MRI, available on Heroku) or
therubyrhino (Rhino for JRuby) for faster compilation. And ExecJS can use
Node.js or Spidermonkey if they're installed too.

~~~
dreyfiz
I’ve heard a little about it, but is there any documentation anywhere about
this new asset pipelining system in 3.1? You seem well-informed about it.

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

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

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

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

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

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

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

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

------
weixiyen
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.

------
smoody
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
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.

