Hacker News new | ask | show | jobs
by xendipity 2228 days ago
Ah, this really makes sense with all of the recent work they've done on VSCode's remote development capabilities.

- An early announcement on their focus: https://code.visualstudio.com/blogs/2019/05/02/remote-develo...

- Most (all?) of their recent VSCode updates include improvements to remote development. i.e.: https://code.visualstudio.com/updates/v1_44#_remote-developm...

- Facebook partnering and becoming an early, heavy adopter: https://developers.facebook.com/blog/post/2019/11/19/faceboo...

4 comments

Their remote development capability is amazing and was quite a game changer for me. Having a nice ide where all of the plugins work on a remote server as if everything is local is so nice!
The SSH plugin is insanely good. I can dev from a Windows machine and SSH into my Mac and do React Native (native) iOS modules. Even my zsh shell acts as if it's local. Running `pod install` from Windows. It's seemless.
+1 to this. $DAYJOB has some proprietary ssh handling, but I can dev from my work-issued macbook into a Linux desktop in the office and vscode "just works"
Agreed. It's completely changed my productivity for the better. I don't even remember the code is remote.
+1 on this -- I had lots of remote issues when traveling to Windows desktop locations. It was surprising how few good solutions (hint: 0) I found. Until VSCode, which has been awesome.
but how do you test the iOS app on Windows?
I agree. I was floored by how well it worked, and actually had doubts that it was working in the way I expected it to/it's supposed to. It was just so seamless and natural. I kept thinking there was no way it was using the correct configuration, running the right scripts, etc.

It was a lifesaver too. I was using a severely under-powered ThinkPad and I'm admittedly awful with Windows. Being able to quickly swap to that remote setup reduced a tremendous amount of friction for me.

When good software works, it's so cool.

So nice when it works and has been breaking incredibly badly for me recently. The Python extensions that vscode was trying to bring up whenever I connected to my remote had some weird interaction with a virtualenv and just pinned the server to 100% CPU and rendered it completely unresponsive. Repeatedly. Reboot to recover.

Generally extremely good, but for obvious reasons this makes me think twice about connecting to some things.

Emacs has had Tramp for ages, which does this. Yes, it's amazing. :)
That's not the same at all. The emacs one is equivalent to all the other text editors that were able to open and save to SSH. Vscode allows remote plugin installation, so things like intellisense work on a code base of millions of lines remotely.
I've absolutely had gtags+semantic on remote C++ projects working just fine with Emacs and Tramp. Python+Flask, too, come to think of it. Oh, and Ruby, including full projectile integration along with automated test execution integration.

The key is Projectile+Tramp; I suppose you coulde use EDE, but I prefer Projectile.

Emacs is the beast.
remote dev (and I guess now codespaces) is one of those "clear differentiators" that is actually getting me to move away from intellij and friends.
I wish IntelliJ moves in this direction so bad - would gladly pay more for this. I tried switching to VS Code for my current project yesterday and it's the best VS Code scenario out of my projects - backend RoR frontend React/TS. TypeScript aspect is amazing but the Rails part is nowhere close to RubyMine.

.NET (Core) was inferior to any IDE (even Xamarin ones) last time I tried it (~6 months back). IntelliJ Rider has been quite an amazing discovery in this regard - I prefer it to Visual Studio.

And then there are things like mobile development which VS Code has realistically no chance of touching.

Any language I can think of other than TypeScript - VSCode just cannot come close to IntelliJ support. I would pay for the ability to have a desktop machine on which I could SSH develop from say a Windows tablet/2in1 with integrated 4G and hardware powerful enough to run the client editor + productivity apps and has portability + battery life (say some intel low power series + 8GB ram)

I agree. I’d love remote intellij development, but it doesn’t seem to be something they’re interested in at all.
VSCode team's highest priority is Javascript/Typescript, everything else is just trailing behind. Python and C++ are the very well supported ones. .NET is still really bad.
In my experience, it can't even do it for TS either.

WebStorm seems to understand Microsoft's TS better than the VS Code Plugin. Complex refactors actually work.

RubyMine can become a resource hog - even when it's not acting up the VSCode responsiveness is a noticeable improvement for me (and I'm working on a i9 MBP with 32gb ram !) - for example code refreshes analysis hints and opens autocomplete much faster.

