Visual Studio Live Share Preview(github.com)
github.com
Visual Studio Live Share Preview
https://github.com/MicrosoftDocs/live-share/blob/master/welcome/welcome-owner.md
57 comments
PM on the Live Share team here.
In many cases, yes, all collaborating participants would likely be working together in the same file. However, when speaking with folks as part of developing Live Share, we found that there were equally as many cases where developers wanted the ability to take certain actions independently (e.g. look up the definition of a function that’s in another file), without needing to disrupt the other parties, and without losing the ability to re-synchronize their focus once they were done.
With that in mind, our goal for Live Share is to support “opportunistic collaboration” between developers, that supports a broad spectrum of needs/workflows/personal preferences/etc. in a way that potentially feels more natural for folks as they are helping/teaching each other (e.g. sometimes I want to tell you what I’m thinking, and sometimes I want to show you).
Regarding your comment about being able to view the running app while debugging, we actually support the ability to “share local servers”, which allows this exact scenario for web apps/APIs/etc.
https://github.com/MicrosoftDocs/live-share/blob/master/docs...
It’s still early days for us, but it’s our goal that all meaningful editor/application context can be shared between participants, in order to effectively collaborate together (e.g. build output, terminal sessions).
In many cases, yes, all collaborating participants would likely be working together in the same file. However, when speaking with folks as part of developing Live Share, we found that there were equally as many cases where developers wanted the ability to take certain actions independently (e.g. look up the definition of a function that’s in another file), without needing to disrupt the other parties, and without losing the ability to re-synchronize their focus once they were done.
With that in mind, our goal for Live Share is to support “opportunistic collaboration” between developers, that supports a broad spectrum of needs/workflows/personal preferences/etc. in a way that potentially feels more natural for folks as they are helping/teaching each other (e.g. sometimes I want to tell you what I’m thinking, and sometimes I want to show you).
Regarding your comment about being able to view the running app while debugging, we actually support the ability to “share local servers”, which allows this exact scenario for web apps/APIs/etc.
https://github.com/MicrosoftDocs/live-share/blob/master/docs...
It’s still early days for us, but it’s our goal that all meaningful editor/application context can be shared between participants, in order to effectively collaborate together (e.g. build output, terminal sessions).
I know I've been (overly?) critical of Microsoft projects in the past but for what it is I continue to be impressed by Visual Studio Code. Thank you for your work in Visual Studio Code. I appreciate how it works across-the-board in fedora to a 32 bit Ubuntu based machine.
I am also glad you're pursuing difficult goals like opportunistic collaboration. By the way, have you looked into data usage (sorry for wrong word) I mean is live share usable over a stable 200KBps connection? An unstable 1MBps LTE connection?
I am also glad you're pursuing difficult goals like opportunistic collaboration. By the way, have you looked into data usage (sorry for wrong word) I mean is live share usable over a stable 200KBps connection? An unstable 1MBps LTE connection?
We’re still pretty early, and so we have lots of room to improve our network usage, and tolerance to instability. However, it’s absolutely our goal for Live Share to perform well (as well as can be expected?) on lower-bandwidth and volatile network connections (e.g. coffee shop WiFi).
Currently, it’s already very usable in these conditions, especially when compared to screen sharing :)
Currently, it’s already very usable in these conditions, especially when compared to screen sharing :)
Visual studio code is pretty great, been using it with typescript and c# but it can do a whole lot of things. also the vim plugin works better than sublimes'. They're doing a pretty good job speeding ahead of other editors in terms of features and plugin support.
Only thing is it's so slow. Just typing and navigating is pretty noticeably choppy. also it still has some memory leaks (although it used to be a lot worse)
Only thing is it's so slow. Just typing and navigating is pretty noticeably choppy. also it still has some memory leaks (although it used to be a lot worse)
I've been using vscode for dotnet core development for about a month now and I haven't had any of the issues you describe :S. I am running an alienware i7 laptop though...
I run it on a 12" Macbook 1.3ghz, running Windows 10 in bootcamp, and it doesn't have any of the issues he described either.
> 12" Macbook 1.3ghz
> Windows 10
Sounds painful.
> Windows 10
Sounds painful.
> Sounds painful.
With Windows 10 it's not, it's painful when running OSX, the animations make it laggy and stutter, while Windows 10 gives me about ~3 hours more battery life (cos there's no gfx switching like in the Macbook Pro)
With Windows 10 it's not, it's painful when running OSX, the animations make it laggy and stutter, while Windows 10 gives me about ~3 hours more battery life (cos there's no gfx switching like in the Macbook Pro)
System Preferences -> Accessibility -> Reduce motion X, Reduce transparency X ?
Not sure what you mean by "gfx switching", as far as I know all 12" Macbook have only a integrated graphics card, no discrete graphics card.
Not sure what you mean by "gfx switching", as far as I know all 12" Macbook have only a integrated graphics card, no discrete graphics card.
> Not sure what you mean by "gfx switching", as far as I know all 12" Macbook have only a integrated graphics card, no discrete graphics card.
With the Macbook Pro I get less battery life with Windows 10 because Apple forces Windows to only have access to the discrete graphics card. OSX can switch between the two so it's more efficient.
With the Macbook 12" I get more battery life, it seems Windows 10 is more power efficient than OSX. (I got the same as OSX when running Windows 7)
With the Macbook Pro I get less battery life with Windows 10 because Apple forces Windows to only have access to the discrete graphics card. OSX can switch between the two so it's more efficient.
With the Macbook 12" I get more battery life, it seems Windows 10 is more power efficient than OSX. (I got the same as OSX when running Windows 7)
Typing is slow? It's the fastest IDE I use, and the 2nd fastest text editor behind sublime. It's probably the extensions you have installed, try disabling all of them to diagnose.
It's slower than sublime and it's slower than vim of course... i guess i have high standards
VSCode member here. Did you use the Vim emulator all the time, especially when you feel typing is slow? It would be awesome if you can provide more info in https://github.com/Microsoft/vscode/issues and we'd love to fix the problem. Laggy typing/navigating is always a high-priority bug to fix.
i think the most obvious example is probably impossible for you to fix. when i press c to replace a word, then navigate to the next instance of the same word and press period, it types each letter individually, including my typos and backspaces over the typos.
i know you guys are just interfacing with the vscode api so there's some things you simply can't do, like skipping over folded code when navigating with j/k.
i know you guys are just interfacing with the vscode api so there's some things you simply can't do, like skipping over folded code when navigating with j/k.
Somewhat tangential, but, is live coding with multiple people working on the same editor a thing? I feel like something like this would be incredibly distracting to get any actual work done, but I guess there must be legitimate use cases for this.
It’s good for code review for small teams. Junior developer writes some bad code. Senior developer points it out just using his insertion pointer (no editing). If he wants to say “you should use the set() method here” he can just type it.
I am really interested in this, and certainly have done the equivalent thing locally, at times in my career, by just cramming 2-3 developers in front of the same monitor and maybe swapping the keyboard back and forth as we work on something tricky/weird.
That said, I don't think anybody is proposing this as the default working mode for writing software. It's a tool for specific kinds of situation.
That said, I don't think anybody is proposing this as the default working mode for writing software. It's a tool for specific kinds of situation.
In the introduction video to VS Code Live Share, they showed the scenario of asking your coworker for help. Then together in the same editor you both fix the problem. I don't think it is meant that two or more people work at the same time in the same editor all the time.
Exactly. It's a pedagogical tool. Like having a conversation, but with executable code.
I love that explaination! I’m a PM on the Live Share team, and like was mentioned, the use case we’re currently focused on is seeking and receiving ad-hoc assistance or feedback from a friend/colleague, in a way that can potentially be more opportunistic, productive and natural, regardless if you’re in the same building, working from home or across the world.
That said, we’ve heard a lot of interest in other use cases as well (e.g. pair programming), and are keen to understand how Live Share might be able to complement them.
That said, we’ve heard a lot of interest in other use cases as well (e.g. pair programming), and are keen to understand how Live Share might be able to complement them.
We are very interested at my work in the possibilities for pair programming using this kind of technology. We haven't been accepted into the preview programme yet, but we're looking forward to getting to try it.
Send me an e-mail (address is in my profile) and I’ll get you an invite. We’d love to get your feedback!
This can also be a great tool for helping people over the internet, say on an IRC channel or a friend, it's not limited to a work environment.
Very true. We’ll make sure not to unnecessarily imply that it’s only applicable in a business setting. Thanks for the feedback!
but arent you having this discussing face to face anyway? Why not make it face to face to display?
Lot of teams are remote. With WFH option being commonly used, scenarios where both of you are not f2f has become quite common.
I've been on both sides of a web-based editor[1] for "phone screen" interviews
[1] e.g. http://collabedit.com/
[1] e.g. http://collabedit.com/
Remote pair programming
Ugh. I have fond memories of pivotal guys being brought in and all they did was waste everyone’s time and money. They made sure everything they did was pair programmed for a freakin website.
Pair programming is a good way to learn from someone with more experience.
It shouldn't be used to control what another guy is doing.
It shouldn't be used to control what another guy is doing.
See also Floobits, which has a similar product 5 years ago, which works great in Sublime and Intellij:
https://floobits.com/
https://floobits.com/
Live Share is different than other collaboration tools in that it supports Language Features and Collaborative Debugging. By Language Features I mean all participants get auto completion, go to definition, error checking etc. Collaborative Debugging allows multiple people to step through code, inspect variables or look at call stacks.
I don't know why the GitHub doc get linked, but this page probably gives more context: https://code.visualstudio.com/visual-studio-live-share
Disclaimer: I work at VS Code and have tried Live Share in private preview. Honest feeling is it still has some gaps, but if everything would work out of the box it can be pretty awesome.
I don't know why the GitHub doc get linked, but this page probably gives more context: https://code.visualstudio.com/visual-studio-live-share
Disclaimer: I work at VS Code and have tried Live Share in private preview. Honest feeling is it still has some gaps, but if everything would work out of the box it can be pretty awesome.
Really cool to see this built into the editor. Getting over the hump of “well I could install this 3rd-party extension, create an account, and follow directions, or I could just walk over to my coworker’s desk for the 15th time” is probably a big barrier to adoption.
With VS Code and Xi’s asynchronous-first architecture, maybe collaborative editing will become a standard for new editors in the future.
With VS Code and Xi’s asynchronous-first architecture, maybe collaborative editing will become a standard for new editors in the future.
This is really great feedback! I’m a PM on the Live Share team, and it’s definitely our goal for the getting started/collaboration experience to be simple enough that it could naturally become part of your workflow (as needed).
If you’re interested in checking out the preview and letting us know how well we’re meeting that goal, I’d love to get your thoughts :)
If you’re interested in checking out the preview and letting us know how well we’re meeting that goal, I’d love to get your thoughts :)
What I need would be an open source server with client packages for Vi and Emacs (maybe other editors too) so I can collaborate with my evil friends. Any Idea of such a server? (note: I know floobits exists, but it is not open source, as far as I know)
There's also gotty, which lets you share your shell access over https. I've used tmux together with it, to show a simple thing to a friend and it worked quite well.
https://github.com/yudai/gotty
Similarly, there's tmate which sets up a shared tmux session and proxies the SSH connection so it works through NAT without issue. If you don't trust the connection going through tmate.io you can set up your own server.
how about tmux? screen?
or do you need more than those?
We can't edit the same file in Emacs and Vim at the same time using these.
[deleted]
One of the other use cases for this technology that I haven't seen people bring up yet is remote editing.
Whether you want to edit in a VM, or your company uses devservers, or you want to modify files on a remote server, the previous options were limited to terminal based editors.
VS Live Share should have the technology to enable that for VSCode/VS.
Check out this issue.
https://github.com/MicrosoftDocs/live-share/issues/74
Whether you want to edit in a VM, or your company uses devservers, or you want to modify files on a remote server, the previous options were limited to terminal based editors.
VS Live Share should have the technology to enable that for VSCode/VS.
Check out this issue.
https://github.com/MicrosoftDocs/live-share/issues/74
Thanks for mentioning this use case! We're (the Live Share team) very interested in exploring this moving forward, and so any feedback (using the tracking issue you mentioned), would be greatly appreciated.
I used Teletype with Atom this past weekend to help my cousin with his C++ homework, and it worked out pretty great. It was easy trying to communicate what to do instead of screen-sharing and specifying each line of code verbally.
Looking forward to trying the VS Live Share, as I primarily work with VSCode anyway.
Looking forward to trying the VS Live Share, as I primarily work with VSCode anyway.
We’d love to hear your feedback! Ping me and I’ll get you a Live Share preview invite.
I love pair programming with my wife. I wonder if there is any way to flash fading emojis.
You could use the Windows 10 People bar (sign in to your Skype accounts, add each other to your taskbars, and you can send emoji that pop up from the taskbar).
It would be cool if you could start a session with someone using a different editor.
I believe you can between Visual Studio for Windows and Visual Studio Code (Windows, Mac, Linux).
That’s correct. A developer in Visual Studio on Windows can share with a developer using VS Code on macOS/Windows, and vice versa. Enabling the ability to collaborate from the comfort of your favorite (and heavily customized) editor/IDE is one of the core goals behind Live Share.
I bet this will be used for recruitment testing.
I think coderpad still makes sense here and it’s pretty common in my experience: it doesn’t require any local setup and is good for one-off problems. VSCode would be suitable for longer term work like live collaboration on a real project with lots of files.
have to agree on this... exposing local dev env to some outsider requires a lot of trust on some stranger
Given the things I've seen used for that purpose, it would be huge improvement as an applicant, assuming it gives you basically VS/VSCode experience with sharing.
When you pair program with someone, or assist someone, for it to have any point at all isn't the idea that you always edit in ONE place, and that only one person edits at a time? How will personA know what personB is doing otherwise, if personB's cursor can be anywhere?
Next, when personA and personB agree they have gotten somewhere and they launch their calculator app, web browser or whatever, how will both see what is going on? Is there support for also sharing a window/desktop? I mean, sharing my debugger state is cool, but what about the actual program window we are debugging? How can Jeff help me by introspecting variables in my program, if he can't see the program window?
The simpler problem of "sharing a screen while coding" seems to me to be a solved problem: you share your screen and input, like any remote desktop solution has done for ages. I get that this is significantly lower bandwidth and more tailored to coding, but in return it seems to not solve many of the fundamental problems of collaborative development.
I can see this tech being much more usable to e.g. develop cloud based IDE's, or remote debugging on servers, than "collaborative development"! Am I overly pessimistic or missing the point?