Rails 3.1 shipping with CoffeeScript

https://github.com/rails/rails/compare/9333ca7...23aa7da

by bjonathan • 15 years ago

320 199 15 years 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!

jonsmock2• 15 years 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.

philwelch3• 15 years 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?

jonsmock2• 15 years 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

Cushman5• 15 years 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.

bcrescimanno7• 15 years 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.

icey5• 15 years 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• 15 years 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.

bcrescimanno7• 15 years 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.

jashkenas9• 15 years ago

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

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

bcrescimanno7• 15 years 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.

jpr• 15 years 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• 15 years ago

default frontend scripting language

technomancy4• 15 years 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• 15 years 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?

icey5• 15 years 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• 15 years 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/

MatthewPhillips9• 15 years ago

It's hard to debug when you get compile errors though. I gave up on the language when I could not figure out why a script wouldn't compile; the errors given are basically worthless.

Later I opened the file on Windows (Notepad++) and saw that one line had not been indented, which wasn't showing up on Vim/Gedit. I never tested it to see if that was indeed the problem, I'd already moved on.

mdwrigh24• 15 years ago

I don't know if I'd consider it life-changing for the world of client-side javascript (I have yet to use it there), but using it in the callback-filled universe that is Node.js, its simplified and clean syntax is worlds better.

jarin8• 15 years ago

I'm hoping there will be a day where I can use:

  <script language="coffeescript">

Cushman5• 15 years ago

This guy.

Switching from Rails (et al) to Express (et al) can be a challenging prospect. Not having to give up your floaty modern scripting language syntax is a serious incentive. That aside from the fact that CoffeeScript almost forces you to write better JavaScript.

mdwrigh24• 15 years ago

Making the switch from synchronous execution to asynchronous is the biggest switch for me so far. There doesn't seem to be many best practices yet and so I'm trying to figure out how to do things like ensure database access is available without opening a connection to the DB every time and setting up everything I want to happen in that call back. So far talking to people the consensus has been to just open it and pass around an instance of it. There may be errors if you start receiving requests before the DB is opened, but it will be a short window for this to occur. I'm not entirely happy with this, but am not really sure of a better solution.

With Rails these kinds of things (and other things like source layout and such) are just kind of taken care of for you. On the other hand, I'm having a blast doing some CoffeeScript + Node development.

bad_user4• 15 years ago

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.

jpcx012• 15 years ago

Scss also provides pretty good syntax compatibility with CSS. All it's features are a superset on top of CSS.

rudiger3• 15 years ago

The new, main syntax of Sass is now "SCSS", and is a superset of CSS3’s syntax, so every valid CSS3 stylesheet is valid SCSS as well.

chc4• 15 years ago

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.

M1573RMU74710N2• 15 years ago

There are different vectors of attack when it comes to optimization.

The point of CS is to optimize for developer productivity and happiness, so I think your questions are largely missing the point. It's like asking "well that's a good screwdriver, but does it hammer nails?".

The correct question to ask is: what do I get from this syntactic sugar, and what do I trade. Or to stick with our metaphor:

"What does this screwdriver bring to the table, and does it INTERFERE with the hammering of nails etc?".

So as stated, CS lets you write code faster, express yourself more clearly, and removes headaches common to Javascript. These headaches are problems that are largely not addressed by other tools like jQuery (which have different goals).

To answer your questions:

> Does it fix browser incompatibilities for you

Yes, but only in terms of the language. CS compiles to lowest common denominator Javascript, so you know the compiled code will run just about anywhere.

So you don't have to worry about whether or not the browser's JS engine supports list comprehensions, because you're using CS.

The question is not so much "Does it fix browser incompatibilities for you".... but "Does it introduce browser incompatibilities?". To that, the answer is no.

>Does it optimize Javascript to run faster?

CS allows you to write really expressive code that gets compiled down to simple (but verbose) forms. This has the side-effect that CS code will generally be faster than Vanilla JS code that is written with a similar expressiveness.

In Vanilla JS you would generally have to introduce a library to get the same expressiveness, and that has a run-time penalty. For example: Something that is compiled to a simple for-loop in CS would require a bunch of function calls in a library in vanilla JS, adding a lot of overhead.

