Assets management solved: we released Rails Assets

This week we are giving out to the Ruby community an assets management solution we’ve been working on for the last couple of weeks: Rails Assets.

Showcase

Tymon showcased Rails Assets during London Ruby Users Group meeting on Monday.

Watch the video from the talk and see the slides below:

Story

Since the advent of asset pipeline in 3.1, we entered Bronze Age of dealing with client-side libraries in Rails apps. All other frameworks were left behind in the dark ages of manual upload of whatever was needed to the /public directory.

However we all know this is a mess behind the curtains anyway. Everyone still manages their own vendor/assets in project codebase and makes sure it’s up to date with the original libraries. RubyGems versions often stay out of sync for weeks, if not months. There is not enough community support. Mostly because it’s manual, tedious job to keep the gems in sync with latest updates from the outside world.

On the other side of the battlefield, front-end people ignored the Rubyists completely. They came up with Bower to ease their lives with package management of their tools of choice. It solved the issue for them as they mostly didn’t care about the Gemfile.

The missing link between reasonable asset management in Rails apps struck us as obvious every time someone had to update old client-side libraries by hand in a specific project. And repeat that for other projects, periodically. It’s almost as if you just realized something is completely broken with what we were doing. Whenever possible we would leave everything in initial state, serving its purpose, letting it rot and get old in peace. #technicaldebt

Given that we mostly work with SPAs these days, this became an even bigger issue. Because then, by the end of the day, the core libraries and toolkits used in our apps were managed by hand. Party like it’s 1999.

Rails Assets is what came out of this thought process and that addressed this problem. A proxy between Bower and Bundler which essentialy means both the front-end and back-end met in between with a firm, friendly handshake.

No wonder this baby initially had two fathers: Tymon Tobolski, Monterail’s CTO, and Dominik Porada, our UI designer & frontend engineer. It’s now being actively supported by Adam Stankiewicz, who is the main contributor.

We have tested it and are using across most of our projects that are live. We can’t stress how much our workflow has improved internally. We are already saving time and our clients’ money with this.

Technical highlights

The most exciting piece is that the missing gems will be built on the fly. This is a killer feature that uses existing Bower library goodness to the maximum. If a package does not exist yet in Rails Assets and is being required (say, rails-assets-angular-leaflet), Rails Assets will try to look it up by name in Bower, create a gem ad-hoc and send it your way.

We also had the chance to add little icings like a note that will be printed out for packages with incomplete Bower manifest files about how they should be called from the app when they are being installed via bundle. It's not elegant at all so while you're at it why not update the manifest yourself and make sure you are the last person seeing this message.

What happens next

We are now mainly relying on you and the community support. Please give it a spin, see how this performs in your projects. Spread the word and let others free themselves from the manual work. Let us know if there are any issues. We want this to become a solution for everyone looking to make their work more efficient. Maybe there is a better way, maybe we have overlooked something. We are looking to hear from you with all kind feedback and questions. Thank you!