3 ms·
Despite its apparent complexity, webpack is much more suited for the common case than it is for use cases with more complex requirements. To make an analogy, we
by mnutt 8y ago
Despite its apparent complexity, webpack is much more suited for the common case than it is for use cases with more complex requirements. To make an analogy, webpack is the HighCharts of the js build system. If you just need a chart it’s fine for that, or if you need to configure the chart and they’ve thought to add that config option it’s fine for that too. But if you have something esoteric and instead need a set of composable pieces, you probably need d3. The closest thing to d3 in this analogy is probably Broccoli.js.
Ideally webpack would be a set of composable pieces and you could use a simpler API for common use cases and drop down to a more granular abstraction when needed, but unfortunately as with HighCharts/d3, going from “batteries included” to “build from scratch” can be pretty jarring.
- kn8 8y agoThat's an interesting perspective. I'd add that one option in those situations could be to utilise Webpack plugins. In one project we were bundling JavaScript with webpack in a service behind an online IDE. We used a couple hand rolled plugins to do custom resolving (find the packages in this memory-fs structured by name/version), caching (what is safe to reuse) and sandboxing (only allow safe requires and plugins).