React hot reloading. As we know in Meteor, every time we save, Meteor rebundles your entire app and reloads the page, and this takes a bit of time depending on the size of your project. React hotloading is slightly different, it leverages HMR (see below) and without reloading the page, replaces changed components in-place, preserving state. That means that, your change will be visible in about half a second; if it was a dialog, you wouldn’t need to re-open it, your text inputs remain filled, etc. In short, it’s a massive boon to iterative development where you spend much less time waiting for your app to reload. See the animation at the top of here for an example. Further (technical) reading: babel-plugin-react-transform, react-proxy, react-transform-hmr.
Code splitting. As we know in Meteor, the client loads all client files on the first load. E.g. not admins will still be served all the admin templates, which will never be used, and this creates a slower load time. With code splitting, you can divide your app into different pieces. You could, e.g. load the main code straight away, and load code for particular sections if a user visits them (or load everything else after the initial load is complete and the user can start using your app). Further (technical) reading at http://webpack.github.io/docs/code-splitting.html.
Hot module replacement (HMR). When you change files, the server will send only the changes (and perhaps their dependencies) to the client. Modules (files that import/require each other) that are “hot aware” can then take action to use the new code when it arrives. An example of such code is the react hotloading code, which knows how to replace react components in-place. Further (technical) reading at https://webpack.github.io/docs/hot-module-replacement-with-webpack.html.
The last two need to be provided by your app’s builder/bundler/packager/server, i.e. Meteor or Webpack or Browserify. The next post discusses two different ways to bring some of these features into Meteor, which doesn’t support them officially (yet).
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.
Wow! Thank you!!!@gadicc for this awesome explanation and seemingly very balanced comparison.
The work done by people such as yourself and @benoitt are more valuable than ever now that Meteor itself is opening up the gates to its garden.
It feels like babelrc - for your package - is the connection to that world while for the other one, webpack is itself that connection.
So apart from the mindfulness for backwards (or perhaps even forward) Meteor compatibility, what do you think are “features” that one would provide while the other would perhaps have a harder time providing?
PS: I should have started a new thread all along, so thank you for doing this here rather than there or over there
Firstly, a clarification; webpack:webpack of course uses babel too and let’s you customize the .babelrc. Meteor (official) included babel since 1.2 (for the ES6 support), but didn’t support customization. My package adds this now but it’s not incredibly complicated and it will land in Meteor official quite soon after 1.3 I think.
As such, either option lets you use the mass of cool Babel stuff floating around. But webpack is a lot more than just babel and can do a lot of other fun stuff. HMR is one example, but now no longer exclusive (webpack has a fuller implementation though, for now). There’s also code splitting, which would take a while to get into Meteor. Beyond that, all kinds of build plugins and other things; in some cases similar things could be written for Meteor, of course, for webpack they already exist. For example, I think - but am not sure - that using CSS via ES6 imports is not possible in 1.3 yet (but is using webpack:webpack).
Re PRs. The process has started, but the focus now is on getting a stable 1.3 out. After that we can look into some of the other things. The .babelrc support isn’t too complicated and could well make it into 1.3.1. The HMR stuff is a lot more complicated, and would need to be completed in different stages; parts of the meteor-react-hotload code could become something official, whereas other parts are too hacky and would require some fundamental changes to the meteor bundler. The good news is there’s no need to not have this stuff until then