If you're already using webpacker
, you may be wondering how it compares to jsbundling-rails
and whether you should migrate or migrate to shakapacker
the official fork of webpacker
. Note, the shakapacker
fork still uses webpacker
name within the project, allowing an easy trial. So the below discussion applies to v6+ of webpacker
/shakapacker
vs jsbundling-rails
.
Here are some considerations between the two:
jsbundling-rails
is a simple integration composed only of installed files and a couple of new rake tasks.webpacker
/shakapacker
, on the other hand, provides view helpers and a customizable webpack config that include support for the most important advanced features of webpack: code splitting and HMR. You don't need to use thewebpacker
webpack config. You could choose only to use the view helper portion ofwebpacker
/shakapacker
.jsbundling-rails
can be used with multiple bundlers (currentlyesbuild
,rollup
, andwebpack
are supported out of the box, but anything that can put a bundle intoapp/assets/builds
could be configured to work with it).webpacker
/shakapacker
is built specifically to integrate withwebpack
. That allowswebpacker
to provide support for HMR and code splitting.jsbundling-rails
doesn't tie you to specific versions of the JavaScript packages you use for bundling, transpiling, etc.webpacker
/shakapacker
releases are also not tied to a specific major version ofwebpack
,babel
, etc. as these are handled because webpacker specifies these as peer dependencies.jsbundling-rails
uses the standard configuration format for your bundler of choice.webpacker
/shakapacker
has an optional configuration layer on top ofwebpack
's configuration. You don't have to use it. The only requirement of webpacker is that your webpack configuration must produce a manifest.jsbundling-rails
works with the standardactionview
asset helpers.webpacker
/shakapacker
provides view helpers with an almost identical API.webpacker
/shakapacker
can be used as a complete replacement forsprockets
, and in that setup you can stop loading thesprockets/railtie
in your application. What you produce in the webpack ecosystem is what is sent to the browser.jsbundling-rails
(as well ascss-bundling-rails
) works in conjunction withsprockets
. Because of this, you need to be sure not to double fingerprint your assets in bothwebpack
andsprockets
. You might also have issues with source maps due to double fingerprinting of output files.webpacker
/shakapacker
supports using thewebpack-dev-server
for hot reloading. HMR enables you to see your changes in the browser almost immediately as you make them, usually without the need to refresh the page or lose your application state.jsbundling-rails
hands over static files tosprockets
, so hot reloading is not supported. To load any JavaScript changes, you'll need to do a local-state-clearing full page refresh.webpacker
/shakapacker
delegates asset processing entirely to the external nodejs tooling.jsbundling-rails
still relies onsprockets
to output the finalpublic
assets and create the associated manifest.webpacker
's complete control over the resulting webpack output files allow it to integrate additional features like automatic code splitting. Webpack provides advanced optimization to split your staticallyimport
ed shared dependencies. Thewebpacker
/shakapacker
view helpers will automatically specify each entry point's dependent chunks for you in the resulting HTML. Withjsbundling-rails
, you'll be able to manually split out lazy-loaded chunks by using dynamicimport()
s. However, the manual approach would be challenging to maintain on a large project. Why is this important? Code splitting allows the browser to download only the JavaScript and CSS needed for a page, improving performance and SEO.