Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris--un-co-located--Coyier. Hey, Chris.

[Laughter]

Chris Coyier: Chris-real-time--Coyier. Yeah! I'm doing just fantastic. Thanks, Dave. We have a special guest to talk about a particular feature of a particular product, so it's kind of a niche thing, but it's not niche in the way that so many developers use this thing now, or at least the platform that the feature is on. Wow! I'm being so cryptic, but we're going to get to it. Don't worry. We have Jonathan Carter on. Hey, Jonathan.

Jonathan Carter: Hey. Thanks for having me.

Chris: Sure. Jonathan, you're at Microsoft, and it looks like you kind of have been forever.

Jonathan: I am, yeah. I've been at Microsoft for almost 12 years.

Chris: Wow!

Jonathan: I had the opportunity to work on a bunch of different stuff.

Chris: Yeah, that's great. Lately, I think our conversations start with the idea that you are the lead project manager on VS Code. The project is Live Share, which is, in the grand scheme of things, a relatively new thing for you all, right? Do you want to--super high level--tell us what that's about?

Jonathan: Yeah. yeah, my team kind of owns a handful of different service-backed experienced VS Code, Life Share, Intelicode, and we're also building the kind of VS Online Web-based editing experience as well. Live Share, really, at its crux, is just real-time developer collaboration built deeply into the editor. That way, much like you would with Office documents where you can collaborate in real-time with someone, edit, add comments, and kind of work together with them as needed, Live Share makes it such that you can, with a single click of a button in VS Code or Visual Studio, invite someone into a collaboration session with you, edit files, debug, share terminals, share localhost servers, share inline code and comments while everybody gets to stay and retain their own personalized editor environment. That way we have this mantra of sharing your context, not your screen. Unlike screen sharing, what Live Share enables is that I could be in VS Code with my dark theme on Mac collaborating with someone on Windows who has an entirely different theme, key bindings, window layout, font size, et cetera.

Chris: Yeah, right.

Jonathan: We're able to work together because we're sharing the same context of the code base, the language support, the debugging session, the data-driven or contextual nature of the IDE that's entirely separate from the kind of personalization and UI of how you want your environment to look and feel. Really, the reason that we found that to be so important is because developers spend so much time customizing their environment to feel familiar, ergonomic, and accessible for themselves and, because collaboration is so important, we've felt that it was important for folks to be able to do it frequently without sacrificing the setup that they've spent so much time building.

Chris: Sure. Sure. Well, we can get into all the reasoning in how it works shortly. It'd be interesting to hear a little bit of the VS Code story before we do too much Live Share stuff. Now that I have somebody from Microsoft here to ask about it, I think it's kind of fascinating. It seemed to, in a sense, come out of nowhere, although I don't know if that's what it feels like at Microsoft or not.

It's now just like this dominant code editor on all platforms. Everybody is using it. Everybody is hyped up about it. It just seems to have taken over. Is that what the feeling is like at Microsoft too, no surprise, or what?

Jonathan: You know I think that VS Code's goal was always to provide the best cross-platform development experience possible, regardless of the language. I think, over time, as we've iterated on the extensibility and worked closely with the ecosystem, it's been really exciting to see the response, like you've said, where folks from the GO community, the Rough community, Python, Java and, of course, Node.js and front-end Web development have all rallied around the tool, its capabilities, and the experience that it can provide for those different ecosystems. Yeah, we're absolutely--

Chris: [Indiscernible] …like, "Oh, we worked on it and we did a good job. Now people like it"? I guess that's just what it is, I guess.

Jonathan: I mean, yeah. I think it's just trying to have a tight feedback loop with folks. Of course, within the team, between our experience with Visual Studio and other IDEs, focus on the VS Code team in the past worked on Eclipse. There was some breadth of knowledge of what makes for a great developer experience but, also, what are opportunities to rethink things.

Chris: Mm-hmm.

Jonathan: I think the story with VS Code--

Chris: I guess … is that there's Visual Studio, which doesn't have that good of a rep, or at least in my circle. Maybe there's a ton of lovers out there. I'm sure there is. It's a big product. It's been around forever, right? Front-end developers, Mac people, whatever, it just isn't -- I don't know. I don't see it used that much.

To come from this big IDE kind of situation that people weren't loving so much and then release -- I guess it just does less, right? Isn't VS Code, in a way, is kind of like, remove the IDE from Visual Studio or something? I guess maybe I'm not explaining it or understanding it quite right.

Jonathan: Yeah. Well--

Chris: It's kind of Visual Studio lite, in a way, and that was key to its success.

Jonathan: Yeah. I mean, I think, in a way, you're right where Visual Studio or really kind of traditional IDEs, in general, are really meant to optimize for a kind of holistic, end-to-end experience for specific platforms and, as a result, can be a bit more prescriptive and have a lot more provided out of the box. For many developers, that kind of thing is their preference. We still have a massive audience of developers that love and usual Visual Studio, but the approach with Visual Studio Code was, as you said, to provide a lean and core set of editor primitives that folks could use and then choose to opt into additional capabilities based on need.

And so, out of the box, Visual Studio Code comes with a set of capabilities that we found to be really valuable. Like I mentioned, over the years with Visual Studio, we learned that things like auto-completion and integrated debugging were extremely valuable and compelling to developers. Those things weren't necessarily associated with lightweight editors. In a way, VS Code started as a lightweight editor that then introduced just enough to make it a lightweight editor plus-plus experience so that it felt like it brought with it some of the benefits that people might have traditionally associated with an IDE but without introducing the complexity that you might otherwise associate, so kind of getting the best of both worlds.

