I second that. Cool if you’re starting from scratch. Not at all practical when you have a huge amount of legacy code.
@veered totally feel your pain on this one.
Speaking to people about it, getting webpack-style incremental build times is probably not possible without a major rewrite of the build tool, principally for the reason that webpack doesn’t write/serve from disk, it instead keeps everything in memory (i.e. there is no .meteor/local/build equivalent).
I have thought a bit about the “fast past for single file change” idea. I asked people who know more about the build tool than I do about it and they didn’t raise any obvious objections to it. It would be a far reaching change though, so not a simple project.
If you are interested in working on this, perhaps we can coordinate on a GitHub issue?
7 Likes
I am definitely interested in working on this (as a collaboration)! And I bet you that a lot of other people are as well; this is a really big deal.
1 Like
I’d be interested as well 
2 Likes
I totally agree. Although i’m not really sure what a Meteor app is these days.
It’s also do-able for current apps but takes some thought to migrate the yourapp/client folder and into webpack. If you have ES6 imports it’s really not that bad. Though to be honest the time spent migrating will likely be more than the time wasted on reloads (took me a good solid weekend to migrate one with a few hundred files).
1 Like
Would you mind writing a short tutorial on how would you migrate from existing project? My app is React + Redux + Apollo so it definitely fits to the category you mention. I’m very much intrigued!
How would you see Galaxy deploys there? Would that still be a Meteor app?
I’m going to give this post a bump up.
Alright I did a few profiles of our application. Things got a little bit better since switching to the 1.4 beta, which these profiles are based on:
In addition to running Meteor with --profile, I also timed the full restart on my phone. So the listed time also includes our application code that needs to run on startup, which I think takes about 3 seconds.
It appears that Meteor is not usually properly separating out client-only or server-only reloads. The client-only reloads work when you are in a package (offering a large performance bump), but there doesn’t appear to be separation in any other case. I have no idea when this regression was introduced, but that’s kind of a big deal and an opportunity for easy wins!
Edit: Sometimes the client-only or server-only reloads work; I’m trying to figure out why
1 Like
This about sums up how I feel about it.
It’s up to 12gb now. Pretty sure it spell checks every line of all 12 every time I save any non-css file.
1 Like
So are we done with this?
No, I’m going to be posting a roadmap on how to speed up reloads soon. I had a good talk with some MDG devs.
1 Like
Here is excerpt from the blog post about 1.4:
We’ve already begun planning for Meteor 1.4.1. We’re hard at work on much-needed performance improvements, such as speeding up package extraction and rebuilding single files.
What’s more, Meteor 1.4.1 will include performance improvements enabled
by the Node 4 update, thanks to Node 4’s native support for many more
JavaScript language features.
3 Likes
You can safely delete that whole folder (1.5 years of releases) and restart. Meteor will recreate only the currently needed stuff.
2 Likes
Hi,
Here’s my idea:
• Decouple client codes from server codes
• Use webpack hot reload modules
• Use a Meteor client side implementation to communicate with the server (like react-native-meteor, or node-ddp, or others)
How to make a build process faster?
Rewrite the build system on Golang for better concurrency 
I’ve been experimenting a bit with some of the Meteor webpack/react skeleton projects. I decided to start hacking something together to support Blaze using the webpack/react skeletons as a starter. Here’s the repo: https://github.com/zmikaya/meteor-webpack-blaze. Basically, I just wrap a compiled Blaze template in a React component. It’s far from a perfect strategy, but I think the idea might have some potential. A decent package could probably be built to effectively abstract away the React aspect of things.
The end consequence seems to be that you can update a Blaze template and have a primitive form of hot module replacement so there is no need for a page refresh. This includes updating template helpers. This means that reload times are essentially non-existent compared to the 20-30+ second wait times we’ve been experiencing.
I can’t promise that this approach scales to very large codebases, but I suspect it’s much easier to optimize the build process vs. dealing with Meteor’s configuration-free, but monolithic build system.
4 Likes
This is very interesting! Does it require your project to be structure entirely with ES6 modules?
No, you shouldn’t need to. The ES6 module system basically boils down to scope. It’s actually pretty easy to control scope and load order using the webpack structure. The code you want to be webpackified is separated from the standard Meteor file structure. This gives you the ability to use whatever build system suits each file best and merge them together seamlessly in addition to fully controlling scope and load order.
1 Like
I’ve finished the document about faster reloads I was planning on writing Roadmap/Howto for Faster Reloads
I think that most people on this thread would be very interested in this: Blaze: Instant Code Reload Demo (+Beta)