I don't trust any refactoring tool to do cross file refactoring correctly in JS/TypeScript and the code navigation stuff in VSCode has been rock solid for me - I don't really miss anything and it's a much faster environment to work in - if I just had to do JS/TS development I could switch without any issues.

Vscode has an excellent support for golang too. Python support also is good but sometimes it’s hit or miss with some native dependencies.
VScodes support for Golang is meh. My entire team has switched to using Intellij/Goland.
Try solargraph for VSCode. I've found it about as useful as RubyMine.
But intellij has had remote dev support for longer than vscode has even existed, what am I missing?
It's amazing!

I've been doing some AOSP customization (Android 9) and I have several remote (Ubuntu) servers hosting/building OS images for different implementations (it takes too much disk space for a local PC and even so, I have a Windows based PC because of reasons, so if I had to use VMs, it would be too slow).

Now I can use intellisense through the entire Linux folder without delays. And... a global search for a string takes no more than 2 seconds. And I am talking about a string search through the entire codebase (not just the kernel; thousands of files).

My days are brighter, my life happier, my mood changed; thank you whoever invented this!

How does it work with poor or slow internet connection?
In my experience, pretty well. If the internet cuts out temporarily, it reconnects automatically without losing any of your work.
It’s actually impressive how often VS code or ssh has exploded for some reason without losing any work.
Should be fine - most editors will not round trip on every key press, only periodic saves or command runs.
True, I love it and it has been a game changer. The only problem with that is that it only works with the official VSCode, not with the OSS counterpart, which is a damn shame.
The WSL integration is a pretty good result of that effort too.
Is there a way yet for me to run a server on Windows, and be able to code anywhere from my web browser? I basically want code-server that works on Windows.

https://github.com/cdr/code-server

You can register your own machines with Visual Studio Codespaces: https://devblogs.microsoft.com/visualstudio/bring-your-own-m...

It's not entirely self-hosted, but it's an interesting hybrid middle-ground.

Coming soon :)
I wish the vscode remote dev functionality didn't require a binary server/remote side component. I have a bunch of users who want to use it, but it's not compatible with the system libraries on our servers and dev environments.
Reminds me of a job in a past life I was quite happy to leave. It seemed like all I did was clean up low-end websites compromised through Frontpage extensions.

That was a year I'll never get back, but I do highly recommend the fun of leaving _vti_bin/ directories laying around with funny-behaving things in them. Every few months I still see evidence in my personal site logs of a script kiddie slowly becoming enraged as they figure out I left them a busy box to play with.

Are you sure it needs a remote component? The remote SSH dev experience is actually pretty good in python.
Quite sure. Here's the documentation.

https://code.visualstudio.com/docs/remote/remote-overview

It seems like it runs all the functionality on the remote end, and the vscode instance you're running on the machine in front of you is just the GUI. To install this, you need ssh access, and then it drops some binaries on the remote system and uses ssh to start them up -- so it looks to a layman trying to get this working that "it only needs ssh", but that's just for the install stage. These binaries only work with more recent releases of glibc.

You know what's interesting about some of the features listed on that page:

- Develop on the same operating system you deploy to or use larger or more specialized hardware.

- Sandbox your development environment to avoid impacting your local machine configuration.

- Make it easy for new contributors to get started and keep everyone on a consistent environment.

- Use tools or runtimes not available on your local OS or manage multiple versions of them.

- Access an existing development environment from multiple machines or locations.

We have all those already with the way our development environments are setup, but the reason people want to use vscode is for the editor, no one asks about the above things.

So then perhaps you could mount the remote file system with something like SSHFS and use VS Code locally?

I don’t understand what VSCode could provide that would be useful while not executing any code on the server side. It sounds like what you’re really asking is that vscode be made compatible with older version of glibc?

sshfs is god awful slow for heavy local editor use. I don't understand what vscode provides other than an editor when all those capabilities are something that already exists when working directly on a remote machine, either.

I am asking that vscode be made compatible with older, established builds of glibc; or that the server component be open source so it's potentially possible to get it to work.

Use the remote containers plugin and that problem goes away.
Didn't we already solve this problem with containers?
You should read the article...nothing to do with containers...
The article has a lot to do with containers. When you spin up a code space, you get a containerized workspace for the current repository.