Then I would just say, the fact that the extension ecosystem, the decision was made to build VS Code using Electron, JavaScript, and Node.js and then passing that tech back onto the extensibility ecosystem has enabled a giant number of developers to easily target VS Code as a platform, which is then why we've seen an explosion of new experiences, new languages, and new extensions because the barrier of entry is low for folks to hack on the editor and then share their ideas.

Dave: What that a contentious decision for y'all? I pictured you have this 20-gigabyte flagship product that is perfectly engineered for writing .net applications, enable Window applications, and then you're like, "You know we're going to come up with a new one and it's going to be an Electron app for JavaScript developers." Was that sort of contentious or was that responding to a demand?

Jonathan: Before VS Code existed, we had already built a Web-based editor that's still available today called Monaco. That was built and meant to be used as an editor within the browser. You see that component be used all over the place. Most Web-based products that have an editor component to them are beginning to converge on Monaco.

On the one side, we already had this kind of Web editor, so we wanted to effectively reuse that same component in the desktop client. At the same time, we always knew this down the road. We also wanted to be in the position where we could make the entirety of VS Code also runnable and available from the browser.

As I mentioned, my team is also working on a … right now, a private beta called VS Online, which is a Web-based editor experience that you can create new dev environments in the cloud, connect to them from anywhere in the browser, including your iPad pro. Having the core of VS Code be built on Web technologies just had quite a number of benefits in terms of its ability, its reach, as well as, like I mentioned--

Chris: Yeah, that's a nice story, right? Building on the Web just has all these side benefits. It's like a nice portable technology. That's a cool part of that story.

Jonathan: Yeah, exactly. Yeah. Then I think, like I mentioned, the fact that the ecosystem around Web-based technology is so diverse and rich has then also made it such that the marketplace of extensions for VS Code has also just grown exponentially. I wouldn't say there was any contention in the decision to use Web tech because there were intentional benefits that that decision made sense that we've seen the payoff from.

Chris: That extension thing is such a big deal. I don't think I've quite done it myself, built one, but plenty of people I know have been like, "I think I'll hack together a little VS Code extension," because you can write it in such kind of familiar technologies, I guess, to Web people. In a way, that's kind of a big deal.

Jonathan: Yeah.

Chris: Like I'm on a Ruby project; you open up a .rb file, even on a raw install, and it's like, "Hey, let me help you out here. I can get syntax highlighting here." I'm sure this is highly familiar to you. You can install a dozen plugins and you have an environment for Ruby that's pretty great. Not an IDE, but just a base editor experience that's really customized to that particular language and the things it can do. That could be totally different from Rest developer. I don't even know. I've never written a line of Rest in that way, but I imagine the Rest situation is pretty good. You mentioned it right up top.

Jonathan: Yep. You're absolutely right.

[Banjo music]

Chris: This episode of ShopTalk Show was brought to you in part by Stackbit, Stackbit.com/ShopTalkShow. Stackbit is super cool. I swear to God, so static sites, you know, this JAMstack stuff. We talk about it around here all the time. It's growing fast. Front-end developers like us, we kind of get it already. It's really fast. It's really secure. It has all these developer conveniences. You get full control over the markup, the design.

But the client's part is a little trickier. They're like, "What do you provide for them to update their content? Where's the CMS?" It feels like that's a little bit of a hiccup in that the super mainstream adoption of JAMstack in a commercial context is about solving that issue. That's where Stackbit comes in. Stackbit allows you to build and deploy a full JAMstack site with a static site generator and a headless CMS in just a few clicks.

That's the thing about it. You choose from -- it's like you start with a theme and you don't have to. There are multiple ways to do this, but it's kind of like a wizard of, like, I'll take this theme on this static site generator with this headless CMS. There's work to do when you're setting that up. All of you all can do that, probably. But it's like, wouldn't you like to just go click-click-click, and then you have it, it just deploys to your Git repo, and it's ready to use. The CMS all hooked up and all that stuff already is pretty great.

On top of all that, Stackbit just released custom themes, so now, if you've already built the theme and you're working on a static site generator already, including the ones like Gridsome, ViewPress, and some other ones, you can put a Stackbit configuration there, Stackbit.YAML file, and define the content … that your theme is already using and then connect it to any of these headless CMSs. It's pretty cool. You can use a part of the build process.

Stackbit allows you to test the strength and weaknesses of different headless CMSs because of that reason. It's easy to explore the different ones, which is pretty cool. We're talking about, like, Forestry, Netlify CMS, Dato CMS, Contentful, that kind of thing, and the SSGs are like Hugo, Jekyll, Gatsby. That's just a lot of combos there. It's all very exciting to me. It just goes to your own repo, too.

Stackbit just helps you get it all done but, in the end, it's just your code. Go to Stackbit.com/ShopTalk to feel the magic. Let us know what you think.

[Banjo music]

Chris: We have Monaco, this browser-based thing that VS Code has inside of it and works because of Electron. Then we have VS Code exists and all these extensions exist. You're like, "Whoa! Let's make it even better." VS Code is wildly successful. What is the pair programming scene like or how can we get people working together? That's what this Live Share thing is about.

In fact, Dave and I have a little Live Share session open right now just because we thought that would be fun to try.

[Laughter]

Dave: We were doing it the whole time!

