Just for a bit of history here. When we adopted Webpack as the preferred solution to compiling modern JavaScript in Rails, it was because Webpack offered a superior solution to Sprockets when it came to JavaScript compilation. But none of those advantages were present – at least at the time! – when it came to stylesheets or images or any other static assets. The asset pipeline required less configuration, was faster, and was easier to overall integrate.
Now I appreciate that some of this perhaps comes from the fact that we don’t build SPAs at Basecamp? Maybe there are some component scenarios where people are bundling images and stylesheets together with their JavaScript work, and in those cases, it would be easier to use Webpack directly. As far as I recall, we’ve made provisions for this already. But I could totally see if it’s not very well explained.
Anyway, to the larger question: Should Rails just use Webpack for all asset compilation? The answer is: sure, when Webpack can do it better than the asset pipeline, for the non-component based approach. I haven’t looked at Webpack 5. It’s possible that this deals with CSS and digested images and all the other Sprockets concerns better. If so, I’d love to see a bake-off. Show the whole pipeline working smoother, faster, with as little or less configuration, and with as good or better error messages.
But before we even consider expanding Webpacks role in the Rails asset compilation pipeline, I think we’d do well to document, clean-up, and polish its role as the preferred JavaScript compiler and packager first.
