@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
That gorilla is more like a pet monkey, and he’s very friendly… especially if you install Bash on your Windows 10 environment and have native Ubuntu Linux on the command line
I personally run all 3 platforms, all the time. Can’t we all just get along? Just sayin…
That’s not the “true” VisualStudio, that’s a rebranded XamarinStudio (which was available on Mac for the longest time). You won’t be able to do any kind of Node development in VS for Mac.
And your second link points to Visual Studio Code which is not Visual Studio.
.
)