Chris: [Laughter] I've done it a number of times on Team CodePen because we generally all use VS Code. Once in a while, to repair a program, it's easier to be doing it that way. Maybe just through lack of muscle memory or something, it hasn't quite totally taken hold with us yet, but we'll see if we get there or not.

Part of it is, it's just a little weird. You've got to figure it out. For one thing, you've got to talk somehow anyway. You probably have a Zoom call open anyway, or is there some kind of audio/video thing built into Live Share too? Is that like a V2 thing? Did I just miss it?

Jonathan: Yeah. No, it's a good question. I would say, in many ways, much like the story that we just talked through with VS Code where we kind of started lean and then provide the option for folks to opt in to more capabilities, when we initially built Live Share, we built it with the recognition in mind that many teams already have kind of a communication tool that they've standardized on and that we didn't want to replace that. We wanted to complement that. A bunch of people that use Live Share today continue to use Slack, Zoom, Teams, or Skype for their kind of audio call.

Chris: Right.

Jonathan: They might spin up a call and then start a Live Share session. You're really just kind of using that tool for the ambient audio channel, but your full screen in Visual Studio Code and working on that using Live Share. That said, over time, we found that there were quite a few use cases that people were interested in using Live Share for that weren't necessarily formal team-based interactions where you already have a tool, but more like ad-hoc groups of people where having a built-in audio and text chat experience was really valuable.

For example, if you're working at a hackathon, student projects at a boot camp, or a team-based brown bags, or we see this all the time where just online communities within Slack channels for React, JS, or whatnot. When people want to leverage Live Share and use that to kind of get together, it would potentially be a hassle to say, "Oh, okay. First, we have to coordinate what we're going to use for video and chat. Then we're going to use Live Share." What we've done is, you have the core Live Share extension and that does not include audio and any chat, but then we have what's called the Live Share Extension Pack, which is Live Share plus integrated audio and text chat.

Chris: Oh, nice, so you … built it yourselves.

Jonathan: Yeah. Yeah, and so what we did is the audio is actually built on top of the Teams audio infrastructure. That way our team didn't have to go build out audio calling and all that sophistication.

Chris: Yeah. I was thinking, like, what is it, FRTC? But it's not.

Jonathan: Yeah. Yeah, well, and the benefit of that is that, one, it enabled us to deliver extremely quickly, but the fact that we're using the Teams infrastructure doesn't mean that you have to have a Teams account or install anything extra. We're leveraging.

If you're using Live Share, you don't have to install or do anything more. You just start a call and then everyone in the session can join that call as if it's a native part of Visual Studio Code. But, behind the scenes, we're able to work with the Teams organization as they make improvements to their stack that then just accrues to us.

Then, in addition to audio, we also have text chat. If you install the Live Share Extension Pack, you will see, basically, a new --in VS Code, Live Share has its own tab. When you're in a Live Share session, there is kind of a session details tree that shows all of the resources that have been shared, whether it's terminals or servers. There's a new entry point for opening up a chat channel that is scoped to all of the participants in the session. That way, if you're in a setting where you don't want to use audio chat, you can chat with someone using just text or you can do audio or you can do both. We think that's pretty cool because then the Live Share URL becomes the single rendezvous point, so to speak, for the entire collaboration and communication experience.

Dave: Wow. This is wild. It turns code into a discord, almost, because you're just like, "Okay, let's hop into a call." Beep. I didn't know the extension pack existed. This is very cool.

Jonathan: Yeah.

Chris: Did you install it and I didn't, so you're chatting with me and I can't see you, or what?

Dave: Oh, I'm just looking at the docs here.

Chris: Oh.

Dave: But it's pretty cool.

Chris: Oh, okay. Cool.

Jonathan: Yeah, so, over time, we're going to start kind of promoting the pack a little bit more just because, so to speak, following the unit's philosophy, we wanted to start lean first. But what we've kind of, over time, learned and grown in confidence is that many people see the value of the integrated chat as a companion experience, so it's obviously not trying to replace your existing communication tools but, in order to kind of have that seamless, single entry point for all things collaboration, we just found it makes sense to have the chat built in.

Chris: Yeah.

Jonathan: If people don't want it, then they don't have to install it.

Dave: Yeah, I could definitely see this. Even from an accessibility standpoint, somebody who is deaf or has a speech issue or something, they might feel more comfortable chatting out feedback.

Jonathan: Exactly. Yeah.

Chris: Perhaps. That's how I experience most pair programming today, which I'm a huge fan of. I love that this world is getting richer because I just think people get more work done and they do better work when there are two people doing it.

Jonathan: Yeah. Yeah.

Chris: You're less distracted and you're sharing ideas. It just couldn't be better. The dumbest way you can do it--I do it every day--you're on the Zoom call and one of the two of you clicks that share screen button, shares the window, and you're both looking at it at the same time. Even that is good but, of course, it's quite limited. There's a lot of, like, "No, look at line 37. See that?" You know.

Jonathan: Yep.

Chris: You know. Like I said, it's still cool. It's still useful, but probably a lot easier if you -- I don't know. There are a million things you can do, but this gets me into, like, so far, I'm finding it like an uncanny valley of sharing, in a way. Like, let me paint the picture a little bit. If your code is already on some cloud server, like we have a real-time feature on CodePen called Collab Mode, and it's similar in spirit in that multiple people can just share cursors on the same code and you can see their name above their cursor. You see them working.