CS is not a tool to optimize code, so asking if it optimizes code misses the point. The real question is whether or not it introduces inefficiency, because if it does....that's a drawback that needs to be contrasted to it's benefits.

In this case, no it doesn't...and the code it produces is sometimes faster than similar vanilla JS code.

>Does it have a kick-ass library that's optimized for it?

CS is not meant to fill the same role as a library.

The question is not "does it have a library"...but "what's the implications of using CS vis a vis libraries?" The answer is CS interacts with JS seamlessly, use any library you like.

>Is it easier to debug?

No, because that's not the point of CS. CS is not a debugging tool. The right question is: "is it harder to debug?".

Here we hit what imho is the only real trade-off involved in CS.

Some will hem and haw about having an explicit compilation step; but the tooling support for CS is great and any serious JS developer can fit it into their dev process seamlessly (via commit hooks, watch, build scripts, etc).

Debugging problems is a legit concern, but in my experience it does not add significant problems. Errors in CS syntax are generally caught during compilation and other errors can often be easier to find because the CS code is cleaner and it's easier to catch errors in logic.

I think beginners will often hit problems with debugging and CS because it adds a layer to confuse them. Experienced JS devs on the other hand should be able to cleanly separate the layers and debug them effectively.

The tooling for debugging CS in the future looks promising and will improve the situation.

As for your suggestion that you could just improve your text-editor, use macros, etc....I think that's a good tool to have in your belt but it just doesn't compare to what CS brings to the table.

Either you'd be duplicating CS's efforts ...or you'd not hit the same level of capability...

In the first case, it'd be a pointless re-inventing of the wheel, but your wheel would have drawbacks CS lacks.

With CS there is:

- Lot's of editor support. Your suggestion is tied to 1 editor.

- Lot's of tooling support. There is framework support, and possible browser support in the future...etc etc. Yours would have none, or would need it written.

- Widespread use. Lots of coders will understand my CS code right off the bat, or can learn it easily. Not only will no one understand your crazy macros etc, there's little incentive to learn them.

In the latter case, it's not a valid comparison.

The real question here is what does CS bring to the table, and what do you trade for it. CS had demonstrable benefits and demonstrable drawbacks.

It's my opinion that the benefits dramatically outweigh the drawbacks, but that's a question every developer must ask and answer for themselves.

I get that your contention is somehow, "well if it doesn't do these specific things, it's not 'life changing'", but that seems a pretty arbitrary line to me.

I don't see how you can say developer productivity is not a vital factor in development....and that something that improves productivity, readability, development speed, etc...is not "life-changing", at least as much so as the other factors you mentioned.

When judged in terms of what it's goals are, I think CS is highly effective and far from "pure syntactic sugar" (which to me implies something that simply saves typing).

jpcx012• 15 years ago

CoffeeScript "fixes" javascript in many very essential ways. The most important fix is the lack of global variables. It's all too easy to accidentally forget a var on an assignment and all of a sudden you get a global variable that can cause havok. CoffeeScript handles variable scoping extremely well, and if you need a global, you can use the more explicit: window.var = ....

Also it's class system and function binding (=>) is something I feel I can no longer live without.

euroclydon• 15 years ago

I don't know any thing about CoffeeScript, but static analysis tools like the Google Closure Compiler can help you take care of global variable problems and a whole lot more. Using Closure Compiler, you are forced to document your code with their enhanced version of jsDocs, so CC will make sure that if your method returns null or a list of strings, that anywhere that method is used, you don't try to treat the returned value as a string or object, for instance.

How does coffee script play with existing object oriented JS libraries? Is there compile-time type checking?

chc4• 15 years ago

It is not quite as big as CSS->Sass — that takes CSS from a dumb configuration language to a grown-up programming language with functions and variables. But it is a big difference, and it's not just syntactic.

First of all, I'd like to point out that syntax is not entirely irrelevant, at least not in the sense that CoffeeScript is "just a weird syntax" for JavaScript. Python decorators and list comprehensions are generally thought of as very nice features of the language, but they're really just a nice syntax for higher-order functions and iteration. That syntax makes a big difference. Just adding CoffeeScript's syntax for functions (including the do-operator) and the existential operator would noticeably reduce the size of most JavaScript code, without anything else.

