Another serious problem with Webpack is that it assumes we’re going to be using CommonJS forever. Two of Webpack’s shiniest features, code splitting (require.ensure) and hot module reloading (module.hot) depend on CommonJS-isms (require and module) that will and should cease to exist in a fully ES2015 world of import and export, and Webpack has no plan to adapt those techniques to work with a purely native module system.
The more popular Webpack gets, the more it contributes to the entrenchment of CommonJS. Webpack is very much a tool for today, when what we really need is a tool that embraces the future of the language. I gave a talk recently about why it’s so important that we move on from CommonJS to a truly native module system (import and export), in case you’re not yet sold on that vision of the future.
By the same logic, adopting Webpack as a core concept in Meteor would hold the platform back in the long term—and probably in the short term, too, if you read that post of mine.
When Meteor finds a way to support code splitting and hot module reloading, those features will be designed to work with import and export syntax, without any dependencies on CommonJS. Unfortunately, Webpack has no insight to contribute to that still-open design problem. If you have ideas, we’d love to hear them!