It's the same kind of deal except for that this code lives on CodePen. There's no mystery of, like, what am I looking at here? You're looking at code that's saved up on this cloud server and there's an owner of that code. They can save it, share it, and whatever, or like Cloud 9 or whatever.

Jonathan: Mm-hmm.

Chris: I haven't used it much, but it's like Amazon's thing. The code is on the cloud. Okay, cool. This is unusual.

The screen sharing thing is obvious, too. I'm looking at your local code in this case. Cool. I get that.

Jonathan: Mm-hmm.

Chris: Whereas in this case, you're talking about this shared context thing. I think probably a lot of people get it. It seems like you went over that pretty fast, but it's unusual.

I have shared with Dave. What Dave is looking at looks exactly like his VS Code, but none of that code is on his computer. It's on my computer, right?

Jonathan: Correct. Yeah. Yep.

Chris: Even though we're working on the same team, so he probably also has this project open locally too. It just feels weird to me. It's like, which file am I looking at here? Am I looking at the one that's on my computer because we work on the same project, or am I working on the one that's on Chris's computer? [Laughter] You're like, "Ugh!"

Then if he's working on some other file on the project, you've got to figure out where they are or what line number they're on. I'm sure there are tools all around this. It's just my unfamiliarity. I don't know. What do you think about all that? Is it obvious to people what's happening when you share?

Some of the stuff that came up for us was like, what if you console.log something because you're in a JavaScript app, like I'm running Node code or something? Does the code run on Dave's computer even though it's on my machine? [Laughter] It's all very confusing.

Jonathan: Yeah. Yeah, I mean, really, I think, as you said, the product itself is still relatively new in terms of being generally available and so I would say we absolutely still have work to do to improve the way we position it and make it more intuitive, like you said, because it is a bit of a different class of experience. That said, I think the thing we learned and kind of what led to building it was that there were a bunch of situations where developers wanted to collaborate with someone and that other person maybe didn't have their machine set up entirely in order to collaborate with them.

Chris: Oh, right.

Jonathan: They didn't want to have to centralize or move their code or their dev environment to the cloud simply in order to take advantage of the state they're in and get help right away. I think, when we look at services like CodePen and the other ones you mentioned, those provide an amazing experience and, in a way, they were kind of cloud-first, so to speak.

With Live Share, we wanted to enable it such that you're working on your local machine, your laptop or whatnot, and we just want to make it as trivial as possible to click a button, give it to someone else, and know that they don't have to do anything in order to start working with you.

Chris: I'd say that's the happy path here, in a way. If I want to get help on something and I just share them this link, it opens up in their editor environment, it has everything that I have, and I know it all works because it's my local dev environment, that's very cool. You know?

Jonathan: Yeah.

Chris: It could open up a whole class of work. It could be like, "Hey, I'll help you with your Python project. Just share a link with me, you can buy an hour of my time, and I'll help you. I don't even have to worry about installing your project. Just share it with me."

Jonathan: Yeah.

Chris: I love that.

Jonathan: Yep.

Chris: Yeah, I'm just confused a little bit by, like, if we were both on the same team. Is that like, "Whoa, what am I looking at here, yours or mine?" situation?

Jonathan: Yeah.

Chris: Not a criticism. I'm just trying to figure this all out.

Jonathan: Yeah. I really appreciate the feedback. I think it's something that we have a lot of work to do in order to respond to that. But in terms of what's actually happening is, you can think of it that Live Share turns the host's IDE into basically a peer-to-peer server that, when someone joins the session, they're able to request the data that they need only as it's necessary. What happens is that when you share using Live Share, there's no code being uploaded. There's no nothing happening at all. It's just effectively getting a URL that someone else can use to join and then that becomes the rendezvous point for discovering each other.

It's like, okay, what IP address is Chris on? I use that to connect to him. Then from there, only the bare minimum of information is requested. The moment a guest joins, we basically have a simple protocol that the tool speaks between each other that'll say, "Give me the tree structure, but only the top level."

Chris: Yeah.

Jonathan: That way, to the guest, it looks like they have the entirety of the project, but it's virtualized.

Chris: Just some file names, folder names, and stuff.

Jonathan: Yeah, exactly right. Then it'll say, "Give me the contents of the file that the host is in." We immediately jump you into the location, and so we download the contents of one file. Then, if a guest hovers over an expression, we'll say, "Give me the hover information for this." If they do a go-to definition, "Go to the definition of this." If a debugging session is started, you could imagine there's an event getting sent from the host to say, "We just paused at a breakpoint here and here are the contents of the call stack." If a terminal is open, there is a stream, effectively, between the two participants.

in a way, we kind of decompose the entirety of the editor and turn it into a protocol that we could distribute and make super-efficient such that people can join into someone else's session and power everything from that host. That has the benefits, like you said, where--

Chris: That's familiar to a Web developer who is like, you know, they're managing a global state and they're trying to share as little of that state as they can.

Jonathan: Yep.

Chris: They're waiting for user interactions to share more of that state. It's nuanced because sometimes you need an active stream and sometimes you don't. Sometimes you wait for a click and sometimes you don't. It's like building a Web app.

Jonathan: Yeah, exactly. The beauty of it is, like we were just discussing, the person that joined the session does not have to have any extensions installed other than Live Share. They don't have to have any tools or runtimes installed.

If we're debugging a Python app, like you said, I don't have to have Python installed. I don't have to have the Python extension installed, but I can entirely navigate, debug, et cetera, that application because, as long as you as the host have set up your environment for that, then I get that automatically.

