Check out allremoteconfs.com to get in on all the conference action this year -- from the comfort of your own home!

 

On YouTube
199 JSJ Visual Studio Code with Chris Dias and Erich Gamma

02:13 - Chris Dias Introduction

02:21 - Erich Gamma Introduction

02:31 - Visual Studio Code

03:49 - Built on Electron

04:25 - Why another tool?

08:12 - Code Folding

09:00 - Will people move from Visual Studio to Visual Studio Code?

12:06 - Language Support

18:06 - Visual Studio Code and Microsoft Goals

22:47 - Community Support and Building Extensions

28:31 - The Choice to Use Electron

32:41 - Getting VS Code to Work on the Command Line

35:02 - Tabs

38:49 - Visual Studio Code Uptake and Adoption

40:11 - Licenses

44:46 - Designing a UX for Developers

58:15 - Design Patterns

Picks

LEGO Star Wars: The Force Awakens Video Game - Announce Teaser Trailer (Joe)
Firebase (Joe)
Progress bar noticeably slows down npm install: Issue #11283 (Jamison)
Darkest Dungeon (Jamison)
Trek Glowacki Twitter Thread (Jamison)
Mogo Portable Seat (Chuck)
Clear Acrylic Wall Mountable 10 Slot Dry Erase Marker & Eraser Holder Organizer Rack (Chuck)
Bitmap Graphics SIGGRAPH'84 Course Notes (Erich)
Salsa (Chris)
The Microsoft Band (Chris)
Making a Murderer (Chris)

Special Guests: Chris Dias and Erich Gamma .

 [This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth, and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]

Hey everybody and welcome to episode 199 of the JavaScript Jabber Show. This week on our panel we have Joe Eames.

Hey everybody.

Dave Smith.

Hello.

I'm Charles Max Wood from DevChat.tv. Quick shout-out for Freelance Remote Conf and React Remote Conf coming up this month and in May. So, if you're interested go check those out. AllRemoteConfs.com.

We also have two special guests. We have Chris Dias.

Hello.

And Erich Gamma.

Hi.

Do you gentlemen want to introduce yourselves?

Sure, I'll go first. My name is Chris Dias. I am a Program Manager on the Visual Studio Code team here in Redmond.

And I'm Erich Gamma and I'm leading the development team working out of the lab in Zürich working on Visual Studio Code.

Alright. Well, do you want to give us a brief overview of what Visual Studio code is? I think most people in the .NET community and in other programming communities have some idea what Visual

Studio is. But this is a bit different, isn't it?

Yeah. I think it is. I think... I can sort of give you the overview of what it is. Visual Studio Code is, we kind of think of it as, we call it code editing redefined, or a code editor redefined. Visual Studio, if you think of that product as the base of the conversation, it's an IDE. It's been around for a number of years. It has a tremendous amount of functionality and power associated with it. But there are also other tools that people use out in the real world today. There's a set of developers that like using just plain text editors and code editors. And Visual Studio Code is our entry into the code editor space in the family of developer tools that are out there. And so, it's decidedly more lightweight. It has automatic update. There are no tool windows, there's no window docking, things like that. It is very much a keyboard-oriented coding experience. And the other interesting thing about it is that it runs cross-platform. So, Mac, Linux, Windows, wherever you are Visual Studio Code will be there.

Very cool. We did...

And it's open source and extensible.

Yeah, we did an episode a while back on Electron. And my understanding is that's what it's built on.

That's correct. It builds on the Electron platform. But people often confuse it by thinking we build on Electron plus Atom. But really we build on Electron. And everything on top is freshly custom-made code from us, which has quite some interesting history because we started actually building an editor which is an online editor that runs in a browser. And then over time we moved to Electron to make it also available as a desktop application.

So, are you trying to break in the middle of the Emacs versus vi fight?

Well, I don't think we're trying to break into any fights.

I guess that's my roundabout way of saying there are so many other tools out there. Why another one?

Well, I think of it as... so, the tools are all very, they all have a long history. And what we decided to do was to try to bring some of the great experiences. We call it the core inter-developer loop, the core edit-compile-debug experience that is typically found in IDEs or more heavyweight tools. Bring that down to the editor space but in a lightweight, pluggable, and as Erich said open fashion.

So, out of the box you get a lot of the great functionality that you would expect in an IDE but you get it in an editor package. So, great language syntax colorization, IntelliSense, and with a couple of extensions you get end-to-end debugging experiences. And throughout all of that, not forcing you into another tool where we actually make it a big principle of the tool, is so that it has loose coupling with existing tool chains. And so, you can shell out to your existing Gulp or make or cmake or whatever other tools that you have. You can use those with the tool. You don't have to drop everything and come into this. So, if you're an editor guy and you want an out of the box better code editing experience then we're giving you your editor experience, keyboard focus, plus great IntelliSense, code navigation, understanding and debugging experiences “out of the proverbial box” even though there is no box.

So, since you mentioned the fight, right? There are these two ends of the spectrum: the editor and the IDE. And actually, we love them both. So, we like the editor, fast startup, keyboard navigation, support open for any tool with the command line. But all the things from the IDE we love like [preset], IntelliSense, debugging. And we'd like to find a place for Visual Studio Code which is kind of in the middle and hitting the sweet spot that we don't lose the fastness of the editor but we still get the things we love from IDEs.

That makes sense. I'll admit, most of the time I'm doing Ruby, a lot of the time I'm doing JavaScript. And my preferred weapon of choice is Emacs. But sometimes I just want that debugger in there. And the command line debuggers work some of the time but not all of the time. So, having a visual debugger is really handy. So, I definitely see both ends of the spectrum and by getting a happy medium so to speak, it seems like a nice place to be. Does it support the key bindings for vim or

Emacs?

