Hacker News new | comments | show | ask | jobs | submit login
Rails 3.1 shipping with CoffeeScript (github.com)
320 points by bjonathan 2352 days ago | hide | past | web | 199 comments | favorite

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?

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


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.

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.

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.

You should have gotten an error for missing an indentation on one line. For example, given this mis-indented script:

    if one
      if two
The error given is:

    Parse error on line 4: Unexpected 'INDENT'

Too bad you "already moved on". I coded in CoffeeScript in Gedit for a few weeks now. A CS compile error in the version I have does show the line number... and if it compiles and I have a runtime JS error (also with line-number in NodeJS) then opening the compiled JS file in my ./project/_js folder and jumping to the line is also not a Big Deal at all.

Since the compiled JS is just-the-code-I-wrote-myself only in a slightly more verbose curly syntax, troubleshooting my own CS code even when compiled in JS is totally not an issue. Thankfully Coffee does not minify or otherwise obscure the code.

Considering duolagies comment: was that recently or could it be that error messages have improved since then? It would be a shame to let a good thing go because it was insufficiently mature the first time you looked at it.

Thats almost the same as someone claiming Python is a huge fail - because he didn't know how to configure his editor properly.

Alas, poor error messages are a big -

I didn't say the language was a huge fail. I don't have a background with indented languages, and although the code looked correct to me, it wasn't, and not having the knowledge of what could be wrong, I was dependent on the compiler, which gave me no help. I'm ok with curly brackets and semi-colons, so there wasn't any reason to continue wasting my time in a fruitless attempt to figure out what I did wrong. I'm not down on the language at all, bad compiler errors are expected in one year old languages. I'll give it another look on my next project.

I think it's a valid point. Regardless of the fact his editor wasn't configured properly, the fact that the error messages that were generated did not IMMEDIATELY point him in the right direction is a problem with the language and the compiler. Any good product attempts to alleviate human error as much as possible. Obviously in this person's case that goal wasn't achieved.

Paste this line into your files:

    # vim: ts=2 sw=2 et :

I've been using list/listchars for a few years and have come to really like it:

  set listchars=tab:»·,trail:·
  set list
That will show tabs with a little double arrow and trailing dots, and show whitespace past the end of the line with dots.

Regardless, with coffee being default in Rails 3.1, I'm sure editor support will show up quickly. For the time being though, I just stumbled onto this: https://github.com/kchmck/vim-coffee-script (have not tried it myself).

I'm using the vim syntax file and plugins from vim-coffee-script and really like it so far. It even will mark trailing whitespace by highlighting it red (this is configurable as well).

Personal preference here, but I generally like to write the "full" version of configuration option names in my .vimrc (and when giving config advice to other Vim users), because after a month of not touching my RC file, it's easy to forget what those abbreviations stand for. (I tend to limit the shorthand versions of things to the interactive Vim commandline.)

Ok... care to explain?

It's a directive for VIM to set the tabstop to 2, the shiftwidth to 2 and to enable the expandtab option.

The tabstop variable sets the ratio of tabs to spaces (in this case, one tab is equivalent to two spaces).

The shiftwidth variable controls how much a line gets moved when it gets "shifted". In VIM pressing << in Normal mode on a line does a left shift. With a shiftwidth of two, it will move it over two spaces to the left. >> is right shift. There are many more ways of shifting, however.

The expandtab option sets it up so that every time you hit the tab key, VIM will insert the equivalent number of spaces according to the tabstop. In this case, pressing tab will give you two spaces.

This makes sure that your CoffeeScript files never end up with mixed tabs/spaces, which will result in the compiler getting confused, and your hair being pulled out from "invisible syntax errors"

It's a shame that this hack is necessary; it would have been so easy for the language designer to simply declare that any tab characters used as indentation result in a syntax error, and poof: a whole class of errors simply become impossible. Don't get me wrong; I will probably reach straight for coffeescript the next time I write code that runs in a browser, but this is the one thing that cools my enthusiasm for it.

It's a shame that this hack is necessary; it would have been so easy for the language designer to simply declare that any tab characters used as indentation result in a syntax error

then someone else would say that it's a shame that TABS aren't supported and that it would have been so easy for the language designer to support them. I'm sorry if it sounds snarky, but I find it arrogant to assume that design decisions are "easy" simply because they look easy to implement.

All that to say it seems pretty uncontroversial to say that Python and Make have shown that the problem is not necessarily with meaningful indentation itself, but with the ability to have two expressions that are visually identical with different meanings.

... unless, the person has a comic strip to back it up. :)

