Hacker News Reader

Comment by tomfakes | Hacker News Reader

I've been building a new app with the Rails 3.1 rcs for the last 3 or 4 weeks. I still have no idea how to actually deploy into production in a way that has a chance of working.

As far as I can tell, I need the V8 code built on my production boxes! That seems insane, unless I want to switch to using node.js....

On my FreeBSD system, I still have no idea how to get V8 built correctly. I've bailed on it for now and am running my 'production' server with the 'development' environment.

Remember, I'm not running beta software, I'm running a 'release candidate'.

When this works, it'll probably be great, but stick with 3.0 if you actually want to make progress on your application.

View on HN

I think the assumption is that everyone is using some sort of asset packager/JS compiler at this point. I'm not smart enough to hold an opinion whether or not this is a "good idea™", but I can tell you that it's the general expectation.

We use Capistrano to deploy our app, so packaging assets on the way to the server is as simple as an additional deploy task for the production environments. We have a task named precache_assets that uses Jammit [1] to compile assets based on the Jammit settings (stored in a yml file, imagine that).

1 - http://documentcloud.github.com/jammit/

You could compile coffeescript in development and commit the resulting JS file. Automatically recompiled Coffeescript is fantastic in development, but IMO, there's really no compelling reason to be compiling it production-side.

Yup - I'm going to need a 'build for production' system - I've used Hudson for this in the past - that does this and sets up the production push.

(I can't seem to reply to your comment, so replying here)

You could look at using something like a Git pre-commit hook to do that pretty trivially. I personally use a rake task that compiles all my Sass and Coffeescript to their respective CSS and JS files, then packs it into minified-and-gzipped files with jammit, then commit the resulting bundle. I end up serving pre-baked-and-concatenated assets and it works just fine.

This is the best way to do it, and using a continuous integration server to emit a binary as the output of your build, as our ancestors in compiled languages did in days of yore, is a good way to make it happen. You don't even need to commit it; just use the tarball (or whatever) as the artifact of deployment.

Put the coffee-script gem into your Gemfile.

Assuming you have a compiler on the production box, you're fine.

You'll need to add 'therubyracer' (or another javascript interpreter) to your Gemfile. It requires python and a C++ compiler to compile its binaries.

If you're on Heroku, you may need 'therubyracer-heroku' instead - there are compilation issues. Hopefully this will be fixed soon.

This needs the V8 stuff compiled and installed. And then I'm running yet more code on my production servers to deploy. And this code compiles the CoffeeScript to JS, and this will be the very first place that this code will have actually been tested in this configuration.

This deployment scares me a lot -- partly because I haven't yet made it work in an RC build, and mainly because it adds more moving parts to my production servers.

You do not need to use CoffeeScript in Rails 3.1, it is merely the default option. Just delete the "gem 'coffeescript'" line in your Gemfile and just use regular js.

That's the problem though; Rails now depends on an implementation of a second programming language (coffeescript) that's only implemented inside another language environment (node.js) that changes quickly enough that many OSes don't have working packages for it.

Coffeescript is rad as hell, but making Rails depend on it by default without a really great way to install it seems foolish.

Node.js isn't required. You can use any of the seven javascript runtimes that the ExecJS gem supports.

https://github.com/sstephenson/execjs

:s/Node.js/Not Ruby

I admittedly haven't spent much time with Rails 3.1, but isn't that what rake assets:precompile is for?

Automatic compilation of coffee scripts is nice in development, but not overhead you want to add for production anyway.

Reply on news.ycombinator.com