So, there is an extension, a vim extension, which is pretty popular, which is work in progress, which supports the vim key bindings. I'm not aware of an Emacs one.

Well, that's too bad. [Chuckles]

Well you know, it's extensible. You can easily write one and publish it to our store, our gallery.

Oh, I hear what you did there.

Wasn't vim one of the most requested features for VS Code? [Inaudible]

It's a popular one, but if you look at, Chris you maybe have the ranking better in memory, but I think on the top we have another one. Right, Chris?

Yes. The current most requested feature is code folding. The vim key bindings is, it's in the top 10. I can't remember what it is off the top of my head. I'll look it up here. Get it to you in a minute.

Chris mentioned code folding. So, the good news is we just started it actually. We do monthly sprints and we're just starting this sprint on code folding.

Can you guys talk about code folding and what it is, for those who don't know?

I was about to say cold fusion, you don't have to talk about that. [Laughter]

No, I want to hear about that, too.

I want them to talk about that promise that I just heard that it's going to be out in a week.

Did not say, who said that? We do monthly iterations. [Inaudible]

I know. I'm just putting words in your mouth.

Yeah, yeah. Some features take a longer iteration. So, code folding. Well, the idea is the little [inaudible] on the left that allow you to expand and collapse ranges of code so that if you have a large file you can collapse things you don't want to work with. And yeah, it's actually a pretty old feature which Visual Studio introduced I think 10 years ago and it's now almost... people expect it in editors today. So, we want to fulfill this expectation.

So, is there some concern then that Visual Studio Code might, I don't know, people might move off of Visual Studio, which is a paid product from Microsoft, onto Visual Studio Code which is free?

I don't know if it's a concern. Visual Studio has so many features in it. And it really is the Cadillac of development tools. I think that what we're seeing is that there's a place in a lot of people's toolboxes for a lightweight, fast editor as well as a rich IDE. So, there are some times when you just want to go in and tweak a file and you want the IntelliSense there but you don't need to load everything else up. Having Visual Studio Code is very handy. And Visual Studio itself, the community edition is very much full-featured and very much free as well.

So really, our focus right now is more about just trying to reach a set of developers that we haven't been able to talk to with Visual Studio as it exists today. It's definitely a Windows-based tool. And there are a lot of folks out there who are on the Mac and on Linux that we don't have an offering for. So, now we can have something for them which brings them those rich experiences from VS into where they are instead of saying, “Hey, you know what? If you want to have these great experiences you have to come over to Visual Studio.” Instead we're going where the developer is.

And what we're also observing, developers today, not all of them are folks on a single tool. They use and IDE, they use an editor on the side. So, it's not just one or the other. It's just completing a toolbox and adding another tool to the toolbox which is a lightweight editor.

Yeah, on that point, one of the big things that we look at and trying to do is instead of... if you think of Visual Studio as an IDE, an integrated development environment, we think of Visual Studio Code being integrated not at the UI perspective but more like at the file system or the asset level. And so, with VS Code you should be able to go in and you can edit your C# project. You can go add a file to it. And a lot of this comes from the platform as well. But you don't have to manage project files or solution files or anything like that. And what we really want to do is make it so that it's easy for you to move between these tools without having to be in a particular tool to get all the magic that goes behind the scenes. So, you'll see more and more of that stuff happen on the Visual Studio side as well as on the VS Code side. But again, it's to help people as they do move between tools. If it's a file that's on disk, then pretty much any tool can open and edit it. And that's where we try to focus.

And of course we just maybe don't, we ignore this additional information about the project, but we kind of discover it, right? You just open a folder and then basically the language extension, they discover additional metadata to enrich the experience, like when you do TypeScript or JavaScript development. There is a file, a config file which describes your projects. Which files are in there, which compiler options you use. And we discover them. And once we discover them, we give you a richer experience. It's really kind of this graceful, not degradation, but upgrade. The more we know about the project, the richer experience we can give.

So, you mentioned TypeScript and JavaScript and some of these other languages. What language support do you have?

So, okay that's kind of, since we're extensible right, it's kind of, we'd have to go to the gallery. There are some languages which come bundled with Code and which is something which we make sure are high quality like for TypeScript and JavaScript, CSS, Sass, JSON, for all these we have rich languages, which means IntelliSense will understand the language. We can validate it. We can make new IntelliSense proposals, completion proposals. So, we have those. Then we have a whole long tail of languages for which we only support coloring. And what's cool is now that we see the community contributing additional languages. So, there is an extension for Rust, for Python, for Ruby. I'm not sure whether it goes deep. And it's now an ecosystem of languages.

And what we try to do is we try to give extension writers a toolkit to write a rich language experience. So, things that are in this toolkit are for instance an IntelliSense widget. A peek experience right, so that when you want to see the definition of a symbol you can look at it in place. So, we give this toolbox and the ideas then when someone adds a language and teaches Code a new language, they leverage this toolkit to get a rich experience and moreover a consistent experience across all the languages.

I think it's important to...

Did I mention C#, Chris? Did I mention C#?

No, you didn't. But now you did. [Laughter]

But I think the other interesting aspect of that is the toolbox that Erich talks about is the exact same toolbox that we use for... on the built-in language services, so TypeScript and JavaScript. It's the same set of APIs that are being used for what we have built into the tool that other extensions can then take advantage of. And we build these language services that are in the tool as extensions themselves. One other one that has been very popular that does a good job demonstrating the end-to-end capabilities that an extension can offer up is the Go language service which has text colorization, IntelliSense validation, even debugging. But it's pulling in all of the Go platform tools that exist out there and then surfacing that data and that experience in the VS Code UI.

Did you guys mention Elm?

What's that? [Laughter]

Careful, Chuck.

Which is cool. [Inaudible] have a pretty cool Elm extension, actually.