If using 'et', it's not necessary to make 'ts' equal to 'sw'. Just make 'sts' equal to 'sw' or use 'sta'.

I'd follow it up with:


The creator of CoffeeScript acknowledges debugging is a problem and somewhat "daunting" for beginners (though your issue sounds more like an editor config issue). http://thechangelog.com/post/849754840/episode-0-2-9-coffees...

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/

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/

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.

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

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 ?

Not very realistic. CoffeeScript semantics are nearly identical to JavaScript semantics -- you'll have to understand them.

Hate to disagree with such a distinguished source, but having done it:

Very realistic. Looking at the compiled CoffeeScript taught me more Javascript than all of the tutorials put together, and CoffeeScript itself was a joy to learn. I think you're under estimating your own baby here, jashkenas.

I would point out that you're not so much 'skipping' learning JS, as that learning CS is the quickest way I've found so far to learn JS.

Hey, that's wonderful.

I'm just saying that you're not in any way going to avoid learning JS by starting with Coffee -- you still need to know:

  * How JS numbers work.

  * All about "this" (dynamic scope).

  * Function vs. block-level scope.

  * How the prototype chain is structured.
... and all those other un-obvious things about JavaScript.

True, but I would need to learn these regardless of which syntax I use to write my JavaScript. And coffee actually helped me to become aware of/understand some of these issues: -> vs. =>, for example, or the prototype code produced by your 'class' syntax.

Spend a couple hours reading "Javascript: The Good Parts" by Douglas Crockford. Read it twice, cover to cover.

The other option is to skip learning javascript properly, which I tried... and it came back hard at me when I tried going beyond enhancing my pages with jquery.

I'd say it is realistic for what you're probably trying to do off the bat with Javascript.

It's what I did. Since I'm already comfortably with Ruby and CoffeeScript's simple syntax, I used CoffeeScript's "Try CoffeeScript" console to insert Ruby-like code and get the Javascript equivalent. Helped me rapidly map Ruby-Javascript equivalences in my head.

Now that I'm quickly comfortable with Javscript's surface and my foot's in the door, diving deeper into the language isn't the obstacle I used to consider it as.

Very realistic until you need to debug your code. Debugging's JS-only, as far as I know, so you're picking through the compiled CS looking for errors.

edit: Well listen to the man himself, but I learned tons about JS's semantics by picking up (and picking apart) CS.

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.

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?

I always thought it would be cool if CoffeeScript's generated JS code added Closure Compiler annotations, such as @const and @param types. Let the user minify/optimize the generated JS using their favorite tools.


This fork of CoffeeScript does: https://github.com/jstrachan/coffee-script/blob/master/TypeA.... I for one would also love it if this got rolled into mainline. I use Closure at work, and I'd love to be using CoffeeScript with it.

Thanks! I hadn't seen this "UberScript" before, though I was kinda hoping the Closure annotations could be inferred "for free" without changes to the CoffeeScript language. <:)

Automatically annotating JavaScript code for JSDoc would really helpful.

One of the niceties of CoffeeScript generated code is that it's totally readable and idiomatic Javascript with a dose of JSLint on top.

To misquote the "Pragmatic Programmer" book... don't use wizard code you don't understand. The opposite applies in my opinion.

The golden rule of CoffeeScript is: "It's just JavaScript". The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. http://coffeescript.org

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

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.

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.

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

  <script language="coffeescript">

You can do that now, with caveats:


I've seen that, but I wonder why it says "not recommended for serious use". If it's just slower, I'd be ok using it for simple things, but if it's buggy I'll just use BistroCar.

It's not recommended for serious use because:

* You have to include the "coffee-script.js" compiler file, which is medium large (mostly the generated parse table).

* It's harder to debug, because you're debugging through an eval(), without the compiled JavaScript handy.

Those two caveats aside, it works fine. All of the interactions on the CoffeeScript.org homepage are powered by it.

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/

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.

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.

From what I understand, the SCSS syntax is mainly just for compatibility with CSS. I'm sticking with SASS as long as it's officially supported, since I like getting rid of all of the curly braces and semicolons.

Officially SCSS is the "primary syntax" and SASS merely the "old syntax that is still supported".

I never understood the rationale behind this decision (does anyone prefer SCSS over SASS?), but who cares as long as SASS remains a first-class citizen.

SCSS lets me migrate an existing css file without rewriting anything and drop in random snippets I find on the web without translation. It solves exactly the problem I have (limited expressiveness) without introducing a new one (new syntax to learn).

sass-convert is your friend and takes care of both of your problems for you.

How, and with what input and output formats? I said I like SCSS.

