Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook and Microsoft Partner on Remote Development

developers.facebook.com

Post reply on HN
Print view View original

21–30 of 145 posts

Re: Facebook and Microsoft Partner on Remote Development

#21

Post by rubber_duck »

jpalomaki wrote: post #10
galkk wrote: post #8

Everything is better than "cloud desktops" and everything that includes remote desktop connection for UI, with bad font rendering etc. I don't use vim, I use IDEs and like when they have native and fast rendering

vscode is based on Electron. So even if you run it locally, it runs on "browser". So Remote Desktop is not needed. 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://cod…

Electron is not the browser - it's node.js + HTML DOM - I get what you are trying to say but being electron based doesn't really buy you anything in the scenarios you listed, native UI IDEs can and do use SSH filesystem and language servers in a same way VS code does (for example both those features exist in visual studio proper, and work even more reliably imo)

Re: Facebook and Microsoft Partner on Remote Development

#23

Post by woadwarrior01 »

mraison wrote: post #17

Very happy about this move. Nuclide’s remote development capabilities were way above anything else I’ve tried (Sublime, IntelliJ Ultimate, VSCode, remote SSH mounts, etc). 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…

Indeed, I remember trying to switch to IntelliJ locally (with SSHfs on the server), a couple of times and always going back to Nuclide because of the lag with sshfs, whilst working there. Nuclide had a lot of problems, but good support for remote dev wasn’t one of them.

Re: Facebook and Microsoft Partner on Remote Development

#24

Post by jsnell »

taurath wrote: post #2

I’m disappointed this wasn’t really about remote workers but about remote development as in code doesn’t live on the machine. That said, remote development tends to be awful, and more tools could be helpful if it’s not specific to a FBs particular implementation of remote dev shards. Learning that at Facebook you don’t develop things locally and likely are on a box with all sorts of things tracking your usage and acc…

> all sorts of things tracking your usage and access to everything lends even further credence to the big brother thing.

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.

Re: Facebook and Microsoft Partner on Remote Development

#25

Post by jameslk »

The trend seems to be the IDE and development environment will move to the cloud for larger companies. This is what Facebook and Google are already doing. It makes ramp up easier, environments more consistent and tooling more predictable. Also you can spin up multiple development branches of the same codebase without having to switch branches or stash changes (a big deal when you have one giant monorepo). And probably harder to leak any IP.

Re: Facebook and Microsoft Partner on Remote Development

#26

Post by _bxg1 »

I was an Atom holdout for a while - it felt disingenuous the way Microsoft kind of swept in and usurped their idea.

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.

Re: Facebook and Microsoft Partner on Remote Development

#27

Post by kbumsik »

xxpor wrote: post #15

Remote development via TRAMP is the number 1 reason I'm stuck with Emacs. More support via other editors is always appreciated.

Try VS Code Remote Development extension now. It is already working as great as native and you will not miss TRAMP anymore.

https://marketplace.visualstudio.com/items?itemName=ms-vscod...

Re: Facebook and Microsoft Partner on Remote Development

#28

Post by dan-robertson »

xxpor wrote: post #15

Remote development via TRAMP is the number 1 reason I'm stuck with Emacs. More support via other editors is always appreciated.

The sad thing about tramp is that it requires code to be written agains it. When it was added to emacs, developers had not previously had to think that some buffers might be on remote machines and so their code would not magically work agains it. New code ought to be written with tramp in mind using functions that work remotely but this isn’t always done.

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.

Re: Facebook and Microsoft Partner on Remote Development

#29

Post by naoru »

I've just set up remote development VM on my personal server and it's super seamless. Love this stuff, crazy fast. It's scary that I, a person who expressed my dislike with Microsoft in the past, got hooked on VSCode + Typescript.

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.

Re: Facebook and Microsoft Partner on Remote Development

#30

Post by usecodium »

Just an FYI for people - The Remote Development extensions are not open source. I'd hope if Facebook were joining efforts, they'd do so on a more open project.

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...

Post reply on HN