Check it out to stay tuned on what we’ll be focusing our time on. We also updated the Change how Meteor executes Async code discussion. As you may know, this is our top priority this year. And we are organizing this work into a few releases.
Speaking of priorities, this is a new section that we’ve added to the roadmap.
Our top three priorities are:
Change how Meteor executes Async code or Fibers migration.
Improve MongoDB stability and new async API support.
Improve TypeScript support.
We appreciate more help!
Please reach out to us if you see something you can work on! If you want to help us test these new features, that would be great too!
What are you secretly working on?
We would love to hear from you and add this to our Roadmap! We had a Community section in the last version with just a few items, but we were guessing those.
The worst part about Meteor BY FAR is Windows. It takes forever to build, and only having Meteor running takes a huge amount of the CPU. I don’t understand how this is not a priority, it’s been like this for ages. It’s unusable compared to Mac and Linux.
That isn’t my impression. Actually before you answered I didn’t know a single person who develops in Meteor and does so in Windows OS. MacOS followed by Linux, but Windows? No.
I’m pretty sure that Meteor is tracking the downloads and pages that refer to Meteor on Windows and thus they are well aware of how few people use it.
When resources are scarce, they need to be used where the majority will have a benefit from it. Simple as that.
Windows support is a real need and I think one of the worst point of Meteor.js nearly all students are using windows. Instead of this, if you have to run in enterprise world, you might have no choice. It’s also very hard to create one-click installation. Windows has a path-length limit
Everything is slow on Windows but meteor is the slowest thing I run on Windows
Would WSL (Windows Subsystem for Linux) be a viable solution to enable Windows users to easily and reliably use Meteor? It seems prudent to me to try to reduce the maintenance load of Meteor as much as possible and instead focus the limited resources on core features. I have not used Windows for years, but heard very good things about WSL. Perhaps the best option here for the Meteor team would be to discontinue writing code that directly targets Windows and instead update the docs with guidance on how Windows developers can quickly get up and running using Meteor via WSL? This would finally give Windows developers confidence that the way they use Meteor on Windows will be operational for years to come without any Windows specific issues.
Firstly thanks a lot for GREAT work on Meteor framework!
I want only remind, that similar problem is also inside the Docker. Waiting 30minutes to building middle size app inside docker container is tooooo long I think. Especially, if same build oudside Docker container is a much much (multiple times) faster.
There is existing multiple old threads in this forum and also discussion in Slack but without result.
Is it possible to also to add solving this strange problem to Roadmap to solve it? I know, that new features are also very important, but everybody must build and everybody must wait long time during the building…
…and now I’m waiting 58minutes to build and still I’m waiting and waiting…
Have you tried WSL? It’s Window’s Linux subsystem.
It’s a bit arcane to setup (especially if you’re trying to do WSL version 2, which requires some lower level virtualization settings to be enabled), but it works reasonably well once you get it running. You can pretty much pretend you’re working on a Linux system.
It’s a bit of upfront overhead to get it working, but it’s been pretty smooth sailing for me once I got over that hump. Even got Docker working; in fact, Docker Desktop for Windows gets it working in WSL for you out of the box.
If you decide to go this route, I recommend putting in the extra legwork for version 2, because the speed differences are really noticeable, especially if you’re doing CLI stuff in VSCode (running tests, linting, git commits, etc.).
Usually high cpu usage is caused by the large number of files Meteor watches. This was improved in 1.11, but Meteor still watches too many files in node_modules. That should be fixed by removing these changes if someone wants to work on it (those changes should no longer be necessary due to some of the improvements in Meteor 1.11).
Meteor also watches more files than necessary for Meteor packages, but that will be a little more difficult to fix.
Regarding Meteor’s performance on Windows, there are two Windows specific things we can do:
On Linux/macOS, Meteor only writes the changed files during a rebuild instead of re-writing everything. On Windows, this optimization is still disabled for client only rebuilds. I finally understand well enough why it was disabled, so the next time I work on performance I plan to fix it.
We can change how some of the file operations are done to make them more efficient when Windows Defender is enabled.
Most other build performance issues are the same as on other operating systems, though they might be worse on Windows.
Gitlab CI/CD with my customized Ubuntu, but I tested also another and without significant differences. For building, Im using dedicated host (only for building, nothing else), new Xeon CPU and 256GB RAM and it takes about 30min. If I will run on host, it takes about 4min (7 times faster).
I tested on another host machines (e.g. with AMD comparable CPU, It takes little slower), and situation was the same, when I build outside and inside Docker container.
Host was always Ubuntu, Docker container also Ubuntu.
Years I was using Win10+WSL. In older Windows 10 releases with WSL2 was working great. With newer releases it was working slower and slower (but still accepted). But after migration to Windows 11, it was working muuuch slower, I tried everything to solve it, but without success. Therefore I had not another chance, I maked dualboot and run Meteor on Ubuntu. But it’s a shame.
Truth is, that reason of problem in my case could be also JetBrains Webstorm, because after few days of using, it consumed more that 20GB RAM! But still I don’t know the right reason, if problem was slower WSL, Docker, Webstorm or Meteor, or something else… Because non meteor projects (but smaller) with VSCode was running faster.
Few months before I switched to Mac and all the problems finished and Meteor works great …only building takes a long time.
I have only tried WSL2 on Windows 10, so I suppose take my recommendation with that in mind .
Yeah, I noticed that the default WSL setup takes up a lot of resources, memory in particular. Out of the box it “earmarks” a certain amount for the subsystem. What I had to do was make a configuration to make it less greedy. I was able to limit CPU and RAM that way.
I also disabled having WSL start on boot. That way if I just want to play a computer game or something, I am not paying the cost. When I open VSCode, WSL will start up. When I’m done, I have to manually shut it down, which is an inconvenience I’ve just gotten used to.
@moberegger …in my case was problem with the performance under WSL (always I mean WSL2) (limitation of WSL resources will lead to the even smaller performance). The problem is also, when IDE is running from Windows and working with files under WSL (it’s slow). I tried also install the fully KDE desktop and run JetBrains inside WSL, but it was not very stable and network desktop client was also not cheap.
From my migration to MacOS (I was not fun of Mac’s), but what is truth, I’m now mor productive, more focused to the work and less for the solving problems…
I strongly recommend you switch to running Meteor within WSL2 (Ubuntu 20.04) under Windows 10/Windows 11. This is my preferred Meteor dev environment.
Meteor builds much faster within WSL2 than under Windows. Also, the Windows version of VS Code has native support for editing files within the WSL2 Ubuntu environment.
…only building takes a long time.
.