We have tried almost all the work flows mentioned here, I want to share our experience:
- cli (require, system, webpack)
Clearly this is the flow with the smallest learning curve. So it’s easy to start with, but haves a few caveats, mainly watching is a very slow process (as by default it rebuilds all your bundles, and because it uses amodo trace for tracing module dependencies that needs to reparse all your modules every time), in big projects it can be unusable. Also as its an abstraction of all three supported bundlers, you cannot leverage easily advanced functionalities of each. And finally is hard to customize while keeping up to date with cli version changes.
This is at the moment the most performant of all three, however you have to be careful, specially use separated webpack runs and DllPlugin to keep your watch fast, and keep in mind it static nature, so you have to help it when doing dynamic loading, and sometimes (as in our case) is not possible to give it enough information at build time to make webpack aware of the loading pattern. We found in large projects that hot reloading is unstable, and crashes frequently, slowing down you while debugging
This is our current approach, we use aurelia builder to help with bundling, and we crafted our bundle configs separating those that do not change from our main bundle, watching is done with gulp, and it’s fast if you take the time to polish it. However as said here, systemjs can be somewhat slow in mobiles, even with deps maps created and switching systemjs to production build on release. However it supports nicely all module formats around the web, with almost no weird configuration, and does dynamic loading as easy as it can be. We have also some special cases where we have multiple instances of systemjs isolating some user created script loading in our app, that would almost impossible with webpack (it could be done with require and contexts).
We tried also not bundling at all, but we found HTTP/2 features needed, like parallel loading and push state, not consistent enough between browsers and server implementations, and some implementations missing some important characteristics. We also did not see a big enough improvement in loading speeds to make the switch in production. We would love to see this maturing and spreading enough to be our main approach, there is no faster way to develop than having no bundling and bloated build process and tools.