
Visual Studio Live Share Preview - nitinreddy88
https://github.com/MicrosoftDocs/live-share/blob/master/welcome/welcome-owner.md
======
alkonaut
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?

~~~
lostintangent
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...](https://github.com/MicrosoftDocs/live-
share/blob/master/docs/collab-vscode.md#sharing-a-local-server)

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

~~~
mcny
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?

~~~
lostintangent
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 :)

------
kenning
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)

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

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

~~~
dingo_bat
> 12" Macbook 1.3ghz

> Windows 10

Sounds painful.

~~~
philliphaydon
> 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)

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

~~~
philliphaydon
> 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)

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

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

~~~
paulddraper
Exactly. It's a pedagogical tool. Like having a conversation, but with
executable code.

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

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

~~~
lostintangent
Send me an e-mail (address is in my profile) and I’ll get you an invite. We’d
love to get your feedback!

------
polskibus
Is that based on CRDTs / operational transform or is a different solution
used?

~~~
chillee
Operational transforms I believe.

------
jitl
See also Floobits, which has a similar product 5 years ago, which works great
in Sublime and Intellij:

[https://floobits.com/](https://floobits.com/)

~~~
octref
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](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.

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

~~~
lostintangent
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 :)

------
antoineMoPa
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)

~~~
Moter8
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](https://github.com/yudai/gotty)

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

------
chillee
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](https://github.com/MicrosoftDocs/live-share/issues/74)

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

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

~~~
lostintangent
We’d love to hear your feedback! Ping me and I’ll get you a Live Share preview
invite.

------
xstartup
I love pair programming with my wife. I wonder if there is any way to flash
fading emojis.

~~~
WorldMaker
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).

------
z3t4
It would be cool if you could start a session with someone using a different
editor.

~~~
eksu
I believe you can between Visual Studio for Windows and Visual Studio Code
(Windows, Mac, Linux).

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

------
mandazi
I bet this will be used for recruitment testing.

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

~~~
devwinportable
have to agree on this... exposing local dev env to some outsider requires a
lot of trust on some stranger

