3 ms·

If it still relies on CoffeeScript, it's a great argument against Rails.

by mercer 9y ago

steveklabnik 9y ago
Rails doesn't rely on CoffeeScript. It includes support for it by default, but you don't have to use it, and you can never start using it by passing a flag to `rails new` or removing the `coffee-rails` gem from your Gemfile.
- mercer 9y ago
  How do the default affect the ecosystem these days, though? I remember back when I used Rails and CoffeeScript was the standard, it took a bit of work to avoid it altogether. This wasn't difficult, to be fair, but it felt like pointless busywork nonetheless.
  - steveklabnik 9y ago
    I couldn't tell you, as I haven't been really involved in Rails for a while. I never used coffeescript for any serious project, even when this change was made back in 3.1, and I can't remember it ever causing trouble. YMMV.
  - rickyc091 9y ago
    jQuery was removed in the latest version of Rails in favor of rails-ujs, essentially a vanilla js version of jQuery so `remote: true` and things like that would still work. Erb / vanilla js is still the default stack for beginners. But they've started to move away from the asset pipeline and they've built in webpack.
always_good 9y ago
I think the kneejerk hate on Rails by Coffeescript proxy is a good example of why developer-hate on forums like HN is a pitiful metric for scoring an ecosystem. It's such a non-issue. In fact, what's impressive is how Sprockets (part of Rails asset compilation) can chain together arbitrary file transformations by looking at the extension. `file.coffee.erb.whatever` will get processed as with the tool configured for `.whatever` files, then it'll eval Erb's <%= ... %> tags, and then finally get processed as Coffeescript before being concat into the bundle. I always thought that it was a really intuitive way to specify transformations. But the thing is that you need Rails experience to appreciate a solution like that, and it's easier to write off Rails entirely because someone says that it depends on Coffeescript. In reality, Rails just shipped with the Coffeescript handler so that Sprockets could understand .coffee extensions if you chose to write .coffee files. Technology-hate only serves to confuse beginners by making them think everything is black and white. And by making them think that they are making a mistake by learning one ecosystem over another when in reality everything has trade-offs and it's better to learn something over wallowing in the paralysis of indecision. Half of these comments aren't even capable of comparing Javascript to Ruby without bringing up Webpack and the complexity of client-side bundling as if Ruby is a client-side language.

If it still relies on CoffeeScript, it's a great argument against Rails.

by mercer 9y ago

If it still relies on CoffeeScript, it's a great argument against Rails.

Rails doesn't rely on CoffeeScript. It includes support for it by default, but you don't have to use it, and you can never start using it by passing a flag to `rails new` or removing the `coffee-rails` gem from your Gemfile.

mercer 9y ago
How do the default affect the ecosystem these days, though? I remember back when I used Rails and CoffeeScript was the standard, it took a bit of work to avoid it altogether. This wasn't difficult, to be fair, but it felt like pointless busywork nonetheless.
- steveklabnik 9y ago
  I couldn't tell you, as I haven't been really involved in Rails for a while. I never used coffeescript for any serious project, even when this change was made back in 3.1, and I can't remember it ever causing trouble. YMMV.
- rickyc091 9y ago
  jQuery was removed in the latest version of Rails in favor of rails-ujs, essentially a vanilla js version of jQuery so `remote: true` and things like that would still work. Erb / vanilla js is still the default stack for beginners. But they've started to move away from the asset pipeline and they've built in webpack.

always_good 9y ago

I think the kneejerk hate on Rails by Coffeescript proxy is a good example of why developer-hate on forums like HN is a pitiful metric for scoring an ecosystem. It's such a non-issue. In fact, what's impressive is how Sprockets (part of Rails asset compilation) can chain together arbitrary file transformations by looking at the extension. `file.coffee.erb.whatever` will get processed as with the tool configured for `.whatever` files, then it'll eval Erb's <%= ... %> tags, and then finally get processed as Coffeescript before being concat into the bundle. I always thought that it was a really intuitive way to specify transformations. But the thing is that you need Rails experience to appreciate a solution like that, and it's easier to write off Rails entirely because someone says that it depends on Coffeescript. In reality, Rails just shipped with the Coffeescript handler so that Sprockets could understand .coffee extensions if you chose to write .coffee files. Technology-hate only serves to confuse beginners by making them think everything is black and white. And by making them think that they are making a mistake by learning one ecosystem over another when in reality everything has trade-offs and it's better to learn something over wallowing in the paralysis of indecision. Half of these comments aren't even capable of comparing Javascript to Ruby without bringing up Webpack and the complexity of client-side bundling as if Ruby is a client-side language.