Why is the Meteor.install(1.3) api better than webpack in meteor?

This is a bit off-topic for this thread, but Meteor 1.3 will indeed support Cordova iOS 4.0.

8 Likes

Hey everyone,

I think it is a fair question to ask ourself do we really need Webpack or should we go with pure Meteor? Why should we use such a complex tool while we have something great that is simple to use.

To be honest, when I wrote the Webpack plugin for Meteor it was out of my own need to use it on a major project. It wouldnā€™t be as near as useful if it was a small project and as someone developing 100% React with Meteor, it was REALLY helpful for fast hot reloading, building assets (most people here donā€™t know this but it rocks) and code splitting.

The good news here is most people only care about fast hot reloading. And as a matter of fact I know it can be as fast with Meteor 1.3 because the hot-reloading of React is not built on top of Webpack but on top of Babel (hey! meteor use this weā€™re lucky :smile:). It has already been done for Browserify, why not Meteor build?

If we add HMR to Meteor, we will be able to do exactly the same fast hot reloading than Webpack. Then, you wouldnā€™t need to use the complex Webpack config files unless you have a major project that needs a complex configuration.

I think this is the future of Meteor and Iā€™m hoping the community will be happy to go there. I wish I had more time to contribute to this.

20 Likes

Hey @benjamn, I think Iā€™ll use this structure for my react app once 1.3 is out. The question is, if Meteor.install will also allow to have imports like this:

Shared module resolution

The way modules in CommonJS are resolved is pretty straightforward in
practice: its all relative from the current file.

There is one piece of ā€œmagicā€ in the way modules resolve. When you do a
non-relative require like require('moment') the resolver will first
try to find it in node_modules/moment. If its not there, it will look
in ../node_modules/moment, and on up the tree until it finds it.

Weā€™ve made it so that shared resolves the same way with webpack
modulesDirectories. This way you donā€™t have to
require('../../../../../../../../../../shared/Avatar') you can simply
do require('shared/Avatar') no matter where you are.

This! Reload times are getting really out of hand on our project, up to one minute on decent machines (i5, ssd, 8gb ram)

Does this mean you wont be supporting the webpack plugin anymore.

NO! Absolutely not. I will continue to use Webpack and would suggest anyone with a large project to do so.

But Webpack is not so easy to use and I think non-webpack users deserve hot-reload without page refresh :wink:

Thanks thats a relief ,!:blush:
I think the time it takes to learn webpack is truly rewarding

Webpack canā€™t help Meteor with server-side code, or can it?

All this build delay have an unmeasurable impact on development process iterationā€¦

Looking at compilation profile output, seems it check packages versions, plugins, reminify all css (even if it is not modified) and a lot of other stuff that is not related to the modification :confused:

1 Like

It can! Iā€™ve been using it in the jedwards meteor-webpack version and itā€™s been working well. It does however, add more config code (almost 2x lol):
https://github.com/jedwards1211/meteor-webpack-react/blob/master/app/main_server.js

All this build delay have an unmeasurable impact on development process iterationā€¦

I agree! I was about to leave Meteor until webpack saved me. I was creeping into 18-20 sec reloads on an i7 quad core. Now itā€™s like 1.4-.1.7 tops.

4 Likes

I would +1 on the effort to improve reload times and build times in general, because i have seen meteor kind of slow up on a system with an SSD and a good enough hardware as soon as the project becomes slightly big, and i am not talking about big in the BIG sense really. So this is definitely something you guys should work onto, if meteor starts killing productivity which it is currently, than the value it adds isnā€™t so much to keep using it and this is something that needs to be addressed fast.

A bit off topic, but 2 questions:

  1. I really like the cross-package imports Meteor has for css preprocessors like less and sass. Is there something similar for webpack?

  2. Is there some kind of migration guide on how to transform existing meteor apps to webpack? I canā€™t live with Meteor rebuild times anymoreā€¦

@benoitt et al., Webpack sounds interesting. I have a situation in which I would like to push down to the client only the (template/view/code) it needs, as it needs it.

For example, say theyā€™re going through a wizard. I know there are 10 screens associated with this wizard. As the client starts the wizard, I push to the client the first 2 or so screens, and as they progress I send them more.

Iā€™d like to make the connections between (templates/code) with tags if possible.

Having the capability for the client to request On Demand Resources is great. But Iā€™d also like to use this to restrict what the client as access to. For example if a client has not purchased a feature, and itā€™s not enabled and they donā€™t see or have access to the screens, why should they actually get the screen pushed down to the client? The client should only get what it needs. Right now, itā€™s complicated to restrict screens, and through packaging I donā€™t think it can be dynamic. For example, what if the client actually pays for this added feature, dynamically sending the client the feature screens because theyā€™ve paid would be amazing.

Maybe something analogous to Appleā€™s App Thinning (On-Demand Resources)?

Is this something Webpack will allow me to do?

2 Likes

This is exactly the reason we need this, perfectly summarized by the author of the Webpack integration module! If we can get the Meteor build system to have hot-reloading and be comparably-fast as Webpack, then I think weā€™ll be onto a winner.

2 Likes

Yes, you can do modular code loading with Webpack.

Within Meteor? How? Is there a How-to guid on this?

If this turns out to be the case, then yes, please MDG standardize around Webpack!

Webpack Inside Meteor

Video: Using Webpack with Meteor

Meteor + Webpack from the Ground Up

Meteor + Webpack + React Router: A Basic Template with Code Splitting

4 Likes

Yes you can do code splitting with Webpack. Essentially, the client only load the javascript of the section when he access it.

You can check the kickstart-hugeapp example where there is an admin page that will not be loaded to the client unless you access /admin.

2 Likes

I took the time to look on how we can implement Hot Module Replacement within the Meteor build and my head is hurting :confused:. I donā€™t think Meteor will ever see fast hot-reload without using webpack.

What if we made webpack so easy to use with Meteor it would be stupid not to use it? What if all you needed was to add a few packages and not even a simple configuration file to write? As an example, if you want to use JSX, you just add the webpack:jsx-loader package. You want TypeScript? You add webpack:ts-loader. The configuration will write itself.

It might give enough flexibility to 95% of the projects and those that really need to configure the webpack.conf.js file, they still can do it.

24 Likes

You bought me, when can I start using it? :smile:

2 Likes

There should be a found from MDG for such people like @benoitt :wink:

9 Likes