1: https://code.visualstudio.com/docs/remote/faq#_why-arent-the...
2: https://github.com/microsoft/vscode/wiki/Differences-between...
3: https://github.com/VSCodium/vscodium/issues/240 (aka, on-the-wire DRM to make sure the remote components only talk to a licensed VS Code build from Microsoft)
MS edited the licensing terms many moons ago, to prepare for VSO (Visual Studio Online = VS Code in browser using these remote extensions/apis that no one else can use)- https://github.com/microsoft/vscode/issues/48279
Finally, this is the thread where you will see regular users being negatively impacted by the DRM (a closed source, non-statically linked proprietary binary downloaded at runtime) that implements this proprietary-ness: https://github.com/microsoft/vscode-remote-release/issues/10... (of course, also with enough details to potentially patch around this issue if you were so inclined). Further, MS acknowledged that statically linking would help in May, and yet it appears to still be an issue.
I just hope they don't come after Eclipse Theia...
It's not EEE. The open core makes it so that the last step in EEE doesn't work. With an open core, anyone can fork.
It’s the only solution I’ve found that really allows you to browse the remote filesystem as smoothly as you would with your local drive (including when you’re also changing the remote files outside the IDE), degrade functionality as needed when the connection isn’t great (using caching appropriately), and immediately recover when it comes back. The only cost to pay was a bit of setup server-side (installing watchman and opening a port, if I remember correctly). I really hope they can bring the VSCode experience to the same level!
For reference, here's the documentation page for VS Code Remote Development:
https://code.visualstudio.com/docs/remote/remote-overview
The Remote Development Extension Pack (linked in the article):
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
But man, eventually I caved. VSCode is a marvel. It performs better than most native IDEs I've used, despite being Electron-based. It's the good parts of Visual Studio without any of the legacy baggage. Its package ecosystem is just as vibrant as Atom's, with solid support for nearly every language under the sun, but at the same time its built-in features and attention to detail in the user experience are Apple-level (really, Apple-of-ten-years-ago-level). I still can't believe I get to use it for free.
The revolution with VSCode is the openness, not the quality.
Oddly, when using SQL Azure instead of on-prem SQL Server, SSMS doesn’t let you use its friendly hand-holding dialogs but instead drops you into a new editor document with cryptic syntax.
The only excuse I can think of is that the user-friendly popups are single-threaded and block window-messages on network IO and would have a very poor UX due to due the chatty TDS protocol.
Monaco was a thing way before Atom was. It was publicly released after Atom but it was already in some of Microsoft's websites.
Still, a web-based code editor on its own has independent utility from an IDE. I'm not sure they would've taken the plunge into a full-on Electron IDE without Atom first showing that there was demand for one.
[1] in fact I've just checked and at least one of those bugs - #10720 - is still open, almost 4 years after it was created.
Kind of like how Android apps can just do whatever they want, and how that's become a major performance challenge for Google to mitigate. Whereas iOS says "here's how you send push notifications, here's how you do X Y and Z in the background, here's how you do web views, work within these APIs". Those constraints allow the platform to schedule and prioritize things, reuse work, and enforce quality. I don't actually know firsthand that VSCode enforces this kind of model, but I don't see how else they could get the performance they do with arbitrary extensions written in JavaScript.
The only drawback is that they had to learn and use vim to do their code editing. I tried to make their lives easier by setting every user with a default vim config, but the insert vs normal mode is a big hurdle for most students.
I'm glad visual studio code supports remote development, I'm hoping that means now my students can use it to ssh access my server and code there. Excited to try this out with new students.
Disclaimer: I'm working on Gitpod.
I've had a really good experience with VSCode remote development tools (https://code.visualstudio.com/docs/remote/remote-overview). Both filesystem access and sharing local web servers works out of the box.
Happy to chat and see if we can figure sth out.
Not really sure what you are implying with the 'Big Brother' comment. The remote development servers are only used for writing/debugging code and not for other daily tasks. Even if they are tracking what tools/functions I am using on the server, what does that matter?
Personally, I have found remote development awesome because it enables engineers to start contributing to a huge product in the very first hour. No need to wait for the repository to clone, the dependencies to install, and the code to build before you can become productive.
I am nobody but I've had this nagging feeling ever since I started working on websites for big corporations about why can't I work on my code on my local machine with no network connectivity? Why do I need to talk to three different databases and two different services on five different servers? Why can't I just fake all those things during my development?
If anything, my not so humble opinion is that remote development further enables bad habits. Of course, remote development is a tool and is not to blame but I recently learned the term "hermetic" build [Google SRE]
>The build process is self-contained and must not rely on services that are external to the build environment.
Personally, I think we should work towards making it possible to run (or at least stub) the whole stack on a single physical machine - be it local or remote. What do you think? I think this is a trivial problem engineering-wise but I am not very good at selling ideas.
[Google SRE] https://landing.google.com/sre/sre-book/chapters/release-eng...
Hence the "big brother" reference.
Frankly, I was/am a little leary of how Facebook might be "improving" the MSVSC Remote Development pack since I use it every day.
It absolutely matters. I do not want to give facebook any data, especially about my development work.
The "what does that matter" attitude is the entire reason people do not trust Facebook.
As a user, shouldn't you be happy if the usage / access to everything by Facebook developers is carefully monitored? That should significantly reduce the risk that some insider improperly accesses any of your data.
Only in the sense that I would be happy that the serial killer that captured me uses sterilised blades. That would considerably reduce the risk of infection.
Yes, running docker-compose for the first time takes a bit longer. But seeing it unfold and having all the parts present on my local system helps me understand this new system better. And really, how often does this happen?
Could you elaborate on this? I’m not familiar with these cloud IDEs.
But.
There is a possibility that in a corporate environment this tool could be more of a hurdle. Imagine that you don't have control over your VM. No root, no sudo, everything is monitored and scrutinized.
Sounds scary.
I'd rather have a bare metal machine with something like Proxmox just for my team's needs.
What happens if this becomes the norm and IDEs are only in the cloud? Do these corporations decide who gets to code on their platforms and gain the ability to peep into the technical secrets of every competitor?
I will never support this.
Also there's some other features for remote development. You can for example develop inside Docker while running the UI on your desktop [1]. Or you can connect via ssh [2]. A bit like IDE split between client and server components. All the intelligence runs remotely, just UI runs locally.
[1] https://code.visualstudio.com/docs/remote/containers [2] https://code.visualstudio.com/docs/remote/ssh
You just had to drink the kool aid and give up any thought of of using any of your own preferences, but it worked.
Guess I’m uninstalling it now.
With a complex development environment (say compiler, separate autocompletion/jump to definition program, version control, maybe a test runner or other external programs) made out of emacs modes, it only needs one thing to not be made with tramp in mind or with bugs for the whole thing to fall apart in practice.
What I have is ssh access to a powerful development box and a relatively non-powerful desktop (possibly using multiple of these in one day). Everything runs on the dev box and I use emacs over ssh with x forwarding. This works fine (the network latency is low and I’m not super sensitive to it anyway) with some hacks to ssh back to the desktop to play sounds or open links, and a lot better than tramp or sshfs). But I am a bit worried about the future: emacs is becoming more graphically complex in various ways leading to more data needing to be transferred as the X protocol is less suited to it; and X (and in particular X forwarding) is dying for various reasons. Screen sizes are also getting bigger. A trivial update at 1080p takes a few hundred kB, a trivial update at 4K takes close to 1Mb, viewing an image takes a lot more.
The emacs future I’m hoping for isn’t so much a better tramp than a fatter emacsclient. That is, instead of using ssh to run emacsclient on a remote box, which causes the server to connect back through ssh to my X server to open a frame, I would run emacsclient locally which would talk (over ssh I guess) to the remote emacs and speak a more efficient protocol to it, and use modern apis to push the pixels onto the screen.
Also, ITerm lets you open http links.
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
So it's not really practical to do "local" development even if that were allowed.
But even if you aren't at a FANG, your company workstation often has the "right" set up and it's much more powerful than a laptop, so if you're dealing with compiled languages it might just be easier to deal with it remotely, as long as the experience is seamless.
Semi-OT but: How are spinup times for different VM/host options? Would it be feasible to have a beefy dedicated machine with something on it that spins up a VM/container when I SSH to it, with all my stuff on it?
Would it be feasible to build something like that with any of the major cloud hosting providers? One always-on server accepting the SSH connection and forwarding it to a fresh VM or something?
It seems wasteful to resources allocated 24/7 when they will probably only be used 8/5.
The beauty of a VM is that it can get migrated around, so those hypervisor hosts can get turned off when load is not there. This is something that is likely happening already.
https://github.com/cdr/code-server
What was better in Nuclide that is not in this one?
Incorrect - they built their own remote-editing solution (similar to vscode's built-in edit-over-ssh, but with a load more features), and have been working with Microsoft to get those features upstream.
Just hope that with the jabs from React Native for Windows team does to Electron based apps, that eventually VSCode gets rewritten in React Native instead.
It's in such a good place right now. With the exception of multi-monitor support (the only real issue with Electron, in my opinion, but a big one), everything about it is wonderful to the point where I feel that it can almost only get worse from here.
So far the team has been incredible, continuously improving without making it feel bloated and slow so hopefully my fears will continue to be put to shame for years. But yeah.
IDE choice is a highly personal thing. This sounds awful.
> There is no mandated development environment. Some developers use vim. Some use Emacs. And even more engineers use our internal, unified development environment called Nuclide.
There are many at FB where we would have to pry vim or emacs out of their hands, and, even then, we would not be successful. :-)
What OS(es) were you using at the time?
In my experience, IDE choice was a team decision in Windows (and perhaps Mac?) shops, where the build system was tightly coupled to the IDE.
But in shops that develop Linux code, the IDE and build system tend to be loosely coupled, and the IDE was a matter of personal preference.