To your point, it makes a bunch of scenarios suddenly trivial. If you have dev leads that are working on multiple projects and they get a request to kind of help someone or do quick pairing, they don't have to worry about switching context or getting their machine into the right state. They just join the session and they're ready to go.

We have a bunch of companies that use Live Share for product support, so like dev Sass products where maybe you have a customer that's trying to use your API or your SDK. It's not working. You can just jump into a Live Share session with them without having to do any setup or reproduction of the issue.

Even at Microsoft within the Visual Studio support team, beginning to start to use Live Share for support with our customers as well. But also, things like TAs doing remote office hours for classes at Universities where, once again, just removing the entirety of the setup in order to get to the exact state that the person seeking help is in just ends up being a good productivity boost.

Dave: It fixes that, like, commit up a broken branch thing and then somebody else picks it up from there, sort of thing, you know. Like, "Here's where I got it."

Jonathan: Yep.

Dave: You can just….

Jonathan: Yep. Exactly.

Chris: What I learned in using this just, again, briefly here is that, even though I've shared, I can just do whatever I want. I can just go off and do my thing knowing that Dave has shared it too. It's almost like there can be a leader because of this pinning concept or following concept where, if I'm like, Dave's leading right now, I'd probably click on Dave's name, which is cool in that it instantly moves to whatever file and position in that file that Dave is at. Then if I pin him or whatever, then even as he scrolls, selects things, and types things, I can see him doing all that. I'm kind of like, I think I can still work too, but it's almost like don't because he's moving and typing. My screen is very much following what he's doing. We could easily shift that or I could stop following him. He could follow me or whatever else.

Jonathan: Yep.

Chris: That's nice, in a way. I think that's an important aspect of this. Otherwise, it's kind of weird. If I haven't followed him, I'd have to manually try to figure out where Dave is and what he's doing. That would be too much. The fact that I can just follow him and my screen very much just follows what he's doing is pretty clutch.

Jonathan: Really, the kind of core, I would say, value props that we've found Live Share as compared to screen sharing. One of which I mentioned is the ability for everyone to retain their personalized environment. Really, the second is kind of what you just mentioned where you're able to work entirely independently or together based on the needs of the collaboration. Even further, like you were mentioning with pinning, you can actually passively follow someone while also working independently. You could have a split view editor layout where you're typing in one file on the left and then you've pinned the editor on the right to Dave.

Chris: Oh really? That's awesome! That's great.

Jonathan: Yeah.

Chris: You can have the best of both worlds, in a way, and be following them.

Jonathan: Exactly.

Chris: Yeah.

Jonathan: Yeah, and we've seen interesting cases where teachers running maybe instructional classes for corporations or boot camps where you can do a grid layout where you've got seven different editor tabs pinned to entirely different people, and so you kind of almost have a way to observe or work with a larger group because right now, with Live Share, you can have up to 30 guests. It ends up enabling some flexibility where what we wanted to do was provide people with the option to say, "Okay, if you prefer a form of pair programming where you're always working on the same exact task together, then you can do that." Right?

You just follow Dave. As he moves, you move with him, and you can take advantage of that much like you would get with screen sharing. But we see a lot of people that like to do even temporary independence. Maybe you're fundamentally working on the same problem, but even something as simple as if there's an API being used in the code that you're not familiar with and you want to go do a quick jump to definition of it to see what it's doing and then come back, you wouldn't have that flexibility with screen sharing whereas, with Live Share, you would.

Chris: Right.

Jonathan: Or if you're debugging together and you want to go look at an older or a frame later on in the stack without interrupting the other participant, you can do that. Giving folks that flexibility to not be entirely mentally serialized, so to speak, which we find for some people allows them to actually enjoy pair programing a bit more because they don't have that feeling of, "I can't explore an idea real quick and then come back without interrupting you." Live Share lets you do that.

[Banjo music]

Chris Enns: This episode is brought to you by An Event Apart. An Event Apart is the premier Web design conference for UX and front-end people just like you. Each event they put on is three days of design, code, and content for interaction designers and developers packed with tips, techniques, and insights into the future from industry shakers and shapers.

If you've been in the past, this year they've adjusted things so that all of their shows in 2019 will be 3 days long with at least 17 speakers for each show. If three days is too long to be away from home or the office, they also offer one- and two-day conference passes as well.

The next few events coming up are in Denver in late October, San Francisco in early December, and they've even got 2020 dates and times posted, so be sure to check out AnEventApart.com for all the details. Our thanks to An Event Apart for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: This terminal concept, it's one person's terminal, just to put a point on it, right? If I open up the terminal while I'm sharing with Dave or Dave opens it because I've shared with him and he types NPM install, that NPM install is going to execute on my computer, right?

Jonathan: That is correct.

Chris: Cool, so it's a big responsibility to give somebody.

[Crosstalk]

Jonathan: It is.

Dave: Install hacker virus.

Chris: Yeah.

[Laughter]

Jonathan: It is. So, when you open up a terminal, by default that is only shared read-only. The intention of that is that, with many app types, the terminal output is so fundamental for seeing build failures or test failures, and so it's an important piece of context. But Dave or if you invited someone into the session, they would not ever inadvertently get write access. Like you said, yes, you really want to be confident that's the right thing to do.

Chris: You can give them write access, but the default is not.

Jonathan: You can.

Chris: Okay. I see.

