Post 2/2: Differences between webpack:webpack and gadicc:ecmascript-hot
Note, I’m the author of
gadicc:ecmascript-hot (also known as
meteor-react-hotloader); @benoitt, the author of
webpack:webpack might have a different take.
In the previous post, we mentioned a bunch of cool things used in modern web dev that Meteor doesn’t officially support (yet). Both these projects let you use (most of) these features in Meteor, today, in different ways:
webpack:webpack uses the webpack builder along-side Meteor, and instead of some parts of Meteor. The big advantage here is that webpack is awesome, supremely popular, and now you can do everything people using webpack could always do, in Meteor. Webpack is traditionally very difficult to configure, and this has been solved with simple packages that you can use via
meteor add. On the (potential) downside, your project is now a hybrid project, and some Meteor-specific things (especially backwards compatibility for older Meteor code) might break - but I’m not sure of the specifics.
gadicc:ecmascript-hot brings partial HMR, full react hotloading and
.babelrc support (but not code-splitting) into Meteor without using Webpack (hence why I call it “native Meteor”). So you project is still 100% Meteor, and some of these features have aspirations to ultimately become a part of official Meteor. It’s also very easy to add to existing projects.
Which to choose? I think it depends on your project.
Firstly, webpack (in general) is super awesome, and there’s been talk of possibly - and in the long term - having Meteor adopt it officially. If you’re doing a new project and want the best of both worlds,
webpack:webpack is definitely worth checking out and much easier than setting up a plain webpack project. As long as you understand that you’re no longer working in pure Meteor.
I know for me, I’m working on a few projects which wouldn’t accept mixing two build stacks, and wanted Meteor’s slower features but guaranteed stability when upgrading. That’s why I wrote this, to get the benefit of these features without needing to splice webpack into the Meteor build process.
For a more in depth look at some of these differences, you should also read Why is the Meteor.install(1.3) api better than webpack in meteor?.