It's just this obscure thing that nobody wants to use.

There are 107 votes for that on UserVoice.

In UserVoice? But I think I saw Elm. Come on.

Yeah, there's an extension. I just installed it just to see.

Oh, okay. Is it a deep one? Does it give you IntelliSense? Or is it more the coloring level?

I guess I'd have to know how to write Elm code to do that. [Chuckles] I don't know.

Okay, I see.

I can't tell.

[What you make] very easy, the first level is syntax highlighting and snippets. And the next level, that needs to really parse and understand the language and have a service for that. And what's interesting for that, this kind of language [brain] that you build for a language, we run them in a separate process from VS Code. VS Code, there you are, you're writing JavaScript. But when you want to integrate your favorite language then often you already have [language] infrastructure written in that language, like the OmniSharp language brain is implemented in C#. So, we have... one of our architectural principles is that we can run these expensive language brains in a separate process and you can then integrate them seamlessly using this language toolkit into Visual Studio Code.

Oh, I got you. So, since Ruby already has features that know how to parse Ruby, you just hook that in and it runs it in a separate process in Ruby?

Yes. Right, [inaudible] Ruby, you talk some IPC protocol, RPC style, and you write the integration code in JavaScript to glue it to adapt it to this language toolkit. But the rest you can reuse, which has also the nice characteristic, this language brain you wrote in a separate process works with different editors. It's not a lock-in

Mm.

Yeah.

So, you mentioned C#. I don't know if you've kind of been talking through this, but what's it like to author in C# in an editor like this versus in an IDE where you actually have the typical, “Ah, when I'm done I hit this little button and everything compiles then I go and run”? What's the difference in something like that?

Well, hopefully at the end of the day it's not that different [chuckles]. From a build and compile standpoint, we do have debugging built into VS Code. And debugging for managed code is certainly on its way here. And so, as you're writing code you're constantly getting feedback and it's constantly letting you know when you have errors and warnings so that you can just press F5 and then run your application. If you want to do something like invoke make or sorry, MSBuild on it, then you can set it up basically as a task or a command that runs from the command palette. And much the same way that you basically do in Visual Studio but instead of invoking the build menu, you can just invoke it from the command palette.

So, all that core, I called it before the inner loop, the edit-compile-debug loop, is there, will be there shortly for managed code. The key bindings might be going to the command palette instead of the menu system. There's no buttons obviously for a lot of things. But that whole flow is actually still there.

No [wizards]. Maybe Chris there is no built-in wizards, right?

Right, right.

So, what's the ultimate goal with Visual Studio Code? Is it just to bridge that gap? Or are you hoping to open up coding to more people? Or is there some loftier goal with this or is it just to make an awesome tool?

Well, I think the ultimate goal is really to be able to have an offering for more people than we can offer to today. So, we have a cross-platform offering that great experience from Visual Studio where there's a whole class of folks that couldn't use Visual Studio before. So, we're trying to make the tooling and the great tooling from Visual Studio, from IDEs available to more and more developers.

And so, we actually did quite a few interviews with folks that don't run on Windows. Either they were on Windows or they run on the Mac or it's been a long time since they've been on Windows. We asked them what they want and what they think about Visual Studio. And the key things that they always bring up are the great editing and debugging experiences. And so, we felt like if we could bring those to more developers then that's a great development experience for more folks out there that could benefit from what we've built over the past 15 or 20 years with VS. And so, like I said, the ultimate goal is to be able to just provide a larger set of developers with a better experience than they have today.

Yeah, I also want to point out that I think when we started this show Microsoft was the butt of about half of the jokes on the show. And Microsoft has done so many interesting and awesome things that we just don't do that anymore. And to hear you talk about this is just another way that Microsoft is making coding better for people. And it's just cool.

At the fundamental level, that's what we're trying to do, is just provide a better coding experience for more folks. And then that opens up doors, right? You can have conversations with people. Maybe they're more likely to go and try something else from us. Maybe not, but what we've done is we've sort of elevated the quality of development and just made generally developer's lives better. And so, eliminating that negative perception of Microsoft that's been out there for so long is a good thing. It's a good thing for everybody. And so, it's actually, it's quite fun to have that be your objective.

So just now you hinted at a couple of motivations for Visual Studio Code. One was maybe getting people to try other Microsoft products and the other was basically I'll call it marketing where you're trying to get people to have a good impression of Microsoft. Does that sum up why Microsoft is investing in this or is there more to it?

I guess Microsoft wants to be relevant to developers on any platform. You can call this marketing but to me it's kind of, you're in this space and you want to be relevant, right? And that's an investment you have to do because the worst thing that can happen as a company that [inaudible] tool, you become irrelevant to the developers. So for us, it's a very serious investment. It's not marketing. You want to be relevant to developers. And that's kind of the way to do it, is with a tool that developers love. That's what I want to do. I want to build a tool that developers love.

That's cool. So, how many people are working on VS Code in Microsoft right now?

So, there is my team in Zürich. We are nine. We are kind of the core development team. And then in Redmond we have Chris as the PM that is with us since the beginning. Then we have now I guess, well one PM is on sabbatical. We have another PM that started a month ago. And we have also one developer that helps us with the whole data insights. Telemetry, data collection, and so on. But that's just the core. What you see is that now other teams in Microsoft build extensions on top of Visual Studio Code like the Cordova extension became available. There is a team that builds the C# debugger. There is, so now Chris had enough time to think about it, right? [Chuckles] What else is there?

GDB debugger.

C++, C, [inaudible].

I saw some IoT things being built. Lots of folks doing SQL type packages for it. So, across the board there are a number of teams at Microsoft that now have VS Code as a target to build an extension for to broaden their availability as well. So, it's hard to put a number on.