> Codespaces sets up a cloud-hosted, containerized, and customizable VS Code environment. After set up, you can connect to a codespace through the browser or through VS Code.

(But that wasn’t what the parent was referring to...)

I believe he was referring to the system libraries being outdated problem
There are perpetual reminders all around that Microsoft's only pretending to like f/oss because that's where the developer attention (and thus corporate money) is. There's spyware in all of their open source apps (TypeScript excluded, because they couldn't get away with it there) that you can of course patch out, but you can't get it removed from the project because, free software or not, Microsoft gets to decide what goes in or out.

Bet you a dollar the GitHub mobile app that's going to come out pretty soon will also be totally proprietary with no source provided. It's a growing trend in developer tooling: even Docker's desktop versions (not Microsoft's fault, but still) are not even open source (much less free software).

It's going to be really sad in a few years when Microsoft starts turning the screws to extract more revenue from this free software ecosystem (GitHub/npm) that they are coming to exert major control over.

Soon, the most common "industry standard" tooling for the largest and most popular software development ecosystem (javascript) will rely heavily on proprietary software that spies on you continuously while you use it, just like Windows.

> Bet you a dollar the GitHub mobile app that's going to come out pretty soon will also be totally proprietary with no source provided.

Stable version already came out a while ago, been using it on my phone. Also, GitHub the website has never been open source and they never pretended it was or was going to be, so no one was holding breath for source code of the mobile app.

I mean, they could have totally released the source and it probably wouldn’t impact their bottom line at all.
It would make quite a dent in support contracts for their on-prem offering.
I'm pretty sure it wouldn't. The mobile app isn't something that requires a ton of support anyway. What good would the source code do you in this case?
The view of the Eclipse Foundation onto VS Code may be interesting here: https://blogs.eclipse.org/post/mike-milinkovich/theia-open-s...
whoa, slick.
Yeah, this.

The analogy seems clear to me: The web is to IE as git is to VSCode, eh?

At the very least, it makes it harder for an editor to be a competitor to VSCode w/o integrating with GitHub (not just git) now, eh?

It’s telling that they went with VScode and not Atom. Makes me wonder what the long term outlook for Atom is.
Not really. At least: the web happened well before IE was introduced as an answer. In contrast, VS Code was invented much later than git which at the time was an established technology and in some ways a standard.
The other context here is that IE was a competitive browser in its time: 1998-2001. The problem is that it won and then languished. IE had a lot of sway over how developers built things as the market share grew. Then it locked in users in various ways which starved the other competitors.

It took until Phoenix (now Firefox), for there to be something better that grabbed the attention of developers and those sick of being stuck with IE. It became Firefox and Mozilla hatched a pretty effective plan to steal market share. For all of Mozilla's recent failings, we forget (or weren't around to remember) the success of Firefox was pretty impressive as it was a grassroots effort.

GitHub has always been a proprietary company unconcerned with user freedom.

They actually have a whitepaper that predates acquisition on exactly this:

https://resources.github.com/whitepapers/introduction-to-inn...

The company has always been unethical; Microsoft didn't change that.

Wait for radicle.xyz
Those of you downvoting this - can you explain what you disagree with here?

Because it looks like a good analysis of this part of Microsoft's strategy to turn "Open Source" into a spyware-laden sausage machine for Azure.

I think the downvotes are because Microsoft has been providing some amazing tools completely free of charge. If that helps them sell more Azure... great! Everyone wins, except GitLab and AWS.

Calling it spyware is hyperbolic.

Keep it up Microsoft.

Some of us have longer memories of Microsoft's game-plan - embrace and extend. With so man now willing to grant Microsoft open source cred don't forget that it wasn't so long ago that Microsoft was running a Linux patent racket. If we allow The Beast to monopolise open source development tools we have only ourselves to blame.
Microsoft has been adopting standards to then extend them and lock-in users for two decades.

> Microsoft has been providing some amazing tools completely free of charge

Yes, and they are the opposite of a no-profit.

This are just the first steps: "embrace" and "extend".

Not at all. There are no objective criteria to define spyware that do not also apply to Windows or VS Code (and probably the GitHub mobile app, but I have not yet confirmed that).