I am one of the founders at Qualia, and we are probably one of the bigger Meteor companies at this point. The slow reloads (20-30 seconds) are a major productivity hit for our team, and I’ve been trying to think of ways to speed them up. A big part of the reason why the reloads are so slow is that Meteor completely rebuilds the dev bundle on every code change. This isn’t entirely true, since a lot of things are cached, but a lot of things aren’t cached and there is a ton of slow disk IO because tons of files need to be read, written, and deleted on every reload. I think that it may be possible to have a fast path for certain kinds of code changes that could be enormously faster.
The primary idea is to modify the existing dev bundle (i.e. the stuff in .meteor/local) rather that recompiling everything from scratch. For most single file source changes, the vast majority of stuff Meteor is doing on rebuilds isn’t necessary. It shouldn’t have to do a bunch of ES6 recompilation, read and hash every existing file to check for changes, delete and rewrite the whole dev bundle etc. It should just modify the one relevant file in the dev bundle and reload the server.
The strategy of rebuilding the whole dev bundle on every reload is elegant because there won’t ever been any consistency issues i.e. the dev bundle is a pure function of the source code. But fast reloads are important enough functionality that I think some exceptions should be made.
I’ll be working on this problem soon, and would love to see if anyone else has ideas or is interested in working with me.
I so feel your pain! It’s one of the biggest issues we have with Meteor too.
I also hate it if you have to change something very minor in 2 files, it causes 2 rebuilds and browser refreshes. Sometimes I’m like ‘why doesn’t this change work?’, and then it turns out it’s still rebuilding and reloading the browser.
The build system is simply eating all our time. It makes Meteor a shitty dev experience.
IMO, the fastest way to solve this for MDG is to provide an option to turn of automated reloads / builds, and only rebuild when you refresh the browser. Let the dev be in control when to rebuild, like with other frameworks.
Yeah I agree, build time should be improved. I guess currently MDG is really overloaded with work and time is pressing for them to make important decisions that this is not of highest priority. But I agree with @satya 100% - ability to turn on/turn off auto building shouldn’t take that much work and should be on top of their list (hopefully for 1.4). I think this is actually a low hanging fruit for them to improve current users’ experience.
Also, I’ve been thinking that accessing the network for each rebuild is rather gratuitous. I suspect an offline mode would have faster rebuild times. Not to mention allowing those people who know they’re not changing package dependencies to work on the algorithms, styling, etc while they’re commuting on the subway, camping, etc
Also, pulling custom cordova plugins from git and having to redownload them every time makes developing for cordova, which is already pretty slow, almost impossible due to very large build times.
Not to just chime in for a “me too” reply. But, this is annoying the crap out of me. Like others have said, the rebuild seems to be excessive compared to what one could have expected. I for instance do not see why it has to verify all packages when I change one of my javascript files. That should only be necessary if the .meter/packages or the packages files where changed.
As another input to this. Could it be possible to build a dependency tree for the source code when it is built, so that when a file is changed one would know what needs to be rebuilt and only do these file? Not totally in line with the normal build-chain way of doing things, but perhaps doable…
Our company does use SSD’s, and in fact I have tried mounting everything on a RAM disk, but it’s still qutie slow. I am sure that starting to use an SSD would be a big speed boost for anyone that isn’t already though.
I am especially curious if anyone has ideas similar to this for speeding things up. Or if anyone has any feedback on by proposed change, that could also be productive.
That kind of reload time is quite common for very large projects unfortunately. I really do think it is possible to fix it for 95% of code changes by directly modifying the existing bundle.
I’ve gotten rebuilds in less than a second or a few seconds for large webpack applications with caching enabled. Of course, the initial build takes longer.
I just think Meteor’s cache and build system is inefficient.
Not sure yet, but @Urigo can probably chime in on this. I think it is possible to use Meteor without Meteor by separating the UI component written in Angular but still talk with Meteor in the background as per
I haven’t tried it myself, but this should reduce your build times because the UI component of the build is not done by Meteor’s build system and you have a cleaner separation of concerns.
This was bugging the hell out of me a few months back, but one simple change reduced build times from 30 seconds to ~5 seconds. At this point it’s completely tolerable.
The solution was: splitting up client/ and server/ folders properly. Now, when I edit anything in client folder (front-facing JS or SASS), the reload time is super quick. Edits to the /server folder still take a bit longer (~15 seconds).