Jonathan: Yeah. Yeah, the default is not, and so what'll happen is if Dave tried to type into that editor, he would get a prompt saying, "Do you want request write access?" He could say yes. The host would then get a toast on their end saying, "Hey, Dave wants to write to the terminal," and they can say, "No way," or they can say, "Sure," or, at any point, you can revoke or grant write access to a terminal from the Live Share session details tree as well.

We definitely encourage folks. In most cases, you probably don't need a writable terminal, but it's there if you need it.

Chris: Yeah.

Dave: This is a killer feature for me. If you've ever tried to set up Ruby on somebody else's computer, sometimes it would just be easier, like, let me just do it.

Jonathan: Mm-hmm.

Dave: It's like pasting error messages back and forth. I work with designers, and sometimes NPM will get out of whack. It's like, okay, do RM, RF, Node modules, and then people might not feel comfortable doing that because this is kind of like the RM command. That's like remove everything. You know?

Jonathan: Yeah.

Dave: But I could just be like, "Give me access here temporarily and I'll get your computer all fixed up." That would save, quite literally, probably 30 minutes a week for me just getting environments all back in shape and stuff like that.

Chris: Yeah.

Dave: That latency when you're like, "Hey, try this command in Slack." Then three minutes go by and they're like, "It didn't work." Then you're like, "Oh, okay. Can you paste the error message?" Three minutes go by. Then, "Okay, here's what it is."

[Laughter]

Dave: It's like half of the error message. I'm not … too much, but that's a very real interaction.

Chris: Oh, yeah.

Jonathan: Yeah. Yeah.

Dave: It's great.

Chris: You can … control over screen sharing sometimes, right? But even that is a little weird because you seed control to somebody over Zoom or whatever and then you just sit back and kick your feet up on them and be like, "Okay. Do it. I guess I'll go to lunch now or something while you work on this," which isn't my favorite experience.

Jonathan: Yep.

Dave: I like that it's read-only at the start because then you open the terminal, you go in there, and try to do something. There is probably some UI that's like, "Well, you can't. It's read-only right now." They'd be like, "Oh, I get it. It's read-only because it's not on my machine."

Jonathan: Yep.

Chris: That kind of does double duty.

Jonathan: Yep. I was just going to say, on the guest side, even in the little terminal picker UI, it would even say that it's a shared terminal. We try to make affordances when you're interesting with VS Code that you recognize, like, "Oh, yeah, this is a terminal that was shared with me. It's not a local one."

Chris: Yeah. Right, it's not the same as just command-backtick or whatever.

Jonathan: Right.

Chris: Was it control-backtick?

Dave: I'm really impressed. I'm on Windows. Chris is on Mac. We're working on a PHP site. Now I just got Chris's bash. I'm in his bash command, I assume on his Mac.

Chris: I'm going to give you read/write access. There you go.

Dave: Oh, boy. I'm just going to install something wild.

Chris: I can't see you type, though, but I could see what--

Dave: Okay.

Chris: You must be typing right now. Oh, I can see you type.

Jonathan: Okay. Yeah, you should be able to. Yeah.

Chris: [Laughter]

Jonathan: We don't currently show who is typing in the terminal, but that's coming. Yeah, everybody can type if they have write access.

Chris: Yeah. Dave echoed "hello" to my bash and it said "hello."

Jonathan: There you go. That's a killer demo right there.

Chris: I'm going to go ahead and make that read-only again. Sorry, Dave. [Laughter]

Dave: Nah, man. I was about to--whatever--grab CodePen secrets.

[Laughter]

Chris: Hey, can we do the elephant one, though? I think this is a big deal. When I work with people on pair programming, we are writing two lines of code, saving it, and refreshing a browser window or letting live reload take over, hot modular reloading, or something.

Jonathan: Yeah.

Chris: There is always a browser component to this. What's the story with that?

Jonathan: Great question. Live Share also supports a concept we call Shared Servers, which allows you to share any port that's running locally on your machine with the guest in the session. If you have a Web app running on port 3000, your guest joins, they would automatically be able to open up their browser to Port 3000 and view that running application. What's cool is that if that app was using Live Reload, then any file system saves would automatically trigger the reload for everybody even though it's all happening on the host machine.

Now, taking that even further, if you start your Web app from the terminal, so let's say you run NPM start or some Python command, we'll discover that server and automatically share it. That way if you're working with someone, you run the command or start debugging in order to spin it up and then everyone in the session gets access to it.

The way that works is that when someone joins a Live Share session, we actually establish an end-to-end encrypted SSH connection from the guest to the host. Then we set up a PCP proxy on the guest machine that accepts requests for ports that were shared and then proxy them to the host and back. It provides the benefit of sharing a locally running server with your participants but without having to expose it over the Internet or deploy it to some centralized server.

Chris: Fancy.

Jonathan: Oh, yeah.

Chris: I'm trying it right now. What I shared with Dave was our little ShopTalk Show website, which we never work on.

Jonathan: Okay.

Chris: It's a WordPress site, PHP thing.

Dave: This is the most we've worked on it in a few years. [Laughter]

Chris: We're going to work on it. One of these days, we're going to work on it, but it's been years, like Dave said. Anyway. Whatever. It's GitHub, but whatever. We're sharing and we're looking at it.

I can spin it up locally and our local URL is shoptalk-show.local. It's not a port or anything. Is that not going to work? Should I run a little--? I could run a little, like, different server or something.

Jonathan: Yeah. You bring up a great question. That is currently a limitation that if your Web app depends on a custom DNS name, so the server only responds to specific host's request, we don't currently support that but we're working on that.