If you output to a file with a .scss extension it will auto-detect.

I prefer SCSS to SASS, but I like braces. I also find being a superset of regular CSS to be a plus (even though it's not something I've actually used in practice).

I prefer to use the SCSS syntax rather than the SASS syntax (and I've used both) mainly because I don't use HAML and I have a deep distrust of significant whitespace that is syntactically significant.

The SCSS syntax works for me because it's like normal CSS but with extra useful features - functions, mixins, nesting, etc.

I've only ever used SCSS, mostly cause it was the "official" version when I first used it. I also think that SASS files look weird to me...for whatever that's worth. SCSS eing a superset of CSS is huge too, IMO, as one of the bigger push-backs I get from lots of people on SASS is it's "another language to learn" and you don't get any benefit unless you convert everything. That goes away with SCSS.

I'm never giving up the original SASS syntax. It mirrors HAML so closely it makes the separation of semantics and styling so easy and natural.

If I need to paste in some sample css from the web I just copy it to the clipboard and then:

    pbpaste | sass-convert | pbcopy
in the terminal, and the sass is ready to be pasted into the editor.

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

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.

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.

I guess that the benefit comes from being able to get regular CSS files a parse with LESS without syntax modification.

In some cases, that might be a good thing.

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

Dude, long post, little content.

    The point of CS is to optimize for developer 
    productivity and happiness.
That's a subjective claim that I also think is untrue.

CS doesn't have any new paradigms, the type system is the same as Javascript, scoping rules are the same, it's really nothing more than syntactic sugar over JS.

Even Ruby and Python have a lot more differences.

    well that's a good screwdriver, but does 
    it hammer nails
This analogy holds only when you're talking about (a) a screwdriver + (b) a hammer, i.e. totally different tools, with totally different use-cases.

Personally I never understood why people use it to make a point.

>Dude, long post, little content.

I find sometimes you have to repeat yourself a lot before people will understand a point.

> That's a subjective claim that I also think is untrue.

It's obviously my opinion, and I can't speak for the developer....but it's fairly accurate.

To say it's "untrue" it's just plain wrong, and if you're going to suggest that it's "untrue", you should offer your opinion as to what is "true".

Anyway, it's perhaps a simplification and incomplete, but it's demonstrably true.

If you go and read the docs for Coffeescript and what the creator has said, here is the general point made:

- Coffeescript is designed to make Javascript easier and faster to write.

- Coffeescript is designed to reduce some of the headaches associated with Javascript, and make it more expressive.

Those are the immediate goals, but the reason behind those goals is to increase productivity. Increased productivity is WHY those things are desirable.

Nobody just wants to type more JS code per minute for no reason at all.

>CS doesn't have any new paradigms

Well for one, that's not entirely accurate.

For one, In CS everything is an expression, which is not the case in JS.

However, even if we were to grant that point...it's moot.

See, this is why I have to repeat myself. Although it seems despite debunking this misconception over and over you still managed to maintain it.

CS isn't meant to be the latest and greatest language, or exist in a vacuum. If that was the point, why implement it on top of Javascript and put so much effort into making it compatible with Javascript?

CS doesn't introduce new "paradigms" (at least the kind you are getting at) because that's not what it's FOR.

CS isn't supposed to exist independent of Javascript, it exists to generate Javascript.

The fact of the matter is, for some reason some people don't analyze technology based on objective reasoning about it's merits.

In the Javascript world, jQuery and Coffeescript are prominent victims of this.

There's lots of reasons to dislike jQuery....but by far people hate on it for reasons entirely removed from facts.

Same with Coffeescript.

Remarking that Coffeescript doesn't optimize code is a complete non-sequitur.

More importantly this stupid implication that "syntactic sugar" is somehow pointless.

Haters always make some smug implication about CS being "only syntactic sugar", as if that's some sort of actual critique or something.

What these people don't understand is:

Syntactic sugar is a method whereby languages are improved.

There's nothing wrong with syntactic sugar, and it is very much a powerful and useful thing.

I can write list comprehensions in Cofeescript....you can't do that in vanilla JS unless you want your code to only run on certain engines.

That is one example of the power of "syntactic sugar".

People get confused because they mistake it for simple examples of syntactic sugar where

bar (x, foo(x, y, z))

is created from: foobar( x )

In that case the transformation is useful, but so sleight it's questionable whether the effort is worth it.

...but that's not what we're talking about.

>This analogy holds only when you're talking about (a) a screwdriver + (b) a hammer, i.e. totally different tools, with totally different use-cases.

YES... and that is what we are talking about. At least it's sure what I'm talking about.

When you compare Coffeescript to things like:

- Libraries - Code optimizing tools - Debugging tools - etc

Those are totally different tools with totally different use-cases.

If I'm curt it's because I'm sick of this nonsense every time CS comes up.

There's a few people who make actually informed points either for or against it based on facts and technical merits...

...and thens there's a bunch of techno-hipsters who either put it down or blindly adopt it without knowing what they are talking about. (not saying you are in this group, but read the comments any time CS is mentioned and you will see this group)

    When you compare Coffeescript to things like:
    - Libraries - Code optimizing tools 
    - Debugging tools - etc
    Those are totally different tools with 
    totally different use-cases
There's a world of difference between how typical projects are built in C++ versus Java, or in Java versus Ruby/Python, or in Ruby/Python versus Haskell.

And this has more to do with the capabilities of the runtimes, the introspection capabilities available, the available libraries, the debugging tools, the quality of the read-eval loop, the smartness of the compiler/VM to handle errors -- and a lot less to do with whether semicolons are optional.

You're trying to divorce these assets from the job of a programming language, or from the happiness experienced when using said language, but they are not divorceable, just as you can't separate a language from the compilers available (i.e. it's factually incorrect to say that languages themselves are not slow, as most languages in use have been influenced by known compiler/VM optimizations).

And my point about libraries does hold -- to use Rails, you need Ruby, and can't use it from Python because you would need a clone that's built for Python's capabilities, as while the type system is very similar, there are lots of differences (e.g. namespaces, scoping rules, decorators versus anonymous blocks, functions as first-class citizens versus Proc#call, mixins versus multiple-inheritance, method-dispatching itself, etc...).

But Javascript/CS are so similar that they can share libraries effortlessly. CS will never have the benefits of libraries, as those libraries will be usable from Javascript.

    If I'm curt it's because I'm sick of 
    this nonsense every time CS comes up
Dude, if it makes you happier, more productive, do whatever floats your boat. Tickling your aesthetic senses is a perfectly valid point for using a tool. I was just expressing my opinion on the matter.

And truth is I couldn't care less if it is being adopted as a default in Rails. Heck, I've been proven wrong before, and it may actually work out for the best.

Assembly : C :: CSS : Sass

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

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.

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.

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!

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

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

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


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

You can embed javascript if you want:


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.

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

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?

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

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

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

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

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

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

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

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

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

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

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

    for item in list
      item.marked = true
Generates this JavaScript:

    var item, _i, _len;
    for (_i = 0, _len = list.length; _i < _len; _i++) {
      item = list[_i];
      item.marked = true;
... where you have a nice length-cached loop that runs about as fast as JavaScript is capable of.

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

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

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

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

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

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

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

CS has immediately improved the performance of my code considerably.

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

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

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

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

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

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

Jose Valim commented on the commit:

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

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

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

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

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

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

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

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

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.

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

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

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.

default frontend scripting language

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.

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.

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.

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.

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.

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.

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.

Couldn't agree more with you. Good points.

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.

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.

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.


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

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

could you share the gist of his opinion?

Essentially that compotent developers can be trusted to structure their markup in a pleasing fashion and shouldn't have it imposed upon them by a tool.

If I'm not mistaken, at least. It was at the Hashrocket Chicago opening, and quite a bit of drinking had been done at the time. (Probably why I was picking fights ;) )

He hasn't drunk the copious amounts of Kool Aid™ some Rubyists have.


I suppose that may be the case, perhaps my first rails project having been as an intern of Hampton's has coloured my judgment.

That could help. It'd be like taking guitar lessons from Jimi Hendrix - you'd be all like "Man, piano sucks! Guitar rocks!"

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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"

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

It's not MVC though, right? I prefer something more lightweight like Express/Sinatra, but a lot of people are in love with MVC.

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.

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.

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.

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.

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.

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

Who's forcing? Javascript will work just fine.

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

Web development is already a field full of these things:

So it's your first web page, eh? Do you know HTML? No? Do you know CSS and JavaScript? No? Okay, the first step is to figure out how CPanel and PuTTY work ... what? What do you mean Microsoft Word isn't a real text editor? I edited my whole thesis on it. IDE? Isn't that like a hard drive? WTF?

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.

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

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

"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


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.

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!

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.


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.

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.

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

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.

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.

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

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

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/

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

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

Have you tried node.js?

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.

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?

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

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?

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

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

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)

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.

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?

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)

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

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.

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.

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.

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.

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

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.

I didn't realize it was more than a parser; thx for the info.

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

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

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

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"

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

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

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

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

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.

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.

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.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact