So the answer is, it’s just too hard? Is the build system systemically flawed in Meteor?
It’s a question of technical debt. Any system we might build on top of Webpack would be much, much more complicated (and take longer to ship!) than something designed with Meteor’s build system and developer experience in mind. And it would be worse, in addition to being harder to maintain, because design decisions that we could otherwise make freely would be constrained by what Webpack can do.
We’re not shying away from anything. We’ve made a careful decision against using a tool (Webpack) that simply isn’t suitable for our purposes. Read my post (again) if you need further explanation, but don’t insult my intelligence or technical ability with your imagined theories about why we’ve made these decisions.
I’m weary of taking on proprietary Meteor tech now that I know MDG will drop it like it’s hot when the fancy changes. I want something more widely accepted by the community, thereby insulating us somewhat from a few guy’s ideas about what’s best for us.
What have we dropped? If you read the linked post in which I clearly explain why we’re not using Webpack, you’ll see that a big part of the reason we can’t “just use Webpack” is that we have a hard commitment to backwards compatibility. I wish we could ignore whole parts of the system we’ve built over the years, like the various Webpack integrations do, but that’s not an option for us.
Webpack happens to be popular right now among developers who think CommonJS is great, but that doesn’t mean it’s the right tool for the long term. Webpack is also a “few [people]'s ideas about what’s best for us.” That’s all software is, ultimately. I hope the feature set Meteor 1.3 provides will win you over.
I’m spending all my working energy (note: not quite all my energy, especially this time of year) steering Meteor back towards standards and best practices. A big part of that is embracing the npm package ecosystem, and migrating Meteor packages from their current format to the npm format, even though that means giving up some features that npm does not support. As Meteor projects become more and more like plain Node projects, tools like Webpack may become more useful, and I hope Meteor can get out of your way if you choose to use such a tool.
I also hope and expect that tools like Rollup will mature to the point of making Webpack and CommonJS obsolete, because that’s a future that takes full advantage of JavaScript standards, and a future I’m really excited about.