goodbye-to-asset-pipeline-talk

View Github Repository Open presentation in a new window

pferdefleisch

See all presentation from pferdefleisch

goodbye-to-asset-pipeline-talk

0 0

goodbye-to-asset-pipeline-talk

talk given at viennarb vienna meetup 06/02/2014

On Github pferdefleisch / goodbye-to-asset-pipeline-talk

Bye Bye Baby

by @mraaroncruz

servus

First a show of hands How many of you build "single page applications"? I have only expiremented with what I am about to show you and I have only done it using "single page applications" so it's up to you to decide how applicable it is to your use cases.

So, the asset pipeline

The asset pipeline was created to solve some problems we all had a few years back.

The Problems

  • compressing JS and CSS
  • compiling SASS and Coffeescript
  • combining JS and CSS source files
Before the asset pipeline I had built my own tools to take care of file concatenation and compression

Guard uglify

Guard sprockets

So I was and am pretty invested in the Asset Pipeline. I like the asset pipeline. It has saved me countless hours in the past. This isn't talk against the asset pipeline. It is more a talk about cargo culting.

Cargo Culting

Just because the rails core team added the asset pipeline doesn't mean it is the best tool for the job. Just like some people use Data Mapper or Mongoid or Presenters instead of helper methods. In the time since the asset pipeline was created, there have been some pretty neat solutions to the problems the asset pipeline attempts to solve.

I just gave a talk at viennajs about yeoman. It combines bower which is like ruby gems for front end libraries, JS, CSS, etc with Grunt which is kind of like Rake or Thor combined with Guard. It also adds a generator layer which one of the things that brought a lot of us to Rails in the first place. It allows you to build and iterate on front end heavy web applications with ease, watching for changes, and running tasks you set up when those changes happen.

Nice

How?

create a folder in my rails root, let's call it frontend/ I generate my front end app in this directory install grunt proxy plugin Make build target ../public Start shipping code NOW!

Grunt proxy plugin

  • this will proxy calls to a certain endpoint to a host and port of your choice.
  • set it up to proxy /api/v1 to localhost port 3000
  • Any Yeoman /api/v1 endpoints will be in my rails app under localhost:3000/api/v1 So it essentially feels like i am in the public directory of my rails app, when I am not.

Main benefits

Switch out backends

this means that you could swap out rails for sinatra, cowboy, some weird Haskell shit, couchdb endpoints - it doesn't matter.

Separation of concerns

You can start to think about your app as separate services.

Flexibility at the expense of simplicity

Team can focus on their part

Different members can make changes without affecting others as much

Front end dependencies

Bower is great. We use rubygems, we should care about our front end code too.

Should this be Rails' responsibility?

Rails workarounds

Guard

watches for file changes, runs tasks

Konacha

javascript test runner/framework

Bower

yeah, we can use bower with rails(if you want to know how, ask me after the talk)

Backbone-on-rails, etc.

scaffolding for app/assets/javascripts

I realize that most of this stuff can be worked around using gems

Thank you

http://aaroncruz.com

@mraaroncruz

http://github.com/pferdefleisch

Ask about next month's talk