1.8.1 Release candidates: Speeeeeeeed!



I’ve been using the latest beta branch for some time now, and I kid you not, there has been some serious improvements to speeeeeed !

I haven’t been too grumpy about Meteor’s reload times lately, or even for the past year or so. We have a fairly large app and there’s only so much you can do when it’s JS, but damn does it feel snappy with the latest improvements!

Meteor’s release-1.8.1 branch started plopping out release candidates two days ago, I highly recommend running meteor update --release 1.8.1-rc.1 and taking her out for a spin. The RCs seem to be running real smooth :slight_smile:


Sounds good, I haven’t updated yet. Do you have some before/after numbers/estimates?

Not yet, other than:

before: change file, switch to Chrome, wait for a while… look at the sky… browser reloads.
after: change file, switch to Chrom… oh, it’s already reloading!

…but, I’ll arrange a number by clocking a reload with the v1.8.1-rc.1 release: ~ 4 seconds.

To put that into perspective, our app is pretty massive and our reload times were approximately 45 seconds around Meteor 1.2 days, and approximately ~15 seconds lately with the 1.6.x releases.


Nice, that sounds good, I’m also looking at ~15 seconds reload times right now on

I can attest - @zodern single handedly FIXED Windows support! Zodern is the hero of Windows users everywhere!


I bought a linux laptop in part because Meteor was SO AWFUL on Windows, half the time I couldn’t even get a fresh install to build an app. If this is true it will be very much appreciated! :slight_smile:

1 Like

Heil to Linux! Though can’t help but ask - why not just a virtual machine in Windows, with shared folder via Samba?

Mostly asking because I found that code editors and IDEs look better in Windoze.

1 Like

There is no need to use a VM anymore! Meteor is fast on Windows now!

But for history, there are a few reasons not to do this. First thing is, the reason Meteor’s slow in Windows has a lot to do with the specific way it uses the filesystem, and running a shared folder into a VM will do nothing at all to alleviate the problem - AND, it won’t work anyway, because symlinks break all over the place on a network mount. What I used to do, is I’d run meteor in the VM, from a folder in the VM. that was fast. but it was limiting in the opposite direction. My Windows code editor was a bit sluggish accessing the files over the network share from inside Linux, and things like visual source control (like sourcetree or git-lens) were horrendously slow.

With these limitations, it was totally worth it to use a VM - but the main point is that now it’s fixed! No need for a VM!

1 Like

Mostly asking because I found that code editors and IDEs look better in Windoze.

Jetbrains Webstorm looks the same on all of my OSs besides the native windowing but that’s the cool think in most Linux distros - you can theme around until you are happy with it.

1 Like

I remember I had a similar issue with Webstorm, but after optimising the IDE itself to not index like crazy all the time, it worked a breeze and works very well to this day. On the other hand, if you use other tools also, like SourceTree, I can see how access over network becomes quickly a problem.

It’s great to know Meteor works well in Windows, though I will still keep using VMs, for snapshots, command line tools, and all sorts of other conveniences.

Good to know. Years ago, when I was still using WebStorm without any custom theme, didn’t like it. I see what you mean.

Now I am using a custom theme, but I also realised with time that it’s more convenient to keep my day to day OS, and my IDEs separate from the environment used for development. I use one other IDE (Eclipse) for the Java part of our platform, and Sublime for the occasional Python, bash, and the rest - unlike WebStorm, backing up the config is a manual job. And there is so much other software and tools needed for data work.

The dev environment (the VM) can be blown out of existence at any time, and put back in several minutes, whereas the host environment is a different issue.

Upgrading from 1.8 to 1.8.1 didn’t really do any measurable difference to our project, on initial build or rebuilds. Though, we already have ~4s rebuilds, so… :sunglasses: As @arggh said, the improvements to rebuilds over time has been fantastic, even with our ever growing project.

An issue we did encounter were some packages that depended on meteorhacks:meteorx broke, and had to be directed to a fork of it. Besides that, it was a smooth upgrade.

Can you give a pointer to the fork you use, I am expericiecing the issue you mentionned when updating.



If I go back to, I don’t see the kinds of minute long builds I used to (I’m not actually sure what’s different), but at least on Windows there is still a noticeable difference in build time. Are you on Windows?

I also use a linux laptop however an even slicker alternative is to ssh onto your own remote vps linux server and perform all your meteor and devops commands up there … for $5 to $15 per month get a vps from say https://console.hetzner.cloud or https://www.ovh.com/world/vps/ why ? bandwidth, storage and cpu are typically orders of magnitude faster on a server than even a beefy laptop … do edits locally on a mapped dir shared over sshfs with your server … welcome to the future

1 Like

Sounds like a nice blog post to write. :wink:

I did this for a while, but since I was using Digital Ocean, the cheapest droplet that could even build a Meteor app was around $40 a month…

wow, pretty incredible pricing. Looks like I’m wasting a ton of money on Digital Ocean, if this service gets even close in reliability!

How do you do that ? Is it just using powersave mode and reducing inspections, or did you find something else ?