Finally. As "opinionated software", the success of Rails depends on neatly slotting into the well-worn groove of best practices adopted by its user base. Like it or not, jQuery has filled that role nicely for client-side javascript for quite a while now.

Rails is opinionated software, but it isn't the opinions of its userbase; It is the opinions of DHH. If DHH/37 Signals isn't using it, it probably isn't going to make in to Rails core. I am not saying that this is a bad thing. Having the defaults based on a profitable, stable web app with millions of users isn't the worst idea.

> If DHH/37 Signals isn't using it, it probably isn't going to make in to Rails core. I am not saying that this is a bad thing.

That jQuery made it into Rails shows that it's not just DHH's app skeleton anymore; it remains to be seen if ActiveSupport will ever quit being DHH's junk drawer[1] though.

[1]: https://github.com/rails/rails/blob/master/activesupport/lib...

That was introduced by this guy: https://github.com/jeremy

Don't know that I understand what he means by accessing "the reddit", though.

A while ago a 15-20 line patch was committed, which added the methods Array#second, Array#third, etc. These methods were added as syntactic sugar, in order to complement the built-in Array#first. What followed was a huge uproar on Reddit; people called the patch "bloat", claimed that Rails is growing into an uncontrollably large monster, etc. The uproar was not unlike the recent uproar about Coffeescript in size. DHH made fun of that by adding Array#forty_two.

It was added as a joke in response to the controversy on reddit about the original commit.

So before every Rails release DHH should conduct a public poll? And what level of abstraction it should be? "Which JS framework should be made default" or "Should we have a default JS framework"? As you can see, it quickly becomes a mess. Opinions bring sanity.

I think you may have misread my comment. I was saying that it isn't necessarily a bad thing.

If anyone is curious, the default accepts header in jQuery is

    */*

which means, "give me whatever you have." This will actually cause Rails to respond with whatever the first format is that you happen to have defined with your respond_to or respond_with method in your controller.

This isn't very intuitive, which is why we made the jquery-ujs set the default accepts header for remote requests to

    */*;q=0.5,text/script

which says, "give me whatever you have but I prefer JavaScript if you have it."

This isn't clear. Are you talking about the default accepts header in a jQuery AJAX request or in some jQuery script loader script that rails uses to load the jQuery library?

Sorry, I was talking about the default accepts header for jQuery AJAX requests.

Keep in mind that you can specify whatever data type you want with jQuery. The default I speak of is just for when you don't specify any data type.

erm... Ruby On Rails was bundling prototype ever since and was using that by default for their JS needs.

Prototype might actually be a tad bit older than jQuery even and it tries hard at "rubyfying" JavaScript. Because it does so by happily extending built-in prototypes and because it's a huge amount of monolithic code, over the years, people began moving to jQuery.

And now, finally, Rails is moving too.

Also note that with Rails 3.0, they began using data-* attributes for the framework-provided JS-dependent logic, so it became possible to easily replace the built-in prototype with jQuery. For 3.1, they are just switching the default.

Rails doesn't have it's own JS library. It initially used only the prototype library (which exists outside of Rails), but with Rails 3 any javascript supplied by Rails was made library agnostic.

RJS is a rails specific thing, but it's more a method of generating javascript inside of rails than a JS library in it's own right.

This change simply changes the default from Prototype to JQuery - a long-overdue change IMO, since the vast majority of the Rails community has been using solely JQuery for quite a long while now.

Here's hoping that the same treatment is done to RSpec vs. TestUnit.

DHH had already made it clear that RSpec will not get into Rails.

Rspec doesn't really need to be in the default stack; switching to it takes what; a minute? That's not a benchmarked timestamp, but I'm just saying... :-)

Prototype was never "rails' own" js library. It existed before rails AFAIK.

Prototype was actually written by Sam Stephenson who these days works at 37signals and has been part of the Rails Core team since it's inception (read, before making prototype).

Prototype is a stand alone library and predates jQuery by almost two years. jQuery is more or less a direct descendent of Prototype and reimplemented all it's features with a slight twist to emphasis method chaining which was a key insight that simplified everything.

I stand corrected.

Rails has been using prototype/scriptaculous up to now.

Unrelated. CoffeeScript is a language which compiles down to JavaScript; jQuery is a JavaScript library.

No, CoffeeScript and jQuery will both be defaults in Rails 3.1

Note that this is not news. It just happens to be a blog post about the change. The actual news about switching to jQuery was over a month ago.

Unrelated as commented by others but glad you brought it up for anyone else that was confused.

Maybe I misunderstood the situation here. I thought the adoption of CoffeeScript is more like going the GWT way (not quite, but similar) --- you write code in CoffeeScript and let it generate all vanilla Javascript code doing the frontend work, e.g., communicating with the server, DOM manipulation. I do personally think that's a good approach. Now, you also have jQuery in the toolkit, which I suppose is used for DOM manipulation, that's another tool to learn. If you guys just replace Prototype with jQuery, it is reasonable, or just CoffeeScript, which is radical, but sounds like a neat approach. However, CoffeeScript + jQuery? I just don't think it make sense here. Honestly, I only have superficial knowledge of CoffeeScript and jQuery, I could be totally wrong.

Maybe somebody in the Rails core team should write a blog to clarify their strategy on their Javascript integration.

CoffeeScript doesn't generate JavaScript in the same way GWT does, it's more a thin layer of syntax for Javascript that compiles one-to-one to Javascript. It's an abstraction layer, rather than a library that provides functionality like jQuery.

For reference: http://jashkenas.github.com/coffee-script/

So in 3.1, if you were to write frontend code, are you supposed to write it in CoffeeScript, or jQuery?

You can do both, or neither and choose something else you are more familiar with. Just because Rail's opinion is to use X does not mean you do not have the ability to use Y.

CoffeeScript is much like HAML or SASS, where the end result is actual Javascript that can be parsed by the browser. It's only designed to make it easier to write the code, not to replace the code. When I write HAML in my Rails app, the app parses it and send the browser actual HTML. CS will do the same.

You can write CoffeeScript that uses jQuery, so that it compiles down to Javascript that uses jQuery.

You can also use Javascript and jQuery directly.

Or you can write CoffeeScript without using jQuery at all.

My concern is that those combinations can significantly reduce Rails apps' maintainability. I wonder if jQuery is that good, can it be rewritten in CoffeeScript? Such that we can settle down at CoffeeScript, which looks like a better language anyway, and get rid of the Javascript fragmentation issue all at once.

You really can't write coffeescript without knowing javascript. Really, the /only/ documentation for the language is showing what the compiled javascript looks like, plus maybe handling inheritance a bit better.