But the difference isn't just syntactic. Here are a few semantic changes in CoffeeScript:

• Everything is an expression (a la Ruby)

• Equality is always strict

• A simplified class-based inheritance model on top of JavaScript's prototypal inheritance

• Switch is almost identical to Ruby's case expression rather than C's switch statement (i.e. clauses don't fall through and it's an expression rather than a statement), which makes it much more useful

I'll put it this way: I've been making websites since 1995 and am fairly proficient in JavaScript, but I have never really liked the language all that much. But CoffeeScript is a joy to use. I actually enjoy programming it, and it's just amazingly readable (both from the nicer syntax and the fact that CoffeeScript's sugar means you don't have to write as much code, and it's easier to understand five lines than 20, even if 15 of the 20 are boilerplate).

reinhardt• 15 years ago

For someone who has little or no experience in JS and CS, how realistic is it to get away without learning JS and skip directly to CS ?

KrisJordan• 15 years ago

After a few months of CoffeeScript development I vastly prefer it to JavaScript. Jeremy, et. al., have done a beautiful job with it. I've used Sass/Less as well and believe the JavaScript/CoffeeScript divide is even more valuable.

Edit: I wrote about some of my favorite features of CoffeeScript when we added CoffeeScript support to our CMS app HiFi... http://www.gethifi.com/blog/hosted-cms-coffeescript-support

tl;dr:

1) Lightweight function declarations (with default values!)

2) Implicit Returns

3) Everything is an Expression

4) Object Literal YAML-like syntax

5) Simple, Classical OO Features (you don't have to use them and can still directly access prototypal features, too)

6) (Not in the post) Binding 'this' to the scope's 'this' using => is awesome.

irahul• 15 years ago

> "change the syntax and your life will magically get better, no matter how headachey interacting with the rest of the world will become"

Life won't get better if interacting with the rest of the world becomes headachery, but thankfully the products in question aren't too hostile to rest of the world. There isn't much of an impedance mismatch between CSS and Sass and following the generated code is easy.

From what little I have written of Coffeescript, it generates clean Javascript and should be easy to follow for anyone who knows Javascript. It's not lifechanging per se but there are things which are much more elegant in Coffeescript.

1) Convenient 'this' binding using =>

2) Lexical scoping. Not much of an issue since I use the 'var' keyword all the time; either that or window.foo or something similar depending on what I am trying to do.

3) I have coded in Python and the "mandatory indentation sans braces" is something I am used to and appreciate. It makes the nested event handling calls prettier.

4) I don't need to use underscore.js while using Coffeescript. The language has some essential feature built-in.

5) The existential operator. From the docs:

"It's a little difficult to check for the existence of a variable in JavaScript. if (variable) ... comes close, but fails for zero, the empty string, and false. CoffeeScript's existential operator ? returns true unless a variable is null or undefined, which makes it analogous to Ruby's nil?"

6) String iterpolation, here docs.

bkudria• 15 years ago

Assembly : C :: CSS : Sass

(:: Javascript : CoffeeScript) would be a bit of a stretch IMO)

jwr• 15 years ago

Definitely. We are a mostly-Clojure shop, but we do quite a bit of complex Javascript as well. Coffeescript makes it fun and productive.

Best of all, there are fewer lines of code to make mistakes in. And fewer stupid "forgot a semicolon" problems.

I'd suggest that people also look at Underscore.js (http://documentcloud.github.com/underscore/) and Backbone.js (http://documentcloud.github.com/backbone/). Same authorship, same quality code, great ideas, great execution.

yesbabyyes• 15 years ago

Yes, it's my favorite language. Very fun and nice to work with. Lends itself well to another one of Jeremy's contributions, http://jashkenas.github.com/docco/, and his way of writing code as a story, which I try to mimick.

If you like Sass, you should check out Stylus. Similar, but better. http://learnboost.github.com/stylus/

caioariede• 15 years 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• 15 years 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.

stanleydrew2• 15 years ago

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

jarin8• 15 years 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.

sabat3• 15 years 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.

jarin8• 15 years 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.

ddagradi2• 15 years 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• 15 years ago

Couldn't agree more with you. Good points.

icey5• 15 years 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.

jarin8• 15 years 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.

ddagradi2• 15 years ago

I guess, but at that point, what's the point of bundling support at all? Support is as easy as adding "gem 'coffee-script'" to the Gemfile.

[edit] And with SCSS also slated to be the default, it seems consistent with "the Rails way" moving forward.

MatthewPhillips9• 15 years ago

It's not easily ignored. If you don't want it to spit out .coffee templates and instead get .js templates, you can change that... but you have to find out how (I for one don't know how). It's an added inconvenience. The person who's an early adopter to a new language like coffeescript should be the ones inconvenienced.

nevinera3• 15 years ago

When 3.1 is released, within hours a google search for 'how the hell do I make rails spit out javascript instead of coffeescript' (or 'rails js cs', most likely) will produce hundreds of results, all of which explain the one-line change necessary in excruciating detail.

bonzoesc2• 15 years 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?

sabat3• 15 years 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.

bonzoesc2• 15 years 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 2: https://github.com/sstephenson/execjs

JonnieCache5• 15 years 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.

sstephenson• 15 years ago

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• 15 years ago

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.

djacobs3• 15 years 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.

MatthewPhillips9• 15 years 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.

djacobs3• 15 years ago

Who's forcing? Javascript will work just fine.

clint• 15 years ago

You can make the same argument for "forcing" them to learn JavaScript, HTML and CSS—which would be a similarly silly argument to make.

evilduck2• 15 years ago

Learning Ruby via Rails seems like the hardest thing you listed. Haml, SCSS and CoffeeScript can all be eased into gradually.

extension• 15 years ago

Rails has always been optimized for people who use it all day, every day, rather than those using it for the first time.

JonnieCache5• 15 years 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.

bcrescimanno7• 15 years 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.

JonnieCache5• 15 years 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-rail...

andycroll• 15 years 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).

rbxbx3• 15 years ago

I know I personally have argued with him about it. He's very much in favor of ERB.

yxhuvud• 15 years ago

Agreed. After all, remember that it also defaults to using sqlite.

daemin2• 15 years ago

Exactly, and if you don't like the opinion to include CoffeeScript or SCSS as your default components, then it's a simple one time, two line fix, to remove them from your project.

The same sort of operation as adding/removing a gem from a project.

Chill people.

MatthewPhillips9• 15 years 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.

ascendant3• 15 years ago

Express is on the right path. I picked it up for the first time last weekend and liked it.

MatthewPhillips9• 15 years 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.

moxiemk1• 15 years ago

If your motivations are to make the most useful (to yourself) framework, then there is no problem in propping up your successor. Making the transition smooth is indeed the "Right Thing"

danest• 15 years 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

Aqua_Geek• 15 years 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)

swaits2• 15 years 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.

mberning3• 15 years 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• 15 years 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.

jarin8• 15 years 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• 15 years ago

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!

mberning3• 15 years ago

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.

hoopadoop• 15 years ago

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

augustl• 15 years 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.

dasil0033• 15 years 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• 15 years 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.

aneth• 15 years 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• 15 years 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• 15 years 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• 15 years ago

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

trustfundbaby• 15 years 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• 15 years 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.

dasil0033• 15 years 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.

nightlifelover• 15 years 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..

nevinera3• 15 years ago

Express is fairly rails-like (for node.js).

telemachos• 15 years 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

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

CWIZO• 15 years ago

Have you tried node.js?

te_chris• 15 years 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.

kapso2• 15 years ago

Express/node.js is the closest. LearnBoost runs on it, if I am not mistaken.

chubs• 15 years ago

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

kapso2• 15 years ago

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

joubert• 15 years ago

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

weixiyen• 15 years 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.

apgwoz• 15 years 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?

djhworld2• 15 years 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• 15 years 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 ).

Here are some good resources that have helped me:

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

djhworld2• 15 years ago

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

MatthewPhillips9• 15 years 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?

jashkenas9• 15 years 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

_urga• 15 years ago

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

Rails 3.1 shipping with CoffeeScript

Related Stories