RIP Sprockets Asset Pipelines

rubyonrails-core
1

Rails has always been about best practices in web development, not what’s popular. If this were the case, why didn’t rSpec make it as the default test suite in Rails 2?

Unfortunately now, Rails 6 will contain bloat. But more concerning, leave most web developers vulnerable, as most will unknowingly install Node with sudo, making node_modules owned by root, allowing for some fun executions…

For a moment, Sprockets allowed us to align our Javascript with our MVC resources, it was maintainable, good design, that put Rails developers on the same page. But starting with Rails 6, we will divide - some into Angular, some into React, or Vue, or any of these other exotic front end frameworks that repeat yourself in generating HTML.

2

Most frontend tooling has a build step now, the build step depends on node/npm. It's much cleaner to separate the javascript/css out from sprockets and use webpacker instead. For example, you'd need this for css frameworks like tailwindcss that have a build step to generate only the css you need.

I'd disagree that "most" developers are making the mistake of installing node as root. Even homebrew doesn't do that.

I agree there is tension due to the duplication of HTML generation on server side vs front-end side. It's unfortunate. I'd love it if we could have a full fledged SPA using only rails views/templates/logic. Otherwise it's forcing us to relegate rails to just an API, and do SSR in node instead.

3

Dominic, as a JS/webpack/node.js dev who has come to love Rails, don’t judge webpack by webpackER. Rails devs from the JS/webpack side of things are just as unhappy with webpackER. (the bloat is real)

There is a reason why “procedurally generated javascript” is universally condemned. WebpackER uses YAML to generate a JS file that then compiles your project JS files. What could go wrong?

image.png
image.png706×316 29.6 KB

If you want to use accomplish simple tasks without playing whack-a-mole, I would check out https://github.com/nikushi/webpack_manifest which was inspired by https://inside.pixiv.blog/subal/4615. (in english)

If you want to see my reasons for speaking out against webpackER, you can look at an earlier email thread (https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/rubyonrails-talk/ST2Z8S85CFM) where I make the case that webpackER isn’t bad, it just has taken on more than it can handle.

Last year, DHH asked me to be part of the solution and I have been trying my best, but there are distinct pain points that core maintainers need to start listening to if they want webpackER to fill Sproket’s shoes. I hope that we can all fix this.

PS: Try not to use homebrew for installing node, always try and use nvm (esp. for mac).

4

James,

I’d love it if we could have a full fledged SPA using only rails views/templates/logic.

You can! Best of all, without any APIs and with all the goodies of React. Here’s a bit of self promotion:

https://github.com/jho406/Breezy

It also works like Turbolinks for easy SPA functionality. While Turbolinks requests the next page’s HTML and does a <body> replacement, Breezy requests the next page’s props (written using jbuilder-like syntax) and does a replacement in your redux state. No APIs needed, since, like Turbolinks, just reuses your routes.

Here’s a small visual of the end product

  views/
posts/
index.js.props
index.jsx
show.js.props
show.jsx

Breezy delegates the responsibility of markup to React and the responsibility of content (index.js.props) to Rails.

You can do a lot of things like fragment deferment, fragment fetching, preload multiple pages in a single request, instaclick-ing. There also room for custom reducers when you need to do something more complicated.