Yeah. This, the whole ecosystem is at Microsoft. But I think what's important is through the development of the core which is through your code, you are always a very small team. The development team in Zürich with the help of the PMs in Redmond, right?

Mmhmm. I'm curious. What features do you keep for the core team to work on versus things that you leave open for extensions from other groups, be them internal to Microsoft or community members?

So, that's a very good question. So, to me it's an evolution. So for us, it was very clear in the beginning, we have to show... think of this, we're a small team. You can think of us like a startup, right? We have to show this technology. Of course we do lots of stuff. We owned many languages. We still own some of them but we own C# for instance. But as you move on, the plan is now that some of these core languages get taken out from us because with a team of eight developers you cannot scale up.

Right.

Right? So, that's why I moved to this protocol-based approach which makes it easy that other teams can contribute. You have an extension API. And what you want to keep is the core platform. The core platform means the editor, the extension infrastructure, the API. And the tools which we use to build VS Code itself. That was one way, how we defined the boundary. So, we want to own the extension builder experience end-to-end. But over time, we will... we are more than happy now that we have this extension API, other teams to contribute so that we can still be a small, lean team. We don't want to double the core team. We want to keep it lean so that we have this integrity and the preserved integrity that we are kind of proud of these days, today.

Just the history, we started on that four and a half years ago. Initially focused just on editor, then we made different experiments where we can use it. We always find partners  that used it. Like [inaudible] used it early on, [inaudible] online used it early on. And then we also had an online IDE experience for editing actual website. And then we kind of pivoted a year ago to where it's a desktop experience leveraging Electron.

That's interesting. That's quite the history.

It's a really fun journey, yeah. And initially we started with only JavaScript then TypeScript came along. We were one of the first adopters. And wow, this rocks. Helps us to grow the code, so we migrated everything to TypeScript. So, we're now still one of the larger TypeScript applications with 300,000 lines of TypeScript code.

Oh, wow.

Yeah.

So, somebody decides, “Alright. I have to have an extension that adds random quotes to the code in comments.” And they think that this is the next big brilliant idea. How do they go about building that extension?

So, the nice thing is, we have the tool to write the extension with VS Code itself. You need a little generator, Yeoman, which is an open source scaffolding tool. You do an npm install the Yeoman generator and generate a template, open the editor, press F5, and you can start to explore out API using IntelliSense you provide for the API. And to debug your extension within five minutes, right?

This was our goal. And, yeah.

You make it sound so easy.

[Chuckles] The starting, getting started, I think we really tried to make it easy. The API is kind of clean. I can elaborate why we ended up with a clean API. And yes, it's an API but you have to learn it. And you have a choice whether you want to write your extension in TypeScript or JavaScript. We provide IntelliSense for both languages off the API. And feedback from people is that they could get started quickly. So, that's what made us really happy when we got this feedback, when it all was announced last November. And that might explain why we by now have a nice number of extensions in our marketplace.

So, on the API story, what's interesting there is we really care about startup performance. And also, we think of if you want to be really successful you have lots of extensions. And we also said no matter how many extensions we have, no matter what the extensions do, we want to always start fast. And will always allow that a user can save its file. There's nothing worse than installing an extension, all of a sudden you can no longer save your file. You lose your work. So, what we do is we have this isolation idea. We run extensions in a separate process, which is a Node process which runs separate.

And then basically we have the core which uses some IPC to talk to the extensions, which allows us to define it, control the API 100%. There is no such thing as an internal method you can reach because there's a process boundary in between other protocol. This allows us to, from the ground up, to define an API which should be consistent and easy to use. And also, we isolated the core from extensions, which gives us really some security. We can preserve startup and a user can always say, to be honest you didn't simplify the architectural because you have to... process boundary in between, you have to [inaudible]. But I think it has really paid off. So for instance, we don't expose the DOM which is the whole Electron idea, right? You write your UI using HTML plus Node. We don't expose the DOM to the extenders, because we have controlled extensibility.

I'd like ask what it was that drove you to choose. I know that you talked about the history. Maybe it was just like one of those things that you just went into. But the choice to use Electron to develop ES Code, can you talk a little bit more about the background of that choice?

So, what we saw is this desire to have a cross-platform tool, a smart editor that should run crossplatform. The first thing we tried is, “Can we just give them the tool in the browser?” And what we found is this is great, but if you want to really code [inaudible] by 24, you really care about performance and so on. So, the question for us was can we bring this browser-based experience which is tuned editor that runs cross-platform in a browser, can we allow them to break out of the browser jail and run as a desktop application? This was kind of purely made from running in the browser online to running on a desktop to really give the speed, no latency, offline experience to a developer who wants to [inaudible] by 24.

But online is great for something like playgrounds. You explore an API. You want to learn it. That's wonderful and we still support that using our editor component. And then at the point we kind of looked into what are the options? Of course HTML was given and JavaScript [inaudible] this codebase we had. Then we looked into what kind of frameworks exist. And at that point there was, what was the other one Chris? There was Electron and the one before that.

Node-Webkit? Is that what it was called?

I think it was called Node-Webkit, exactly. So, the first one is Node-Webkit then we started it and it was very clear, the community goes more with the Electron based one. So, we moved from NodeWebkit to Electron. And we now are on this journey since a year. We tried to contribute back by testing, giving bugs, and also helping with pull requests or whatever, whenever, wherever we can.

And so, what's your overall impression of Electron? How happy are you with it and what things... is there anything specifically you feel like it's missing?

I think the whole development, the community around Electron is great. If you look at the apps that are built, that are running on top of Electron, this shows there is a community of people buying into it. Node support is great, having a Node API. So our extensions, they are implemented, they can leverage the Node API which is great, right? It's just a great cross-platform API if you want to access files and processes and things like that. So, what's missing? So, what we are kind of working on right now is because we want to go to general availability. We have of course some quality obligations when it comes to accessibility and localization.

