For those of us who are not very familiar with webpack, hot reloading, code splitting, “native” meteor support for all these etc, could someone please:
Explain what webpack:webpack does and why we should use it
Explain what gadicc:ecmascript-hot does and why we should use it
How does one compare to the other and what are possible reasons for a dev to choose one over the other and if those reasons would change per project
Very important questions I’ll write my full reply now, just wanted to create the new thread first, so we don’t get replies going to two different threads.
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.
Babel. As you may already know, Babel is a transpiler that can “convert” “new Javascript” into “old Javascript” that can work on older browsers, so you can “use it today”. But it actually does a lot more than that. Babel plugins are responsible for converting JSX (inline HTML in JavaScript, made popular by React) into plain old Javascript in the browser. React hotloading relies on a babel plugin to transform your react components. And there are many other custom plugins. “.babelrc support” means you can customize what plugins are being used and their configuration. List of babel plugins, jsx-control-statements in particular is fun!
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.
Having been introduced to non-jquery javascript within the walled gardens of Meteor, the broader javascript neighborhood feels overwhelming at times, especially when you think of developers like me as infants who have been learning, experimenting and growing within that garden. The neighborhood sure is very interesting, but is also kind of intimidating.
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.
So is it possible that you do a more technical, or perhaps feature-wise comparison especially in terms of the alignment with the broader javascript community?
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
It’s a pleasure, glad you found it helpful. And don’t think for a second that I was immune from the JavaScript fatigue over the last year… I suffered just like everyone else. But things are a lot clearer now and I think we’re headed in the right direction!
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).
So ecmascript-hot brings some of the features the “broader javascript community” is used into “native” Meteor, whereas webpack kind of “is” the “broader javascript community”. In terms of what it can support. You can then still get into the debate between Webpack vs jspm vs browserify vs… Meteor
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
I’ll write my full reply now, just wanted to create the new thread first, so we don’t get replies going to two different threads.