- The Asset Pipeline lives outside of the npm build tool ecosystem where the most cutting edge tools live. Developers working on Rails apps have no hot module reloading, no css code elimination, and no ES module loading by default.
- The Asset Pipeline is very slow when building assets for deploy. I've seen 3 minute builds and I've heard of 10 minute builds.
Why the hell would anybody use it, then? Before you rip it out and replace it with something else on day one of your project, check out this list of features that you'll be responsible for recreating.
- Your servers, I mean your cloud, is going to need to have node and npm installed.
- Use Heroku? You'll need a build pack. Use Capistrano? You'll need a custom command or a plugin. Don't forget to cache the node_modules folder, otherwise your node based asset build is going to take just as long as the pig-slow Asset Pipeline one.
- The per deploy cache busting and smart handling of old asset paths so that email assets don't break. You didn't forget about email assets did you?
- Once you get your cache busting working you'll need a replacement Rails asset path helper which is used in both Rails views and (s)css files. Good luck finding npm based tools that have good awareness of how Rails views work.
- File watching with rebuilds. Ideally one that doesn't break whenever you add a new file, I'm looking at you gulp watch.
- If you're working with really good frontend folk then you'll need Sass.
- Installing well known CSS frameworks like Bootstrap are a snap with the Asset Pipeline so get ready to set aside time to figure that out. (And if you're not using Bootstrap then you probably don't need the css code elimination and your builds probably aren't that slow, so why are you trying to get rid of the Asset Pipeline?)
- Planning on using Browserify or Webpack? Great. Don't forget to budget time to figure out how to get your jQuery plugins to work. One such plugin ships with Rails and allows jQuery's $.ajax to work with Rails's CORS protection. Disabling that protection is pretty fucking irresponsible.
- Don't forget to setup the build for your tests too. Unit tests and integration.
Once you get all of that implemented then you'll have lightning fast builds with the newest tools at your disposal! Here are a couple other things to consider, though.
- Many Rails gems assume that you have The Asset Pipeline, so if you're using any of those, the best you can hope for is using BOTH The Asset Pipeline and your new build. You'll still get access to the cutting edge npm build tools, but your deploy and development page reload speeds may still be slow.
- Running rails s won't cut it anymore, you'll need another process running in development.
- Wiring together frontend tooling is its own skillset. You'll need to budget time to transfer that knowledge to other developers.
- On the off chance any of that tooling that you wired together had any bugs, you may have trouble finding the answers on Stack Overflow. Your teammates will be using you as their build support. Contrast this to the crap we deal with in The Asset Pipeline. WE. The answers are almost always one Google search away.
- The cutting edge changes quickly. If you replaced the Asset Pipeline last year then you probably did so with gulp which means that you would need to setup your tooling from scratch this year if you wanted to take advantage of Webpack's hot module reloading. Who knows what the darling build tool of choice will be next year.
I sympathize with the desire to start new Rails projects without facing the inevitable failures of The Asset Pipeline. I really do. However if you begin your project by re-implementing it then you might be putting your project at risk, and a failed project has no asset compilation problems at all.
There are very good reasons to replace the Asset Pipeline but there are even better reasons to live with it for as long as you possibly can.