And there of course we are currently... have some challenges, how to interact with the native screen reader. Because some of the widgets we use are highly custom. So, all the widgets we use actually, they are custom built. They are virtual because they have to be large. The text widget is virtual which means you only have the visible range in the DOM. We do the same with the tree. Whenever you update things, it's as incremental as possible. In the tree, we do diffs, to compute differences and so on. So, this is very custom. But now comes the challenge. You want to provide accessibility. And how do you do that?

Because the screen readers don't like these custom things. So, that's kind of a challenge. And that's where we currently have to do some serious investment. How can we get [inaudible] accessibility screen reading support into Electron? And there was a code camp that together with GitHub on that. And some good work happened out of that. But there is much more work needed to really be able to ship a product with Electron which fulfills the accessibility needs that you want from a desktop application.

I kind of feel like...

[Inaudible] that Microsoft wants from a desktop application.

I kind of feel like we should have you guys on again another time to just talk about Electron. [Chuckles]

One of the things that I've really enjoyed about Visual Studio Code, VS Code, I've actually used it a ton. I really enjoyed how quick it was to get up and running with it. And I didn't feel like I really had to learn something new. But one of the things that I really ended up wanting was the ability to launch it from the command line. And on my Mac it took me a little bit of work of looking around to try to find somebody that had figured out how to get that to work on the command line.

Ah, yeah. So, on the Mac we can only document how to do it. We don't modify on your Bash profiles. But actually it's documented. So, we have, the getting started tells you how to edit your Bash profile. And on Windows we install the command line thing we add, the executable to your path. But we don't do that on the Mac and the Linux currently. That's correct, yeah. And that's [inaudible] pain. I agree. And it's on our backlog to improve that. In our defense, it's in the documentation. I'm sorry that you didn't find it. But it's understandable. You expect it just runs out of the box.

You know, it's been a while since I did it. But if I remember correctly I looked it up and found something. And maybe it was on your site, maybe it wasn't. Tried it and it didn't quite work and I had to fiddle around with something else. But it may have more to do with Mac.

Another thing that's maybe a little bit unique to me is I happen to use Bash on my Windows box. And so, that's my typical editor. And that's when I haven't figured out how to launch VS Code from the command line with.

Okay. Okay, so yeah. That's what I don't know, actually.

[Inaudible] you're there.

Come on. You don't know that off the top of your head?

That's got to be a super common use case. Everybody on Windows using a Bash shell, right? [Chuckles]

But it's on the Mac if you're running Bash. So, you could have just used the set up instructions for Mac OS X and add this function code, VS code, current [working] directories, 'equals dollar P-W-D open minus N minus B'... [Inaudible] the bundle [inaudible] I-C. [Laughter]

Got it.

That's the bundle [inaudible]. Yeah.

Ah, okay.

Got it. Okay, it's all in.

Ah yeah. Okay. [Laughter]

It's Mac-specific, yeah. It's still Bash, yeah. So do IDEs have to do that, right? On first launch, we ask you, should you update your update your Bash profile? Sync like that? But we just didn't get to that yet, yeah.

One small question I'd like to ask is, unlike say Sublime Text VS Code doesn't use a tabbed interface. It's not like tabs are not an editor paradigm. Obviously, vim doesn't use tabs but Sublime does.

Oh, vim doesn't? Okay. I don't know. I bet you're right.

You can use tabs in vim.

Can you?

You can use, okay... Let me start with that... [Chuckles]

Chris, [inaudible].

You can put any word in place of tabs and it would be true of vim. [Laughter]

Real editors use buffers. Just saying.

Buffers.

You can use buffers in vim, too.

You can use Emacs in vim just so you know, Chuck. [Laughter]

These days we call them text documents, right? [Inaudible]. [Laughter]

Because we're open to different media in the future, maybe. But the history is we started in the browser and we were really aggressive [inaudible]. And when you run in the browser, the browser already has tabs. So, one of the things you told us, you don't want to have tabs in tabs. So, that's why we started with a tab-free experience and started to tune it as much as possible. That was one thing. The other thing, we have quite some experience with other IDEs and there is this word, this ugly word, like tab hell. I guess everybody knows what this is, right? If you have hundreds of files open and the tabs show you one letter and three dots and so on. And you want to avoid that.

So, we have a highly-tuned tab-free experience. And we now get the feedback, what about adding tabs? So, there are two approaches to that. We want to find out what is missing from the current one because we think tab hell is not a good thing. But we understand the need. Some people are used to access their working files and have a visual representation. So, we are kind of working right now on these. But if you look at the history, we want to avoid tab hell. And we use it, dogfood it since for years highly-tuned and we really love it. And we try to convince [chuckles] many others that it can be very fast without tabs and without having to manage tabs. That's the whole point. You don't want to manage these tabs, open/close, because 90% of the time I open a file just because I want to read it. I don't to manage it. I want to quickly look something up. But I don't want to manage a tab just because I look at a file.

I feel like every time there's another tab...

Oh, [inaudible]. So Chris, you maybe do the middle ground, right?

No, I like your statements. [Laughter]

That's exactly how it's progressed. And we still have ideas for tweaking the existing model. It's not perfect. We do think there's quite a bit of merit there in the experience that we've got right now.

Jamison, what were you going to say?

I was just going to say every time I use a tabbed editor I feel like every open tab is an item on a todo list. And it just stresses me out.

I love that. An item on a to-do list. Yeah, that's why it feels like tab hell, right?

Yeah, yeah. I don't want a to-do list. I want to get stuff done. I don't want to clean up after my tabs as part of my workflow.

I'll just give you my to-do list after I check everything off.

Great.

