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.
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.
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 :)
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)
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...
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)
> 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)
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
To me this seems like (I'll admit I only watched a video and haven't tried it) it tries to solve a very complex problem of allowing multiple live editors of the same file (?). Is that a solution in search of a problem?
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?
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.
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?
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 :)
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 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.
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.
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.
57 comments
[ 4.5 ms ] story [ 84.2 ms ] threadhttps://floobits.com/
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.
With VS Code and Xi’s asynchronous-first architecture, maybe collaborative editing will become a standard for new editors in the future.
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 :)
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)
> Windows 10
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)
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)
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.
It shouldn't be used to control what another guy is doing.
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, 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.
[1] e.g. http://collabedit.com/
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?
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 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?
Currently, it’s already very usable in these conditions, especially when compared to screen sharing :)
Looking forward to trying the VS Live Share, as I primarily work with VSCode anyway.
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