Phoenix 1.4 ships with webpack - but that doesn’t mean you are stuck with it (but there certainly are reasons to stick with it).
Apart from all the other benefits that bundling can give you - the one that sticks out the most for me is: Modules.
Over the past years I’ve cooled on classes in general because of their typical association with mutability but some form of code organization is needed for any non-trivial codebase.
Before, there was always the danger of polluting the browser window’s global namespace with many errand, potentially conflicting global values/objects as they were loaded through the various
<script> elements scattered throughout the web page. One could (though some libraries wouldn’t) resort to the Module Pattern but that required a lot of discipline.
Ultimately Browserify, as a bundler, made it a lot easier to use modules to organize code within a web page’s code base (apart from properly isolating the libraries implementations from the client code base).
To make matters worse browser native module support (
type="module") doesn’t quite align with the established use of ES2015 modules in asset bundlers (for one the browser needs the “
.js” file extension and other file path details; bundlers assume that a simple name (no path or extension) refers to a package managed by
npm). Meanwhile Node.js introduced a new file extension “
Back to bundlers. My primary impression:
The front end technology you (choose to) use will often dictate which bundler you have to use and have to become familiar with. If you choose to disregard the established “norm” of that particular front end development community then you have to be prepared to be the “salmon swimming up stream”, potentially cutting yourself off from valuable community contributions and support.
Phoenix is the back end - it ultimately doesn’t care which bundler you use.
Becoming competent with the bundler (if any) that supports your particular choice of front end tools is your responsibility.
That being said, my personal view at this time:
webpack - This bundler currently seems to dominate - which is probably due to it’s widespread adoption in the React.js and Vue.js communities. Since version 4, webpack is “zero configuration” at the entry level. That is the point when Phoenix adopted it. But ultimately there will be something that you want do differently with webpack and that is where the fun starts. Expect to spend a significant amount of time grappling with the comprehension of webpack’s “architecture”. But - if you are using React.js/Vue.js (or plan to use it some time in the future) - grin and bear it, otherwise you might be cutting yourself off from other “goodies” that the community can provide you with.
rollup - unlike the others this doesn’t have a “zero configuration mode” but in my (limited) experience the learning curve for rollup is smooth enough and certainly a lot gentler than the jarring experience that webpack can be. I even found it fairly easy to get started with the API. Would I use it for a React.js/Vue.js project? No. But otherwise it seems to have a lot going for it. Some of my bias is based on the fact that designed around ES2015 modules - but it can handle CommonJS modules.
See this article Rollup v. Webpack v. Parcel for just a bit more detail.
I’ve had my say - what are your opinions?