I will say, I'm very used to tabs. And getting into VS Code and not having tabs, it didn't take me very long before I got used to not having tabs.

You can do tabs in vim but I don't know how. And that lack of knowledge made my life better. [Chuckles]

I have blissful ignorance.

Yeah, I can just say that as I use Emacs, it's really easy to pull up the list of open buffers and then you can just pick the file you want to be in.

That's the other aspect with the command palette. It's just a quick keyboard combination to cycle through basically what your working set of files is or get access to another one. And so, that's the flow that we really got into, was just using that model instead of having to manage the tabs.

So, I would say probably the most talented developer on my team use VS Code. And he...

Oh you do, huh?

No.

Definitely not.

That's was awesome.

Humble-brag.

Certainly not. And he's super excited about it. But do you have any kind of idea on what the uptake is like? How many people are using it? If they're coming from Visual Studio itself, or they're coming from other things, or stuff like that?

I think what we said at Connect, we have one million unique installs since last May.

Wow.

One million?

Yup.

Wow.

Unique installs, unique installs.

Yeah.

And since Connect, since November. And I don't have the last numbers in mind, but it went up. The curve goes steadily up.

We don't know what the overlap is between Visual Studio and Visual Studio Code users are. There's no... You don't have to login to Visual Studio Code so we can't correlate people between that. All we can do is sort of make inferences from number of users on Windows versus Mac and Linux. But we don't have any way to correlate those two together. Or if people are moving back and forth or if they're using both or what that behavior is.

And we also see Mac use and Linux use. So, it's definitely, we achieved the cross-platform goal. I think 30% are Mac or more.

So, I have a question. For those of us who are panelists on this podcast, can you guys give us a free license to VS Code? [Laughter]

Yes.

I think I already got one.

Did you really?

Yeah.

Nice.

You're on the secret inner core of panelists then.

You can have two licenses if you want.

Aw, you guys are just too generous.

Cha-ching.

We can give you an insider license and a stable license. [Laughter]

Actually, there is [inaudible] behind it and we just released that last night. We have kind of, we really love frequent updates and feedback on whatever we do. We do monthly things. And what we support now, we have kind of an insider product which is where you update more frequently, which gets out earlier. And we have a stable product which is kind of the stable one. And they can run side by side. This is why you can have two licenses if you want. But both are free. [Chuckles]

But the side by side development channel [inaudible] is really something we like, yeah.

Does Microsoft actually charge for anything it makes anymore? [Chuckles]

Office...

Windows is free. Yeah, I guess Office. But they charge me so little now. I think I spent a hundred bucks and got five installs.

They do have tons of enterprise contracts and stuff too, maybe.

Yeah.

Also I noticed that the VS Code license allows me to make one or more backup copies of the software for reinstalling it if I need to.

So, just keep that in mind, everybody.

Oh, that's good to know.

That's any number.

That's incredible.

Yeah, those are standard pre-release licenses.

That's awesome.

Is the intention, maybe you already said this, but is the intention for VS Code to be free forever?

We don't have any immediate plans for charging for it. It's kind of hard to go back and start charging for it. There may be extensions or experiences that over time we feel like have some amount of value where we could charge for it. But for VS Code itself, we have no intentions to put a dollar sign on it.

And you already see that some extensions which is [inaudible] not done by Microsoft, they charge for them. So, the core is free. And they charge for an extension. It's not Microsoft. Like you see, this is not an uncommon pattern, right? That extensions on top of a free platform get charged for.

Yeah, the extension is typically free. It's the service behind it that...

Yeah.

That you then pay for.

Sure, that makes sense.

Well, I've certainly loved having VS Code as an option. I really like Sublime as a simple text editor which I've used a lot. I'm not really a vi or vim, Emacs guy either. So, I really liked what it has offered and felt like they've done a great job. You guys have done a great job putting out an editor. I use it on both my platforms, Windows and Mac. And so far I've had really no complaints.

So, what languages do you use, code with?

Mostly JavaScript, TypeScript.

JavaScript. Yeah.

Yeah.

So, we did an exciting update for the insiders last night. We have this new TypeScript powered JavaScript which really beefs up the current JavaScript support. We have JSDoc support and more traditional like IntelliSense also if you use the prototype pattern to write classes and so on. So, please give it a try. I think that's pretty nice.

You know, I will say I did notice one thing. I upped my font size in VS Code to a higher font size. And it didn't... like the font size that it had listed didn't match up with the same exact font size in a different product. It was smaller or bigger. I can't remember. I think it was smaller. I had to put it to like 20 to give me what seemed like it was 16 in a different product. That's a weird complaint to make, but... [Chuckles]

Yeah.

[Chuckles] You font snob.

[Inaudible] rendering of course, the whole rendering is really done by Chrome. And that's very... we [inaudible] from that, too. But yeah, file an issue and we'll look into it.

So Joe, how was the kerning like. Was it pretty good?

[Laughs] It was the best kerning I'd had all day. I could say that.

Well, but we... one feature we support are ligatures, literatures. Come on, help me on that.

Ligature.

Ligatures.

I don't know how to say that word. I can't...

I don't know.

Ligatures. That's a new thing. And we got in a contribution that enables ligatures, that it can [inaudible] the greater equals as one glyph rendered. So that's if you have the right font, which is...

Every time I make a font snob joke I learn about some new term that I had no idea. [Laughter]

So, I wanted to ask a little bit about the experience of designing a UX for developers. Where do you come up with ideas and a goal for what you want the workflow to be? It seems like there are so many editors that, I mean you have the old ones that have been around forever. And then there's just an explosion of newer editors too, that there's just a lot of choice. Do you look at what's out there already and kind of pick the good things? Or do you have a set vision in your mind of what you're trying to achieve and just go for that?

