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.
I hope this comes sooner than later! I use Vue and meteor-desktop and both have really been limping along with a lack of support. I’d love to be able to update to Electron 18+ and Vue 3.
You can keep “SolidJS starter template” on the list of community items. I do plan to get to it eventually…
Regarding priorities: I feel like tree-shaking has been promised as “real soon now” for a couple of years. It would be great to see it finally see the light of day, at least as an option, so that I can finally decrease my bundle sizes without a ton of work. Meteor really sticks out here, as every other build tool I know of supports tree-shaking.
Another priority for me and SolidJS: SolidJS isn’t fully usable (specifically, dev mode is impossible to access, which makes debugging difficult) without support for NodeJS export conditions. See this feature request. I don’t think it should be hard to add support for export conditions when manually parsing package.json and simulating ESM, so it should be much easier than full ESM support.
For those who suffer with performance on Windows, try turning off your Windows Defender/Anti-Virus and try rebuild. It made a huge difference for us. Maybe I am imagining things… Let me know!
Stuck on Electron version 11.5.0 whilst it’s currently at version 20.1.0 officially with very regular new versions coming out. Cannot upgrade any further as it breaks
I just began to use Meteor as a side project, migrating (again) from another stack for always the same application.
The main problem I have is the compatibility with major libraries like vue3 (not supported) or discordjs (requires nodejs v16+). That’s a real concern that the framework didn’t manage to cope with libraries compatibility. I had to migrate to Svelte et Eris, but it’s a unsatisfactory workaround when you try to replace mainstream libraries.
Hello @a4xrbj1, I tried by your recommendation build it on another linux distributions, I tried also amazon linux and It not helped. Building duration is still long without change. Try In you case build outside the docker container and try the building time. I think, you will build it also multiple times faster. According to this problem I opened new discussion thread. Veeery long building time inside Docker container
I think you made a valid point: that looks like a multiple choice question. I for one develop in JS/TS and Python on a virtual Linux machine, and in Java on my main machine (which is Windows). All communication with the virtual machine.
All very valid points, and I feel you. Many moons ago, when I started with Node.js as a Windows user I encountered only frustrations. Meteor working well on Windows - which I agree should be the case - is only part of the solution. In my experience both Windows and MacOS are inferior if you are set to develop something remotely complex, especially if you need exotic tooling, additional services (e.g. databases), and so on.
Docker doesn’t always cut it. Plenty of low performance reports when used in Windows, and some issues still being reported with Mac OS.
I would suggest to create an actual Linux virtual machine using something like VMware, enable all available hardware virtualisation options in your BIOS, then snapshot it, and do whatever you like with it, run as many Docker containers your resources allow you, and so on. You communicate with it over virtual desktop, SSH, TCP/IP, any way you like. Share dev folders with your Win/Mac machine and use your preferred tooling from your environment, although you may want to check if your favourite tools like to communicate with folders mounted over network. But Meteor, Node.js, git, Docker - as a rule of thumb, all the CLI stuff needed for development - should run in your virtual machine.
I never, ever looked back at developing on Windows, with the exception of Java, just because IDE quirks and overall Java traditionally having great support on this platform.
P.S. I call BS in advance on anyone who will say running Docker inside a VM is wrong, performance will be worse. Show me a benchmark where Docker on a Linux VM is worse than Docker on a bare metal Windows machine. P.P.S. As an ex-Windows sysadmin, I promise that Linux is beautiful and easy to learn, reliable, and overall extremely satisfying.
My bad, should have said “CPU”, since that is the one impacting more directly the Meteor builds. In my view, RAM is way more expendable, especially since we have exploit mitigation patches eating away at our processing power almost on a yearly basis.
I would like to only ask, Why the Meteor login token is stored to localStorage? Is there any special reason for this (for example security or something else)? Why the login token ins’t stored somewhere, where can be available in request header? It can be very helpful in server static routes.
Also I would like to ask, if is planned to implement static routes from external dependencies directly to meteor framework. I mean especially Meteor picker.
.
