Do you really need asset management in your Sinatra app?

Do you really need asset management in your Sinatra app?

You’re just doing this simple and naive proof of concept, don’t you? At least that’s what I’m doing - I want to get this thing working ASAP and don’t care if it’s state of the art ;-)

I’m doing this little site for managing Sparkle appcasts and recently added my first external component - it’s a drag and drop directive for AngularJS.

This led to a weekend full of playing with assets pipeline. What’s assets pipeline? It’s the whole process of transforming what you wrote in your preferred language (CoffeScript, JS, or whatever) to something digestible by the browser and serving it to clients. Preferably automated.

I started first with sinatra-assetpack which felt more natural to the app (since it’s Sinatra app), I quickly made it work in a development env, but with no luck on the production.

Later found sprockets which is a generic (or mostly rails) solution, compared those two on ruby gems the first has around 30k downloads, the other 1,2M.

Setup was quite easy thanks to Peter Browne, with a couple of fixes I made it work as I wanted (processing files on the fly and caching them).

Had to set :digest_assets, true and add configure :production with:

assets.js_compressor = Closure::Compiler.new

assets.css_compressor = YUI::CssCompressor.new

uid = Digest::MD5.hexdigest(File.dirname(__FILE__))[0,8]

assets.cache = Sprockets::Cache::FileStore.new(“/tmp/sinatra-#{uid}”)

But did I really need it a this stage?

Well, truth to be told that was a premature optimization, I should have spent this time actually working on the app itself.

Sure it was nice to learn that your AngularJS code breaks after minification, but I could have waited to learn that a few more weeks ;-)

What seemed like a trivial task took me too many precious hours. Sure I learned something in the process which is valuable but still didn’t have too.

I need to be more careful if I want to finish this ;-)