We've been doing development for quite a while. The combined number of years of doing development in building development tools is pretty high. And so, a lot of the end-to-end experiences come from really our own usage and dogfooding of the tool. What works well for us in developing an extension or developing TypeScript applications or JavaScript applications, and really trying to fine-tune our own experiences of what comes out in the product itself.

And then the other thing that we do is when we do have different design experiences that we want to bring in, we spend a lot of time experimenting with the experience, trying it out, getting feedback, failing fast, both in the product and on paper and slides and just trying to see what kind of feedback we get. And then as we release an experience in the product, again looking at the telemetry data, looking at feedback on Twitter and on the forums and on Stack Overflow and on GitHub, and seeing if we have to go and tweak those experiences based on how people are using them. I think the thing that's interesting is that we're not fixated on, “Okay, this is how the experience must be.” And we don't try to paint and build a very monolithic end-to-end experience before we put something out there. We try to approach it in a very incremental fashion and tweak it and turn it. And if we have to revert it, go for something better, we'll go and do that. We're not afraid of rewriting a chunk of code for a better end-to-end experience.

So, it's a different kind of model. When you're delivering a tool every month, every three or four weeks, you just have to get in this mode of delivering a little bit by a little bit by a little bit. Having this sort of North Star, this is where we want to go, but getting feedback on it and trying things out and being willing to pivot when you get the feedback that says this isn't working, is the approach that we try to take. It's definitely different from building a large boxed software that maybe doesn't have automatic update. And we just have this luxury of being able to ship so frequently that we can do it and work in this fashion.

I think what Chris mentioned, this whole when you do developer tools you get this dogfooding thing. And we started actually I think four months of developing, we switched over to only use our tool. And since then what we do is we constantly tune it. We constantly improve it. Do we like the filtering in the quick open box? Do we tune? Since four years, it's constant tuning. And what really helps us also here is HTML technology. With HTML, you have so much more freedom when it comes to UI using CSS and using effects than with traditional widgets if you would have coded it all with a traditional UI toolkit. And I think this really helped us to explore things and then to do the constant tuning. And I think constant tuning, HTML as an infrastructure which allows to experiment with new UI things, really helped.

And then Chris mentioned what [Steven did]. There are interviews. We really get people in. We see them, how they use the tool, what is the startup experience? This is another good input to then further tune the thing. It's not only our own feedback that matters but also feedback from others.

And now we open source. We get a ton more feedback which we can track and [inaudible].

[Chuckles] For better or for worse?

Yes, the tabbing one you mentioned. That's a very passionate [bug], issue, issue.

Wow, a lot of plus ones on that.

Yes. These are the helpful, plus ones.

Yes, yes.

Yeah. But it's a really fun journey, yeah, given what we had. And we want to be proud of our tool. So, I want to be proud, show it to my friends, and that's to me the benchmark.

Yeah.

And the best compliment you heard, if someone said, tells the development team he loves it, that's what I live for. [Inaudible] spend most of my time these days reading GitHub issues.

Alright, well...

I'll make a GitHub issue that's just like, “You're awesome,” and then you can plus one it and close it. [Laughter]

Nice. Alright, well should we get to picks?

Oh, alright.

Alright Joe, what are your picks?

Alright. Well, my number one pick which I am super excited about today is February 2nd that we're recording and the trailer came out for Lego Star Wars: The Force Awakens.

Woohoo!

Yeah. If you haven't seen it, it's so dang hilarious. [Chuckles]

Super funny. It's like the same trailer that was for The Force Awakens, just done in Lego with their comedy thrown in. So funny. I love the Lego games. They're so much fun to play. I play them, some with my wife, some with my kids. And even though they're getting lower and lower scores every time a new game comes out because they're doing the same old thing, I love them because they are doing the same old thing. It's something that works. It's a super fun game, great comedy, and there's a ton of writing that goes into it to put in the right kind of comedy. Which I just think is great. And they're making the games incrementally better of course. But I'm a huge fan of Lego games and all the stuff that they've done. So, I'm really a big fan of this game. I'm excited for it. So, that'll be my first pick.

And then my second pick is going to be Firebase. I've been doing a bunch of work with Firebase recently. And I just love that product. I think it's a great product.

So, those are my picks.

Alright. Jamison, what are your picks?

I have three. The first is an issue on npm. It was an issue from people complaining about the speed of npm. And then Sam, I forgot how to say his name. I should [inaudible].

-wise Gamgee?

Yeah. Sam Saccone or something like that? I don't know. A famous JavaScript dude, he just jumped in and just dropped this super in-depth really well-documented performance analysis of what specifically the bug was and what was causing it. And he showed all these cool tools and all these awesome graphs from the Chrome Dev Tools in Node. And then turned it into like a tree graph of the calls. And it's just like a tour de force of how to debug performance problems in Node applications. And he was very nice and very helpful too. So, it wasn't like, “Here's how your crap is broken, jerks.” It was like, “I spent a lot of time to figure out how and this is how I figured it out and here's how you can figure it out, too.” So, that was cool.

My second pick is, I've picked this before but I'm picking it again. You can't stop me. It's a game called Darkest Dungeon. It's a turn-based dungeon crawl game that has a lot of Lovecraft elements in it. You take this team of adventurers through this dungeon and they all die. It's super hard. Your people die a lot. But it's just really well-done. The dialog and the art direction and just the... it just oozes style. It's really good. And it just came out of early access I think.

And my last pick is a Twitter thread from Trek. We've had him on the show once or twice. He's an Ember core team member. But he was talking about interviewing. Interviewing is my nerd passion topic that I just rant about sometimes. And he talked about how he followed people who they had interviewed and passed on and just seen how successful they had been in their careers after that. And it's just kind of like a little bit of interview nihilism that nothing matters and you can't know the truth of anything at all and life is hard. And then it turned into some good advice about how to interview better.

