I’m starting out with meteor but , it seems the community is divided over webpack and new modules in meteor 1.3.
why cant we adopt webpack as a standard just like react?
@jedwards and many others have been contributing to this
8 Likes
I think @benjamn would be best to respond, since this is the thing he’s working on right now. I’m guessing you might have read the discussion on the PR already?
3 Likes
Definitely have a glance at the “Comparison to existing tools” section of that pull request, since much of that reasoning still applies.
The short answer is that the Meteor platform team has a commitment to backwards compatibility that projects like https://github.com/thereactivestack/meteor-webpack simply do not have. For example, it’s acceptable for such a project to say you can’t use Webpack-powered modules to implement Meteor packages, or that Webpack won’t run any existing compiler plugins for you, or that meteor shell won’t be able to import modules from your app (because Webpack knows nothing about meteor shell). These compromises are reasonable because using a Webpack integration plugin is totally optional. You don’t have to use it if you can’t get it to work with your existing apps and/or packages. If it works for you, and you’re excited to learn about Webpack, that’s great. If those requirements were barriers to using Meteor at all, or prevented Meteor developers from easily upgrading to version 1.3, it wouldn’t matter how awesome Webpack is (and it is awesome)—responding to bug reports about the Webpack integration would consume all of our time as core developers.
Even if we didn’t care about backwards compatibility, Webpack is a sophisticated tool that rewards thoughtful setup, and derives much of its value from being highly configurable. Introducing Webpack into a Meteor project (or any Node project, for that matter) means you have to start thinking about Webpack regularly: how to configure it, when to invoke it, which loader(s) to use when importing special file types, how exactly to respond when modules get hot-reloaded, etc. As with any sophisticated tool, the benefits of deeply understanding Webpack eventually outweigh the time spent learning how to use it, but it never fully fades from view.
Though this comparison may not be totally fair, we were able to use Babel as the implementation of the ecmascript package without asking Meteor developers to learn anything new besides ES2015 syntax, and they could even adopt the new syntax at their own pace. From the bottom of my heart, I wish the prospect of supporting Webpack felt more like that, but I just don’t see any way to reap the benefits of Webpack without burdening Meteor developers with its complexity. We care deeply about the slope of the Meteor learning curve, and Webpack presents a big initial hurdle, especially for developers who are not already sold on its benefits.
With all of that said, we very much appreciate input from developers who have chosen to use https://github.com/thereactivestack/meteor-webpack (or any other module system, e.g. https://atmospherejs.com/rocket/module or https://atmospherejs.com/universe/modules) with Meteor. The work you do to implement and validate your proofs of concept helps our planning and prioritization immensely, even if pesky considerations like backwards compatibility require a different implementation of those concepts.
We would love to support the most useful features of Webpack, such as code splitting and hot module reloading, though we may have to think carefully about the precise APIs, since require.ensure and module.hot both assume a CommonJS module system. (What does code splitting or hot module reloading look like in terms of ES2015 import and export? That’s a really interesting question, and unfortunately Webpack doesn’t have a long-term answer.)
To answer the original question, the API formerly known as Meteor.install (now just meteorInstall) is much worse than Webpack in terms of the features it provides. The initial goals of the Meteor module system are more modest: to allow Meteor developers to control file load order using ES2015 import and export syntax and/or CommonJS require and exports, to support a more modular application structure, to make it possible to load packages from node_modules directories on both the client and the server, and to work seamlessly with the existing Meteor build system. Supporting the features we know every Meteor developer needs right now, without claiming to support all that Webpack has to offer, should drastically improve the Meteor developer experience in the short term (~1.3) while leaving us the freedom to pull the best parts of any module system (Browserify, SystemJS, jspm, et al.) incrementally, as those features achieve consensus.
We’re going to be putting out an early beta version of Meteor 1.3 this week, and I encourage anyone who has read this far to give it a try!
56 Likes
Is there an easy way to run the source? Or does the build tool need massaging to get everything to work? At any rate I can’t wait to try it out!
You can easily run Meteor at any commit by doing:
git clone https://github.com/meteor/meteor.git
cd meteor
git checkout <commit>
./meteor
Internally, we all have an alias to the meteor command inside the Meteor checkout directory. So I use meteor to run installed Meteor, and curmeteor to run from-checkout Meteor.
5 Likes
The fun about all this, Meteor is about "easy to keep everything in mind"
With React+Meteor+Webpack my file structure makes me cry. “What the hell did i do yesterday?!” hello, git diff
11 Likes
I’ll be completely honest, at the moment atleast, I care much less about import/export/require than I do about the INSANE difference in reload(/refresh) speed between “Meteor native” and “Webpack” solutions.
I know that Webpack is so fast because of HMR and etc, so that sentence above is a bit dodgy but that’s how it is.
For me, you could do all the fancy things in the world with Meteor packaging and supporting NPM modules but if none of that comes with a NOTICEABLE increase in “check changes in app after a file save”, then it’s been for nothing.
Hell, I’d be okay to a point to name all my files starting with an alphabet letter(for file load order) if that somehow automagically speeds up seeing changes in app after modifying code.
Just my 2 cents on this 
36 Likes
@benjanm I believe rapid iteration is one of core principles of meteor.if webpack can do all of these (codespliting , live reload, import, export ) , why not go with it ?
why reinvent the wheel ?
As for backward compatibility , every codebase will eventually be rewritten or improved upon . And it should be easy for everyone to get started with code, but along the way , it may get complex and introduce steeper learning curves , one cant expect it to be easy fo ever.
I think the MDG should put all its effort on webpack integration .
6 Likes
Thank you for the detailed response @benjamn, we need more communication like this from MDG.
P.S Future Galaxy announcements should land on your desk before going public 
5 Likes
One more thing to consider is that webpack removes unused code. This means you can safely write if (Meteor.isServer) {} or just if (!Meteor.isServer) { return; } and webpack will remove the "dead code on the client, once configured properly. This is a really nice feature!
3 Likes
Cool, thanks! I tried it out and the load order situation is much better 
.
I was having issues importing functions (has no method 'interopRequireDefault') but I prob. have a broken commit. Oh well i’ll just have to wait 
1 Like
Hey @fvg, I want to do exactly this in a current project. Could you elaborate on how to configure webpack for this? Or point to relevant resources? Thanks!
@kzvaigzne strongly agree with you. We just need HMR like feature and we will have a happy Xmas ( My teammate just push “change in one second” in his Xmas wish list lol )
2 Likes
I couldn’t agree more.
I was watching a presentation of DoneJS and all I could think of was “Meteor should have this by now”: hot reload, SSR, and progressive loading. It would also be nice to have a good story for routing and testing too, not just “the community will provide”.
4 Likes
+1 for fast recompile/reload. It is so important… and takes away so much productivity. There are many issues in github about it going on for months, for some people it even got worst with 1.2, with more than 40 SECONDS to rebuild with a not so fast PC without SSD.
It should be a high priority fix and released as a minor version as soon as possible.
I can handle other limitations of Meteor and work with its strenghts, but that one…
3 Likes
+1 for faster reload times. It is a MUST HAVE now.
9 Likes
I would also like to know if MDG plan to address React components hot reload in Meteor 1.3.
If not (which could be reasonably argued as well) I’ll probably use webpack:webpack in Wekan — at least temporary while migrating from Blaze to React assuming that the time spent configuring Webpack would be recovered in the shorter iteration process during the UI rewrite.
7 Likes
Thanks @fvg! Unfortunately I can’t switch to it right away. I’m using a fairly customized version of https://github.com/jedwards1211/meteor-webpack-react
But that’s a useful pointer, gonna try something in those lines.
Will 1.3 support the new Cordova release? http://cordova.apache.org/announcements/2015/12/08/cordova-ios-4.0.0.html
+1 for hot reload also. it’s a need.
2 Likes