Chris: Oh, okay.

Jonathan: But if the application was, yeah, a localhost 3000 or whatnot, like if you were using Create React App or many of the tools--

Chris: Right, right. Most of my projects are like that, in a way, or some of them.

Jonathan: Yeah.

Chris: Like I went on CSS-Tricks as well, and I have a little, stupid Gulp server that spins up. I type gulp-serve when I start working on that project and it spins up localhost 3000. If I copied localhost 3000 and pasted it into Shared Server, that would work with Dave?

Jonathan: That would work, but you wouldn't even have to copy that because, if you ran gulp-serve from the VS Code terminal, we would discover that it spun up localhost 3000 and automatically share it.

Chris: What?! Really. Oh, my gosh. We've got to try it right now. Are you ready, Dave?

Dave: Okay.

Jonathan: Actually, then it would also automatically launch in the browser on Dave's side.

Chris: Seriously? Okay, so I've got to share this thing and I already have shared with you, so now I can just click your name because--

Dave: You know me. I'm a known entity.

Chris: Yeah. Start collaboration session, so it's starting the session. It started the session. How do I invite you, Dave? You're under my recent contacts. Invite participants. Oh, I've just got to send you a link, huh?

Dave: Sure.

Chris: I'll send you a link. I'll send you a link in Slack.

Dave: See how easy it is -- okay. Yeah, I clicked.

Chris: The URL, you know … Live Share….

Dave: Open VS Code. I am in the VS Code.

Chris: Yep.

Dave: I am joining collaboration session.

Chris: There you go. Now I get a little popup that says Dave Rupert joined the collaboration session. Now I've shared with you the theme folder of the current CSS-Tricks them, right?

Dave: Yeah.

Chris: That's where the package.json is, the Gulp file, and stuff. I'm going to type, in the read-only terminal for now, gulp…. It's going to run Gulp. It's running fine. It's about to spin up localhost 3000.

Dave: It just launched a browser for me.

Chris: Did it, seriously?

Jonathan: Yep.

Chris: Can you see--? What do you see? Do you see an article that says "short"?

Dave: I tried to go to localhost 3000 and it bailed. That was maybe because the server wasn't ready.

Jonathan: Refresh the page, maybe.

Dave: Yeah.

Chris: It's a little funky because I'm authenticated into WordPress on my side. That would be weird if you could see that, but I don't know.

Jonathan: He would not, right. You're sharing the server but, obviously, he would be having his own local cookies, et cetera.

Chris: Yeah, right.

Chris: Ah, okay.

Chris: Whatever. Theoretically, this works, right? We don't mean to -- [Laughter] I didn't mean to….

Jonathan: Theoretically.

Dave: [Laughter] We tested it.

Chris: It did spin up a browser for you, which is impressing. What is it detecting here? It ran that command and then…?

Jonathan: Yeah. Basically, it's as simple as when you're in a Live Share session. We are looking for a certain pattern of URL in the terminal output.

Chris: I see. Yeah.

Jonathan: Then, even further, we have, basically, an allow list of ports that are known ports that represent Web servers.

Chris: Right.

Jonathan: Then we automatically share them. That way if you use the integrated terminal, it just works. If you don't, you can always manually forward a port too.

Chris: Oh, I see, because some people like the VS Code terminal and some people just use the iTerm or whatever other third party terminal.

Jonathan: Exactly. Exactly.

Dave: I think it's like trying to rewrite the URL to localhost, so I think it's trying to strip the port or something is. I think it's a demo fail at this point, but probably just -- I don't know.

Jonathan: Yeah. I mean there are definitely, along with the DNS kind of name we were talking about, there's still some edge cases with Web apps that we have work to do to make them fully shareable.

Dave: We've talked about some of the limitations, and I definitely see them as overcome-able. Those seem like fixable issues or something. But are there big limitations kind of like that. Is there stuff that this can't do? That, I guess, is my question. Is something like this we'll never be able to do?

Jonathan: Yeah, so out-of-the-box, the entirety of VS Code when you share with Live Share is going to be shared. If you look at the left-hand side activity bar, guests can do search. They can do debugging, language services.

Chris: Search too, that seems amazing.

Jonathan: Yeah.

Chris: The search request goes over to Dave's computer, executes the search, sends the results back to me, right?

Jonathan: Exactly.

Chris: I don't have….

Jonathan: Yep. Yep, exactly right. It's just another example of a message in that Live Share protocol that understands how to remote search. Beyond that, then you start to say, well, what if you're installing a bunch of extensions? How should I expect those to work?

In a way, there's two classes of extensions in the VS Code marketplace. There are ones that contribute language support for core features, so let's say auto-competition, go-to definition, things that VS Code already supports. It's just getting plugged in to support Rust or whatnot. Even that will automatically just work with Live Share.

Then you have a set of extensions that kind of contribute unique or new UI or concepts to VS Code that are not built in. A good example is GitLens, one of the most popular extensions, where it has its own tab.

Chris: Love that. It's so good.

Jonathan: What we've done is, Live Share, in a way, it is a product, but it's also a platform for collaboration. We have an API that other extensions can use to make their own unique experience totally collaborative as well. GitLens is fully Live Share enabled so, if Dave had GitLens installed, the guest would be able to go use GitLens and do arbitrary queries and explore commit history as if that repo was local but it's obviously not.

Then we have extensions that have contributed, like real-time whiteboards or shared Pomodoro Timer. There's an integrated browser extension that adds an embedded Chrome into VS Code that is fully collaborative over Live Share. As one participant scrolls or clicks, it does that for everybody.

The kind of metapoint to that is, on one side, we're working to kind of make as much of VS Code and the ecosystem just work out of the box because it's really important that the workflows and the tools they're used to using in their day-to-day also work as part of collaboration. Then we're also working with the community to go and explore ways to augment Live Share entirely with new experiences, which we're pretty excited about.

One thing that we're working on right now is the shared server feature that we just showed obviously makes it such that you kind of have a complete dev loop for Web apps or APIs. But if you were working on a desktop application, then currently there wouldn't be a way for the guest to be able to see that, and so we are actually working on a feature. Let's say you're building an Electron app, a VS Code extension, or a mobile app that you need to run in an emulator that you can actually share the window for that desktop app and that would automatically be shared with all guests in the session as well. Kind of a little embedded -- not a screen sharing stack in that we wouldn't be sharing a screen but sharing the pixels of a window in order to unblock use cases where it's a browser delivered application and it really does need to be streamed, basically, as pixels, which is cool. You could imagine somebody could be on Linux debugging a Windows desktop application without having to set anything up at all.

Chris: Yeah.

Jonathan: We're currently trying to explore ways to remove barriers. That said, obviously we're very focused on collaboration that is centered around the editor experience and things that can complement it. There will always be tools that are external to VS Code that certain workflows might necessitate and, for those, screen sharing might be more appropriate, but we think that we can reduce that gap quite a bit by working with extensions and then this ability to share arbitrary windows as well.

Chris: Yeah. Pretty rad. That unlocks a lot of stuff if you're looking at pixels and stuff.

Jonathan: Yeah. Yeah, we think so. Yeah.

Dave: This is cool. I guess the last thing is, is this something everyone should install? Do you see this as something everyone is going to use?

Chris: Well, it's free, right? That's one thing I didn't even ask. It seems free now. Is it going to stay free? Stuff like that fascinates me. Microsoft is big.

Jonathan: Yeah.

Chris: So, … give away stuff because it helps the larger whole in some abstract way or are we going to start seeing pricing models?

Jonathan: Yeah, I mean everything about Live Share that exists today, including integrated audio, chat, and screen sharing that I talked about that's coming, is and will remain free. I think, from just a transparency perspective and "What's the point?" kind of question you were maybe asking, I think we absolutely believe there are capabilities that are more relevant and beneficial to organizations than developers that we expect to work on in the near future and those might come with them, an associated billing model, but we very much are committed and wanting to make it such that Live Share -- our broad aspiration is that it could become the way that developers collaborate in real-time. In order for that to reach the breadth of scenarios that we want--whether it's education, online communities and mentoring, freelance markets like you mentioned paying somebody to help you--it's just critical that it's a free product so that the barrier of entry is as low as possible.

Chris: That's nice to hear. That's great. I think it's the slight entrepreneur in me that I'm always, like, dreaming of alternate realities in which I make money through different things like that.

Jonathan: Yeah.

Chris: Maybe I'll be the first VS Code Live Share super teacher. Hire me and I'll fix your Web app.

Jonathan: Yeah.

Dave: Yeah.

Chris: $1000 an hour, Dave.

Dave: All right.

Jonathan: Yeah.

Chris: [Laughter]

Dave: In your stable of -- [Laughter]

Jonathan: You know, as we've built the product, we have heard that idea come up many, many times and so I'm just kind of waiting for somebody to go do it. Totally, as an aside, as a hackathon project because Microsoft, every year, does a big hackathon, this year some of the folks on the Live Share team built an extension that augments Live Share, which is called Live Share communities. In a way, you see Live Share has this concept of your contacts and so it tracks who you've collaborated with and it'll suggest people that are contributors to the repo that you have open.

But I'm really interested in exploring this way for you to opt in to joining a community, which could be anything like React JS or CodePen or this classroom or a hackathon team. Once you've opted in to joining the community then, within VS Code, you can discover people in that same community. You can make help requests. You can broadcast your work like a Twitch stream. People can discover you.

Then, on top of that, you could imagine communities where it's basically a premium experience where you can seek out help but there is an expectation that you're going to pay people if they help you, much like many of these freelance markets today. We're definitely interested in exploring that and seeing what people are interested in doing, yeah, so we think there are still a lot of interesting areas of exploration in the space of collaboration.

Chris: There absolutely is. For now, let's just get really good at pair programming people. It's good stuff. I'm telling you.

Dave: Oh, I think -- yeah.

Chris: Everybody writes better code.

Dave: That immediate benefit is so tangible here, just that you can write better together. I think that's a good place to end on. Jonathan, thank you so much for coming on the show. For people who aren't following you and giving you money, how can they do that?

Jonathan: Yeah, I'm @LostInTangent on Twitter and GitHub. Those are probably the best places to ping me and kind of stay up to date with Live Share if folks are interested.

Dave: All right.

Jonathan: I try to be as active as possible with folks using it.

Dave: Awesome. Thank you so much for coming on.

Chris: Yeah. I'll echo that. Thanks a lot. Very cool.

Dave: It is very cool to kind of explore this new frontier of code editing. I know there have been SubEthaEdit and all those things in the way, way past, but this seems like the first, like, "Okay, it's kind of working now pretty well," so I'm pretty excited to try it out in my company.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. And, Chris, do you have anything else you'd like to say?

Chris: ShopTalkShow.com.