Those are my picks.

Alright. I've got a couple of picks. The first one is something I'm sitting on. It is a Mogo Portable Seat. It comes with a black cushion on it. You can get different colors. What it is, is I have this standing desk and I moved all my podcast equipment to it. I think I've mentioned that a few times. And on Tuesdays I record three podcasts. I'm actually trying to move Adventures in Angular over to Tuesdays so I can just get four of them done on Tuesdays. But because it's at a standing desk sometimes it gets a little bit long. And I didn't want to get a chair for my standing desk because I felt like it defeated the point.

So, what this is, is it has one leg. It's kind of a one-legged stool and the other two legs of the stool are your own legs. And so, I'm still standing up but I'm leaning on it, leaning back on it a little bit. And so, when I just get really worn down or if I've been running around because I wrecked my car and been trying to get it fixed [chuckles] like today, I'm pretty tired. And so, it's nice to be able to not have to just stand up the whole time. I can lean back on it a little bit. It's also good because I'm kind of trying to work up to the point where I can stand most of the day. But I don't know just how quickly I'll get to that. So yeah, I'm going to pick that.

And then one other thing that I'm going to pick, I have a whiteboard in my office. This is my home office. And I found online this really cool acrylic wall mountable rack holder for my whiteboard, for all the markers and eraser. And so, I'm really excited to get that all organized. I got my office mostly cleaned before we went down to my in-laws this weekend. And that'll be nice because then I can just pull them out of there instead of trying to figure out where I put them last.

So, I'll put links to both of those in the show notes. I got them both on Amazon. I also got my wife an Amazon Echo for her birthday. I'm not sure exactly how nice or not nice that is. But if you know anything about that, if you have any suggestions for it, shoot me an email, chuck@devchat.tv. And that way I can wow her even more after I give it to her.

So Chuck...

Uhuh?

If you get to where you can stand all day, is the next step to stand one-legged all day long?

That's right. And then no-legged?

[Chuckles] Yeah.

I'll just use the force and float.

Oh, I was thinking maybe you'd like hold onto a bar with one hand and just hang all day long, type with the other.

Well, that's how I code anyway.

And I eat a banana that I'm holding in my foot.

So, yeah. Could do.

Standing on your head and coding, maybe.

Oh, don't tempt me.

Alright. Erich, what are your picks?

So, in between GitHub issues reading, today I found a link to a very old paper which just made me happy. It's a technical memorandum on why Bit plate is so successful from 1984 from Rob Pike. Leo Guibas, Dan Ingalls, and Rob Pike, now behind Go. Dan Ingalls Smalltalk. It's just wonderful engineering. So, bit-plate, this was the time when you had no color. One bit deep bitmaps. And they show what you all can do with this universal operation to do character rendering, to do scrolling, to show a pop-up menu by bit-plating the background away. And then you plate it back in, how fast that is [inaudible]. This was to me a nice time warp. And I really enjoyed it. And I think sometimes you should just go back and read some of these old papers just to see how far we have gone when it comes to compositing and so on these days. That's my pick.

Cool. Chris, what are your picks?

Let's see. I think we talked about this a little bit, which I'm really excited about, is the Salsa. It's the codename of the TypeScript JavaScript language service that we're starting to adopt in VS Code. So, I'll send a link to that. It's really going to be fantastic. Another thing that we talked about is it has JSX support. So, it's all sorts of really cool things are in there. So, from a JavaScript and TypeScript language experience in VS Code, I'm super excited to see us picking that up.

The next thing is I just actually got, I'm sure people have talked about this in the past, but I just got myself the Microsoft Band. And it's interesting to be able to track your data day in and day out. I find it most interesting to see how well my sleeping is going and what has impact on my sleeping. I

don't sleep as well on the weekends. I don't know why. But that's pretty cool to be able to track that and see how the nights go.

And the last thing is I just binge-watched Making a Murderer. I don't know if you guys have watched that or if I'm way out of date. But it was 10 or 11 episodes which was quite a disturbing and saddening docu-series. But highly recommend it. Very interesting to watch.

I keep hearing about it but I haven't watched it.

It takes... you got to give the first couple episodes your time. And then it picks up speed.

Nice. One other thing I just want to mention, if you're in Europe, when this episode goes out I will be in Amsterdam. And I'm going to hold a meetup when this episode goes out. It goes out on a Wednesday. I'm holding the meetup that night. So, if you're interested, hop on the mailing list or shoot me an email or tweet at me and I'll let you know where we're going to be at in Amsterdam.

I'm going to be out there for the NG-NL conference. And I'm looking forward to meeting some folks.

I just want to note that no one picked 'Design Patterns' and that seems like a shame.

Are you just sick to death of everyone asking you about 'Design Patterns' when you talk about other stuff?

I say I still love them all. But I don't want to be reduced to 'Design Patterns'

Sure.

I love them like children but they've all moved out?

[Chuckles] It's really like that. You love all your children, right?

But yes, and then the whole JavaScript technology, it's so rich if you think of patterns. And if I wouldn't know how much work it is to write the book, it would be beautiful to do one. [Laughter]

So, someone else should do a JavaScript Design Patterns update, it sounds like.

Yeah. But thanks for the reminder.

In case you forgot. [Laughs]

I still need to get the first one. [Laughter]

I promise you, I will sign it once you buy it, Chris.

I know, I know. [Laughter]

It's too big to bring on the plane.

Yeah. [Chuckles]

Boy, if we keep talking about this, so will somebody's head. [Chuckles]

Alright. Well, thank you guys so much. It was a lot of fun to talk about. And hopefully, we'll get some people...

Thank you.

Interested in it.

Thanks for having us.

Thanks.

No problem.