I get why it’s nice to not have to worry about the build process when getting started, or for your hackathon project. But when you get serious, the trade off is different.
It looks like Webpack is winning in the broader node / React ecosystem. So I was wondering what are the core reasons (other than legacy reasons) Meteor should handle the build process, and MDG should spend ressources on it, vs letting some other package that is excellent at just that do the job.
I’ve recently played with webpack:webpack. While it opens really really cool perspectives, it still feels like a mixed result coming from a hybrid approach to what build process should be like.
Over the last months, Meteor has done an ok job at following on the latest node / js trends (with imports in 1.3, .babelrc support etc) but it still looks like:
work is getting duplicated with Meteor redoing what is already done on the node ecosystem
Meteor updates are lagging, and there’s no easy way for you to get the latest build options you’d want to within Meteor.
So I was wondering
what are people thoughts on that, what are the happy/painful experience with how things currently are.
if we should except to see a change that would embrace an external proven tool, as we’ve seen with React gaining traction over Blaze within Meteor community
Yes, personally, for me this is the part of Meteor which I dislike the most But of course this is just my opninion and feelings This is why I experiment with something like: react-redux-webpack-meteor or lastly with Horizon.
With current build system you can’t do much, but it is great if you don’t want to do much
But I think that it is something which needs time. And it will be rebuilded at some point.
For now Meteor has more important things to tackle.
manage the client/server separation/load yourself, which you want to do if you do server side rendering
external things like storybook or test framework expect your code to respect the node standards. Global variables scope is hard to work with, file default import order as well
You sometime have files you just don’t want to be run. That’s why you don’t import them. There’s just there. But Meteor will still look at them.
Fast reload on the client. Some community packages help here.
Probably other things I’ve not experienced yet.
So what about using an external, dedicated complex build tool, and have Meteor create build the config file you need to get started? So that things work out of the box and you still have full control over what is happening.
They seem a lot faster than a year ago. Both 1.4 & 1.5 are big changes so naturally they’re going to take a while.
what are the happy/painful experience with how things currently are.
I think Webpack definitely provides a much more pleasant workflow right now, but it’s unfortunate that the complexity difference is so vast.
if we should except to see a change that would embrace an external proven tool, as we’ve seen with React gaining traction over Blaze within Meteor community
Why is the Meteor.install(1.3) api better than webpack in meteor?
So the reason Webpack wasn’t implemented in 1.3 was due to backwards compatibility, complexity & future-uncertainty (es6) requirements - but now that 1.5 (alignment with node) and webpack 2 (native modules) are on the horizon, some integration there may be more likely.
I don’t know the details exactly but Meteor automatic build/rebuild, es6/babel support etc probably comes from MDG’s work, while those features have/are also been build by the guys behind webpack (and other build-related tools I’m not that familiar with) So it sounds like the wheel is getting rebuilt.
I trust you on that, I was not around here one year ago.
I’m not sure I get this point very well. It sounds like Meteor = one fixed build configuration. So it is simple only because it’s one less thing to think since you have no choice. But would it not be possible to use a much more flexible tool that would have its default configuration to Meteor’s current build process - which would answer the points of backward compatibility and simplicity when getting started - while keeping a door open for those who want to do more once they know what they’re doing? @benjamn mentioned learning curve consideration. I 100% agree build process is not the first think you should spend time learning. And I think a default webpack config shipped with Meteor would let you not worry about it for a while. But it’s be very nice to have the option to do so if it’s important to you.
Well one good thing is that meteor is getting more aligned with the js ecosystem and I agree that it is easier than before to use existing stuff from the ecosystem in meteor apps. I think moving meteor core to npm might help with the goal of also then exploring how webpack could fit into the bigger picture.
I agree with a default webpack setup to get you started and possibility to tinker afterwards. Afaik the meteor build system has a few things that MDG considers better than webpack does it and vice versa they know that webpack does a lot of things better than how the meteor build system does it.
I think their goal will be to either move their goodies into webpack if possible or the other way around get stuff from webpack into meteor. Both could work out moving forward to npm. There’d be a possibility in the future at least that meteor’s build system will be used by many non-meteor apps, thus gaining more users and contributors.
But of course this is just my opninion and feelings 
This is why I experiment with something like: