@alecslupu and @microstudi,

So far, I sense the frustration was with the old version, which had many aspects that I didn't like. Or maybe there was some misconfiguration. The default "compile" mode to ensure assets were built was crazy slow. Most developers figured out that running webpack in watch mode or running the webpack-dev-server was much better. I can easily see how some developers missed this.

In terms of the ease with the old sprockets, having all globals is a nightmare for bigger apps.

At the core of webpacker is a configuration YAML file used by both the webpack compilation and the Rails view helpers to allow static assets to be built with webpack, which is a far better-supported system than sprockets.

If you're serious about modern frontends, I don't see how you can omit utilizing the JavaScript ecosystem.

Anyway, it seems that some think it's better to add a lot of code to your project rather than leveraging the open-source ecosystem.

Previously, with webpacker under the Rails core, hundreds of open PRs and issues were not getting addressed.

Now, we're moving as fast as the community contributions come in!

So I think you should give the NEW shakapacker a chance. It's not the old webpacker that you hated!

The main issue we've had with Decidim since the Webpacker migration has been CSS compilation performance. It's not really an issue with Webpacker or Shakapacker (with their own problems, even with version 6 which we are already using), but an issue with the underlying Webpack itself.

Here's few test scripts I put together to help measure the difference between the CSS compilation speed:
https://gist.github.com/ahukkanen/33e5858ae56d216f6ec3986bdec72711

No Webpacker or Shakapacker there. Just to compare Webpack and without Webpack.

To use these:

1. Generate the Decidim development_app as per instructions
2. Go into the development_app folder and put both of these gist files to the bin folder of the app
3. Chmod those files to 755 to make them executable
4. Run both files in the console and see the execution time printed out into the console

Note that you need to run these in the Decidim development_app for the requirements to be met. Also note that they are not feature complete implementations, they just serve to prove a point.

My short testing shows that with the current amount of CSS, the compilation speed is about 5-6x faster when compiling directly with Dart Sass compared to passing it through Webpack. It can be also a misconfiguration with Webpack (maybe Webpack is using the non-compiled version of the sass library?) or maybe Webpack is doing a lot more than we really need in Decidim. I'd rather have fast compilation times than all those features Webpack provides.

It's a real pain developing front-end for Decidim when the CSS compilation takes over 20s+ in general, every time you make a small change in the CSS. Dart Sass alone compiles it in 3-4s which is still much more than the JS compilation speed but it's bearable. This could be probably further improved by applying all the current recommendations to the SCSS files, such as using @use instead of @import but that's a bigger change.

I feel that even if we could improve the Webpack performance, we wouldn't really need it for anything. My gut feeling is that most of that overhead is coming from Webpack itself and if not, feel free to prove me wrong.

In my opinion, we could live with all the workarounds we needed to add to Webpacker (or Shakapacker, doesn't really matter in this context, we probably still need those), and we ourselves haven't even missed the foo.js.erb or foo.scss.erb files that @microstudi mentioned above (they were hack'ish solutions to start with). Those other issues could probably be solved with Webpack mentioned by @microstudi but is it worth the effort to spend time configuring Webpack (which I also feel is a pain) or just provide the build tools that we really need in Decidim? We can find other ways around those issues.

At our end the compilation speed has been the real issue why I also think Webpacker has got bit of a bad rep around here. Even when it's not really Webpacker's fault, it's its underlying engine - Webpack.

Based on this comparison alone, I vote against both Webpacker and Shakapacker. It's not supposed to be any kind of attack against these great libraries, as much as it may seem like in a faceless internet discussion. It's just the amount of problems they bring into the Decidim ecosystem without adding much benefit.

Getting rid of Webpacker or Shakapacker does not mean we would need to get rid of the NPM ecosystem. The NPM ecosystem is still available one way or another with all the alternatives proposed here, even with Sprockets.

I still haven't experimented with cssbundling-rails but I am pretty sure it would provide compilation speeds close to running Dart Sass manually with Node. Or if not, we can build our own build pipeline, it's not that difficult these days as shown above.

I feel most of the hate presented here is directed towards Webpack (like JS failing to build due to configuration issues). Not Webpacker or Shakapacker.

@ahukkanen are you 💯 sure that you used the latest versions of webpack, Node, and other libraries. If you had older libraries or a misconfigured setup (like the old webpacker "compile" backstop), then surely you'll have many performance issues.

What doesn't make sense for this project is the need to reinvent the wheel of webpacker just to use "jsbundling-rails" which is pretty darn minimal. Just check out the commits and source. I contributed to the comparison https://github.com/rails/jsbundling-rails/blob/main/docs/comparison_with_webpacker.md

Given how much code was added to this project to build on top of jsubundling-rails, that decision really puzzles me. We have a much better community now that the rails core folks are gone from webpacker! So we'd rather work with you all to solve the common problems for everybody.

@justin808 No, Decidim is not using the latest version of Webpack but it doesn't seem to improve the compilation speed with the provided examples. You can try it out following the above instructions and running npm un @decidim/webpacker && npm i webpack. The CSS compilation speed does not improve with that.

I don't feel going away from Webpack would be re-inveting the wheel. We really don't need most features in Webpack. Only thing we need is to transpile JS and CSS. Whether in one bundle or as separate files, undecided at this point. For the time being my personal opinion would lean towards the bundled files but there may be valid reasons to decide otherwise. It's still up for discussion (see the discussion below).

I experimented a bit with sass-embedded and it cuts the CSS compilation time into about half from the experiment above when not using Webpack. So the whole Decidim SCSS compiles in less than 2 second when using sass-embedded (it's a drop-in replacement for sass, so you can just switch it in the example test-sass script posted above).

Yet again, if we wanted to use that with Webpack, it's not possible right now:
webpack/sass-loader#774
webpack/sass-loader#1031

I also checked and confirmed that under the hood, Webpack's sass-loader was already using the same implementation, so the comparison above is valid:
https://github.com/webpack-contrib/sass-loader/blob/bbb3cf27b940a8c6d82f0795e1977da89dd942cc/src/utils.js#L13