Well at compile-time, I think the ruby based SASS/SCSS assets are much faster than Webpack–and that almost goes without saying, since I don’t think JS is nearly as fast as Ruby and Webpack relies upon so many plugins to actually act as the “asset pipeline”.
I definitely get frustrated by how long it takes Webpack to just confirm that 99% of my assets haven’t changed when I make a small design tweak.
Full disclosure though, I feel like Webpack could be much more highly optimized than it is out of the box, and then it would be a decent solution. Sprockets feels like it was relatively lean compared to the massive dependencies Webpack requires to function.
I haven’t fully migrated any projects to use exclusively webpack yet.
I think documentation, such as improvements to the Rails guides, could help here. We could help address questions about setup, such as directory names and layout, both for developers that prefer the Rails default (Webpacker for JS, Sprockets for CSS and images) and the “all-in” on Webpacker approach.
I have tried chunks, and chances are good I’m just not using them correctly. It does still take an impressive amount of time for webpack to only compile and then review all of the chunks to see what’s changed.
I’ll look into this more though. It has been extremely tempting to switch back to the asset pipeline for SCSS/images. I don’t use utility frameworks like Tailwind, so I don’t think I would really be losing anything by doing this.
But what we have now, where Webpack by default is for JS compilation, the Asset Pipeline for css/images/etc, is not a concession to some legacy setup. It’s the legitimate choice based on how I like to build applications. We’re building a new app at Basecamp called HEY, and it’s running this combo, and we’re very happy with that.
Which comes to an even larger point: Rails is a very big tent. We’re never going to have everyone agree on the entire toolset, when we’re this ambitious in how much Rails should have a say in.
So that leaves us with a much easier path: The default will be the creator’s prerogative (informed/influenced/assisted by a broad community), and then we’ll codify major dialects with nicely paved options that make it easy for us all to enjoy the tent together! We don’t have to agree on whether Webpack is better at image compilation than sprockets in order to share and collaborate on Active Record. And so on.
In short: Let’s try to build consensus around a webpack-only dialect. What should the directory be called? How do we remove sprockets best by default? And then we need a champion or a group interested and dedicated to maintaining this dialect.
Perhaps not as cute, but we’ve used app/webpack_assets/ instead. Fairly non-controversial on its face, and honestly, if the immediate future supports both webpack and sprockets working in tandem, why muddy the waters not calling out the directory explicitly?