I’ve been a PC for almost two decades now, but my new job just got me a brand new MacBook. I am not really interested in learning OSX and I was hence considering just installing Windows (using BootCamp).
However, if someone here tells me that they have benchmarks showing real significant performance gains for Meteor and/or VSCode and/or WebStorm running on OSX instead of Windows, I might reconsider and bite the bullet. The gains must be significant enough to compensate for the likely performance loss incurred by having two partitions (one for OSX and one for Windows) instead of just one (for Windows).
Why would there be a performance loss from having two partitions?
Anyway, I’d very strongly suggest using a Mac for web development since most modern web tools are developed for Mac and Linux first and later ported to Windows if the maintainers get around to it.
+1 to this, my main machine is a Windows box and Meteor development has gotten a lot easier since I decided to just put my whole Meteor environment in a linux Docker container and expose port 3000 to my host
Anyway, I guess what you’re saying is that using OS X allows one the get the most bleeding edges frameworks packages months earlier and with less bugs that using Windows. But I generally prefer to avoid bleeding edge packages.
In contrast, getting early support from IDE is very important to me (hence my question being about VSCode and WebStorm as much as about the Meteor packages; in fact, but I reckon this is an entire other topic, my current main frustration with Meteor is that MDG seems to consider that productivity exclusively comes from high abstraction frameworks and cloud hosting services and not at all from an IDE since it very carefully avoids dealing with IDE support, while IMHO the highest productivity comes from a tight integration of languages, framework, IDE and hosting services, all 4 playing a key role).
But how about OS X vs. Windows performance differences (my original question)?
I cannot comment on OSX vs Windows, but I can on Linux vs Windows (and as OSX is fundamentally Unix it’s probably a reasonable comparison).
I use a 4 core (hyperthreads) Windows 7 laptop with a VirtualBox VM running Ubuntu with a couple of virtual cores. Even with the VM switched off (so all cores are Windows) the Windows update and build is significantly slower than Linux. A meteor update on Windows can take upwards of an hour, on Linux it takes a few minutes. Adding or removing a package takes about twice as long on Windows. Application rebuild (on file change) is similar, but still somewhat faster on Linux.
Do you mean that on the same machine, using Meteor for Windows directly on Windows is slower than using Meteor for Linux on Linux even with the latter being provided by a VM running on top pf Windows?
I will add that once built, I don’t see any difference in performance of the application.
The final point I’ll make is that on Windows the 32bit MongoDB is installed for development, whereas the 64bit version is installed on Linux (and I assume OSX).
@robfallows This is fascinating, thanks for sharing.
From my perspective, supporting native Windows development has been a major time investment over the last year, and to be honest I’m not terribly proud of the results. Meteor works on Windows, but it is definitely still a worse experience than Meteor on OSX or Linux, in large part because making any Node project Windows-portable (and keeping it that way) is hard.
If there was an easy way to support containerized Linux development on a Windows host environment, and it was faster than Meteor-on-Windows for most developers, I would be tempted to discontinue native Windows support.
What do you think would be Windows developers’ main objections to that? Too hard to set up? Preferring PowerShell to Bash (or any other Linux shell)? Not getting to use your Windows text editor of choice? Docker’s system requirements are too restrictive?
As a windows user please do not discontinue windows support. At the very least do not discontinue the ability to compile and run for a windows machine. I have an app we sell that all of our customers run their own instance locally and are all in a windows environment. They need to the ability to run it on their own machines in an ‘airgap’ type situation. Getting them to setup and maintain a virtual machine the app would be a night mare for a user. Some are restricted to an approved software list that can run on their networks and running a vm would open a whole can of worms. I can elaborate more, but we rely on windows support exclusively and I am sure there are other out there in a similar situation.
[quote=“robfallows, post:5, topic:31193, full:true”]
A meteor update on Windows can take upwards of an hour, on Linux it takes a few minutes.[/quote]
I think this particular thing isn’t suited towards being a proper metric for comparison. Today I updated two separate Linux Meteor installations, one taking a few minutes, the other one (being done a bit later) was cancelled after one hour because it once again hung at “Downloading meteor-tools”.
Docker, which a lot of people consider quite a useful tool, only added Windows support very recently.
npm before version 3 had no way to limit file depth to something that would work with Windows in a reasonable way.
I guess I could come up with more. I’m just saying my honest advice to any web developer that asks me is - don’t use Windows right now. There can be different opinions of course, but I’m just trying to be helpful.
But King Kong does not provide support for Meteor isn’t it (as Meteor Tools for VS died 3 years ago already)? So why mentionning it?
Currently, WebStorm can’t properly follow the (albeit complex) Meteor generated source maps for breakpoints (at least for CoffeeScript) and neither can the VSCode node debugger. In addition, the VSCode node debugger is not integrated with the VSCode chrome debugger extension and the examples of launch.json configuration files are very hard to find. So, overall the IDE support does not seem great, unless I am unaware of some other options.
If there was an easy way to support containerized Linux development on a Windows host environment, and it was faster than Meteor-on-Windows for most developers, I would be tempted to discontinue native Windows support.
I honestly thought this was a common practice to use the VM. I’ve been working like that for the past 7 years. Windows machine + Virtual Machine with Ubuntu.
There is a way, docker + map the volume so an native IDE can read it. Here’s one gotcha of this approach: if by any chance you have folders with “:” it can crash for no reason. Bc windows does not support “:” in folders. Anyways if Meteor would offer an official docker for this I’m sure it can help a lot of Windows users.
It is fairly easy if we provide them with a docker container done right + I can confirm windows builds are slow no matter how powerful your machine is.
I am not using docker, I’m on Windows 8.1 + I have a Virtual Machine (Vmware) with 6GB RAM & Ubuntu 4 cores. And I’m using WebStorm inside the VM. Works like a charm, because I have 16GB on my laptop. RAM is your biggest friend here.
I’m not sure how useful nvm is when you’re using Meteor which uses its own version of Node. And frankly, if needing different versions of Node is a thing, then it’s Node’s responsibility to provide such a tool. I mean, I have no problem on Windows with targeting different levels of .NET - that’s built-in right from the start.
And the npm thing with Windows file system limits is, in my eyes, something that never should have arisen in the first place because that whole “we have 20+ copies of the Encyclopaedia Britannica in npm_modules because 20 other modules depend on it!” should have never have existed in the first place.
Seriously, 5 seconds of thinking about the whole thing should have told anyone that this was a bad idea. (Then again, the recent debacle about some joker unilaterally pulling his npm module and thus breaking everything should have told anyone that npm’s developers sometimes are not the brightest tools in the shed).
Definitely true for Windows builds. For some reason they eat much more than builds on Linux.
That’s a fair point. I generally have a very (un)healthy scepticism for anecdotes as proof. When MDG originally said they were working to support Windows development I was very excited - not so much for myself, but for what I saw as a huge growth opportunity for Meteor. Certainly those early days seemed to go much better than they have since the embracing of npm. My point being I have no axe to grind about Windows vs Linux*. I would really like the development experience to be equally good for both. However, anecdotes tend to gain weight the more they appear and difficulties with the Windows experience abound on the forums - and my (anecdotal) findings are similar.
I would have thought that MDG’s proposed Meteor-as-an-npm-package should address the issue of continued Windows support. Once Meteor is a first class npm citizen it becomes more npm/Microsoft’s issue than MDG’s (and Microsoft do seem to be making efforts now to be more npm-friendly).
However, a container approach is very tempting. Certainly, it makes a lot of sense given that production Meteor deployments are increasingly (mainly?) using Docker. Having an opinionated, consistent architecture from development through CI/CD to production would be huge. That’s an approach we are starting to use here for our Meteor developments.
I would think the set up could be dumbed down (in a good way). MDG took the lead there with installing Meteor. That approach taken with Docker would be good.
Gosh, don’t get me started on PowerShell. I’ve written some quite complex scripts (for fun?) and have to say that going from an ox cart (cmd) to a starship (PowerShell) without the option of something to get you to the next town quickly and easily was a bit crazy. And the bad practices that were perpetuated to make it fit Windows (backslash for forward slash, backtick for backslash - grrr). Oh, you did get me started .
vscode, atom, webstorm, sublime. The only problem IDE may be Visual Studio. Would Docker Volumes address this?
Possibly, but aren’t these mainly around how virtualisation is handled in the host? I’ve run Docker in a VirtualBox VM on windows and it’s now available natively, so it’s probably mature enough.
*On a (slightly) related point, I do have issues with OSX vs Linux. It’s always been a perpetual source of confusion for me that products from the least open company are used to make the most open products. Even Microsoft is getting into open source in a big way these days. However, Apple’s github repo is mainly targeted at swift. No great surprise there.
no but this recent thread has some good information on the topic. basically you can set up a container with an image that has Meteor installed inside it and exposes port 3000 to your host, then share your code into the container with a mounted “volume” (acts like a network drive so a folder on your computer is available inside the container) and have the container run meteor on startup
.