Note: I’m a member of the Visual Studio Live Share team, and this post is part of a series explaining why we built the product and the ideas we’re exploring.
Real-world development involves more complexity than just writing code, which is why collaboration tools need to evolve beyond the basic real-time editor. When we built Visual Studio Live Share, we wanted to support end-to-end developer collaboration, that not only provided real-time editing, but also, remote language support (auto-completion, go-to-definition, etc.), project-wide navigation/search, shared build, debugging, terminals, localhost servers, source control, integrated chat & code comments, and much more. This collaborative breadth is what enables Live Share to be used for such a diverse set of usecases (pair programming, merge conflicts, live site diagnostics, hack-a-thons, education, etc.), and represent a viable alternative to screen sharing. In fact, if you're curious which parts of Visual Studio Code are shared with guests during a Live Share session, the following screenshot should help illustrate that (hint: it's everything 🚀).
Out-of-the-box, Live Share enhances every feature of Visual Studio Code with collaborative superpowers, while allowing everyone to retain their personalized environment (e.g. themes, keybindings). That way, developers can leverage their favorite workflows and IDE configurations, regardless if they're working alone or together. The only difference is whether you’ve clicked the “Share” button or not 👩💻
While Visual Studio Code provides a compelling set of capabilities on its own (e.g. integrated debugging, version control), one of it's greatest strengths lies within it's ecosystem of 3rd-party extensions, many of which are fundamental to developer's workflow (e.g. GitLens, Live Server). As a result, Live Share couldn't actually achieve it's promise of end-to-end collaboration, unless it also provided a mechanism for extensions to become collaborative as well, and contribute their unique capabilities to the experience. So we had no choice but to build a Live Share SDK 🔥
An Ecosystem of Collaboration
At a high-level, Live Share works by establishing an E2E-encrypted peer-to-peer network, and then uses a set of built-in RPC services to expose remote actions from the "host" (e.g. go to definition, step the debugger), and synchronize editor state amongst participants in real-time (e.g. text edits, cursor position, terminal output). Live Share ships with enough services to make the core Visual Studio Code experience fully collaborative (e.g. debugging, editing, terminals), but by means of the Live Share SDK, it also enables extensions to contribute custom services as well, which can then exchange messages on top of the same secure channel. Additionally, the Live Share SDK enables extensions to contribute custom UI to its “Session Details” view, which supports improved discoverability and an integration that feels native with the core Live Share feature set.
With this, Live Share acts as both a product you can use, as well as a developer collaboration platform you can extend, which enables some really compelling scenarios! For example:
GitLens exposes a Live Share service for “guests” to remotely browse the project’s Git commit history as if it were locally available (example)
Test Explorer exposes a service for viewing and executing unit tests, and synchronizing their pass/failure status
Browser Preview exposes a service for collaboratively browsing web pages, and synchronizing mouse and keyboard input. Additionally it adds the concept of “Shared Browsers” to the Live Share tree view (example)
Team Chat exposes a service for sending and receiving text chat messages. Additionally, it adds a “Chat Channel” entrypoint to the Live Share tree view (example)
Whiteboard exposes a service for collaborative drawing, and synchronizing shapes and edit operations (e.g. undo, change background color) (example)
Pomodoro exposes a service for a collaborative timer, and synchronizing stoping and starting it. The timer itself is displayed as a node in the Live Share tree view (example)
Having these kinds of integrations allows Live Share itself to remain lean, while at the same time, enabling extensions to enhance it with new and interesting “light up” experiences (e.g. browsing documentation, whiteboarding, collaborative TDD). Additionally, it allows us to partner with the community, and explore how developer collaboration can continue to evolve and mature over time.
Besides building custom services, extensions can also subscribe to Live Share-specific events, and enhance their behavior when the end-user is within a collaboration session. This way, Live Share represents a “mode” that extensions can use, so that collaboration becomes a fundamental dimension of the way you work. For example:
Peacock allows you to specify a custom workbench color when you’re hosting a Live Share session, so that it’s visually clear you’re sharing
Live Server detects that you’re in a Live Share session, and automatically shares its HTTP server with guests (example)
Code Time automatically tracks the time spent collaborating with others as a key metric in your overall time report (example)
Profile Switcher allows you to set a custom profile for Live Share, so that you can easily turn off setting that your pairs might not prefer (e.g. format on save) (example)
Live Share All The Things
At any point, you can view the list of extensions that enhance Live Share by checking out the Awesome Live Share GitHub repo, as well as keeping an eye out for extensions that wear the “Live Share Enabled” badge on their readme. Additionally, you can track and upvote the planned and in-progress integrations on the Live Share Enabled Extensions Trello board. There’s still a lot more left we can do, and we need feedback on where to prioritize our efforts 👍
If you’ve built a Visual Studio Code extension and think it would benefit from Live Share integration, check out the SDK’s documentation, as well as the simple counter sample in order to get started. Additionally, reach out to me to discuss adding the extension to our allow list, since only approved extensions can make use of the Live Share RPC channel (for privacy and security purposes). We’re extremely excited to continue working with the community, and learning about new ways to make developer collaboration more enjoyable! 🙌
Top comments (7)
Wow, I feel like I just learned a lot about how Live Share is used.
In terms of building out your team's product, what are some "this is harder than it looks" parts and how about "this is easier than it looks" parts? 😄
Thanks! I’ve been meaning to write this post for a while, so I’m glad to hear it was useful 😁
In terms of your question, one of the hardest things we had to tackle (and continue to tackle) is building a solution that shares language support (completion, rename refactoring, go to definition, etc.) and debugging to guests for all languages, and regardless if the guest has the respective language extension installed or not. It was really important that we enabled a “universal” experience that didn’t require the guest to have the right tools in order to jump in and be immediately productive with their pair. However, that required a ton of work and collaboration with language owners, in order to get things just right. Even still, we have work to do in improving the underlying protocols to be more efficient in high-latency network conditions.
In terms of what is easier than it looks, we were able to build the integration voice chat experience on top of the Microsoft Teams infrastructure and using the SDK that I talk about in this article.
All-in-all, it’s a pretty magical experience to call someone directly within VS Code, and it was only a couple weeks worth of work, built on the shoulder of giants 🤗
The work you guys are doing on Live Share is truly impressive! It's become my go-to tool for collaborating with other developers and it's only getting better with every update. Thank you so much! 🙌
One question though: When I'm talking to someone over voice chat – mostly Discord – I don't need the "Code Comments" feature and the line it adds to the gutter is fairly distracting and gets in the way when I want to click on a Git diff. Is there some way to turn it off?
Thanks for the feedback! Unfortunately, there isn’t currently a way to turn this off, but we’ll prioritize the work to add a setting to disable it. We’ve actually been meaning to do that, but we were waiting to see if there was interest in that level of configurability. You’re not the only person that has found the comment gutter distracting, so we’ll try to get this change in the next release 👍
Hey there! I shared your article here t.me/theprogrammersclub and check out the group if you haven't already!
Thanks! I just checked out the group 👍
Great!