Sharing some research into Webpack and the build tool ecosystem

1

To make sure Meteor’s tools keep up with the times, I’ve been learning about Webpack and the state of the non-Meteor JS build tool ecosystem. It may make sense for a future version of Meteor to use Webpack, and it’s interesting to see what kind of experience is achievable using Webpack and NPM.

Here are my notes: https://meteor.quip.com/52aGAgRToj31

If you have thoughts about the merits of different JS build tools or what Meteor should do, feel free to leave them in this thread.

Edit: See also this very active thread about integrating Webpack into the Meteor build tool: Webpack compiler inside Meteor (ES6 modules, hot reload and code splitting!) I haven’t studied this approach yet.

18 Likes
2

It will be interesting to hear from the people who have been using Meteor together with Webpack already, and see what they think about this research.

3

Nice notes and thoughts. I’m looking forward to the release of Meteor that implements the proposed Meteor Tool Design Principles. I think the order of them also makes sense priority wise.

4

I think the research is pretty spot on!
In my opinion, Meteor is the best in the market for real-time data (DDP, latency compensation, etc) & I’d love to see more growth there. Instead of spending limited resources to create a custom webpack build for Meteor, I’d prefer a Meteor that was designed to fit into webpack. This could force it to alleviate some of the pains of being stuck at node 0.10 & having to wait for custom meteor-specific packages like webpack & react.

For example, a SAAS app with a landing page app and client portal app only needs realtime after the login. It’d be great to load Meteor just for the latter entry point. Today, my options are to create a completely separate project for the landing page (there goes common chunks), send the whole meteor payload to every casual visitor (there goes the load time), or ditch realtime & hope someone (MDG?:wink:) creates a websocket transport for GraphQL or Falcor.

If Meteor goes the webpack route, it’ll lose it’s charm for beginners, but it’ll increase market adoption since the switching cost would be minimal; not to mention solidify MDG’s role as the experts in realtime data, which should play nicely into the consulting & galaxy business model.

5 Likes
5

This is very interesting. There is already a Webpack compiler you can use and have all the great benefits that are described within the paper (including code splitting :smile: ).

1 Like
6

Really great. This was very helpful!

7

I’m surprised this doesn’t get more attention :smile:

This is exactly what I think! I guess this would lead to a wider adoption as people could just pull Meteor into their stack, even if they already got an app.
People have been complaining about being “locked-in” all the time, and this seems to be a nice solution.

@dgreensp Have you looked into @benoitt’s solution?

1 Like
8

I’d like to echo this question: “@dgreensp Have you looked into @benoitt’s solution?”

1 Like