It’s been two months to the day since my first experiment to see how Jax could be used with Ruby on Rails. Since then, the entire project has been revamped! It is now even more robust, making use of Rails directly and integrating with Rails apps seamlessly. Let’s take a breath, now, and check out an overview of the changes and new additions:

• Lots of TLC for Rails applications. Rails v3.1 and above are officially supported.
• No lack of love for those of you who prefer “vanilla” Jax. If you just need to build a static WebGL application, you can do so with no change in your existing workflow.
• Jax now understands CoffeeScript! By default, if the CoffeeScript gem can be found in the bundle, Jax will generate CS code. If the gem can’t be found, Jax will fall back to standard JavaScript generation automagically.
• A new development suite has replaced the old interface. It splits the runtime and test suites into two separate sections, since the previous approach of merging them both into the same page invariably ran into performance problems. It also adds a third section, in which developers can test drive their materials in isolation from the rest of the application.
• The runtime section, where the WebGL application is run in its entirety, can be configured to point to any page within the Jax application. This allows you to test drive it such that it behaves exactly as it will in the field.
• All of the guides have been updated to reflect the more minor changes in the framework, and the Getting Started guide has been updated to include how to get started in a Rails application.
• All of the Jax generators now tie directly in with the Rails generator system. They can even be executed with the `rails` command, or executed with the `jax` command for both backward compatibility and as a short-cut so that you don’t need to add the Jax namespace to Rails commands.
• Jax no longer precompiles “jax.js”. It is now integrated directly into your application’s JavaScript code. The major benefit to this is that there are fewer requests required to load your application, and thus a shorter load time.
• The task of packaging your application just got better. Jax will now minify the JavaScript source files it produces when you are getting ready to run it in production. This is one of the many benefits that comes “for free” by letting Rails play a more influential role in how Jax works at the lowest levels.

As you can see, a lot of work has gone into this release. Expect more posts in the near future that will overview how to make the nuances of Jax work for you.

In the meantime, you should take a look at the Getting Started Guide if you haven’t done so already! It’s been updated to reflect Jax v2.0.

If you’d rather see Jax in action, check out the live demos page.

As always, if you have any questions or comments, feel free to leave them on the forum. Issues can be raised at the issue tracker on Github.

If you’d like to get involved with Jax development, head on over to the respository at Github!

 

Upgrading

For those of you using Jax v1.x, there are a few steps you’ll need to take in order to make the upgrade happen:

With Rails

Follow these instructions if you are developing Jax and are using Ruby on Rails:

1. Add Jax to the Rails Gemfile:
   gem “jax”, “~> 2.0″
2. Install the bundle:
   bundle install
3. Run the Jax install generator:
   rails generate jax:install
4. Scroll down.

Without Rails

Follow these instructions if you are developing Jax and not using Ruby on Rails:

1. Install the new Jax gem:
   gem install jax -v 2.0
2. Generate a brand-new Jax application:
   jax new application_name
3. Scroll down.

Either Way

Regardless of whether you are or aren’t using Rails, follow these instructions after generating the new application:

1. Copy all app/controllers/ files from the old application into app/assets/jax/controllers/ in the new one. Delete or overwrite the new application controller.
2. Copy all app/helpers/ files from the old application into app/assets/jax/helpers/ in the new one. Delete or overwrite the new application helper.
3. Copy all app/models/ files from the old application into app/assets/jax/models/ in the new one.
4. Copy all app/resources/ files from the old application into app/assets/jax/resources/ in the new one.
5. Copy all app/views/ files from the old application into app/assets/jax/views/ in the new one.
6. Copy all app/shaders/ files from the old application into app/assets/jax/shaders/ in the new one.
7. In the new application, rename all app/assets/jax/shaders/*.ejs files so that their extension is glsl instead of ejs. (Example: common.ejs => common.glsl)
8. In the new application, rename all app/assets/jax/resources/*.yml files so that their extension is resource instead of yml. (Example: teapot.yml => teapot.resource)
9. Copy all public/ files from the old application into public/ in the new one.
10. Copy all spec/javascripts/ files from the old application into spec/javascripts/jax/ in the new one. Afterward, delete the spec/javascripts/jax/support folder.
11. If you have any plug-ins installed in the old application, install them again in the new one.

Deprecations

If your old code has a lot of //= require‘s in them (controllers were generated with them by default), then the require path is now relative to app/assets/jax. For instance, to require the ApplicationController (which is no longer necessary, but as an example) the path would be “controllers/application_controller” instead of just “application_controller”.

If you have written your own shaders, the setUniforms and setAttributes functions within the material.js file were generated with calls to $super. Remove this call, and also remove $super from the functions’ argument lists.