This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Wade Anderson and Ramya Rao from the Visual Studio Code Team at Microsoft. Tune in and learn more about what’s new with Visual Studio Code!

Ramya Rao and Wade Anderson are in the Visual Studio Code Team at Microsoft.

Our vision on Visual Studio Code is to take what was best out of the IDE world (Visual Studio, Eclipse, IntelliJ, etc.) and bring what was best from the lightweight editor world (Sublime Text, Notepad++, Atom) and merge those two together. We wanted the lightweight features from text editors and the debugging capabilities of Visual Studio and Eclipse. We did general availability last year. We’ve been stable for a year. Additionally, this is Visual Studio Code for Mac, Windows, or Linux. It’s also built in Electron.

Wade’s title is a Program Manager. He does more non-developer things but Ramya is an engineer on the team so she gets a lot more coding that Wade does. Everybody has a key area to own but nothing stops them to go into another area. We try to share knowledge between people but we always have that one key owner that you always go to.

Ramya is a recent addition to the team. She started out maintaining the Go extension, maintaining and adding features. She’s slowly branching out to the Emmet features of the product.

Emmet, or Zen Coding, is a must-have tool for you. You can write, say abbreviations and that expands to really huge HTML to update tags, rename tags, etc. That is one of the features of Emmet and Sergey actually wrote the library. We have an in built integration in the product. I [Ramya] am currently working on that.

In that case, we have a multi-cursor software in Visual Studio Code, as well. You could place your cursor in different positions, and then, simultaneously edit things.

Right now, it’s in Built. If you want to know more about Emmet features, you can to emmet.io. That has all the documentation that you need to learn about Emmet features. In Visual Studio Code right now, we’re looking at making into an extension. We pull it out of the main code and maybe more people can contribute and make it even more better.

One of our main pillars for this year is to improve performance of the product. We’ve grown a larger team so we’re adding a lot more features every month. Last few months has been, “How can we get some stability on the issues coming in while making sure we’re reducing our tech load?” We really keep to those core principles that we started with at the beginning, which was, we want a fast, lightweight editor.

We built a few extensions that we call key map extensions. They are just a mapping of key bindings that you learned in Sublime Text. You don’t have to re-learn any key bindings in Visual Studio Code.

We also build this Welcome page where you can flip through and see features really briefly. In that Welcome page, one of the key things is an interactive playground where you can play with existing code in different sections. Additionally, as we’ve mentioned, we also put multi-cursor features.

Another thing is workbench naming. You can change the theme of Visual Studio Code but it will be restricted to the editor and not the rest of the workbench.

Daniel’s another engineer that’s here with us today. He was the largest contributor to the Xterm.js project. He built the integrated terminal for Visual Studio code so I can’t speak to the internals of how that works.

That’s actually where we started. We were Monaco editor where you get this cloud-based editing experience. We’re getting people to use it but we’re only getting people who were already using Microsoft products.  When electron came out, we saw an opportunity of, “Hey, can we port this  Monaco editor to Electron and we could then, run it on Mac and Linux.”

One thing that we did recently was adding an ability to calculate the start time for Visual Studio Code? That’s one of our full steps to get more information from the user-side. How can you get a profile of what things are running? Which part of the process took much time?

We also need to identify what are the things people are doing that’s causing the editor slow down. An example is when you open a large file and things get laggy.

Another exercise we did was we looked at all of our extension API’s to see which one of those could be a malicious extension.

The difference between VS Code and Atom is that, we ask questions like, “Are we using good data structures? Are we managing our memory properly? Are we removing stuff we don’t need anymore?” That just comes down to all those little things you learn from basic textbooks that have been around for decades about how to write good code. That’s what we have been doing and that’s what we’ll continue to try to do, to try and improve the performance.

We definitely don’t load everything at once. Different parts of the editor is loaded differently. When you do the Require, we don’t do it at first load. We do it when we notice that the user wants to use Emmet. We don’t try to load all the library at the beginning and delay the whole process.

We try to lazy load as much as possible, even the extensions. We have a separate process called extension host that takes care of loading all the extensions. Whether the extensions are completed loading or not, that does not stop you from typing in a file. Simple actions shouldn’t be bugged down by fancy actions.

Every month, when we plan our iteration, we create iteration draft plan. We put it out there for people to see. Performance and helping people get started are probably the top two for us. You can look at github.com/Microsoft/vscode, look for the label ‘iteration plan draft.’ So that’s the current work that we’re doing that month.

Another feature is the multi-root workspace where you can open multiple folders. When you look at the issues and sort by most comments, multi-root is the number one. The second one that is little paper cuts around formatting and auto-intending – just things that make your code prettier.

Special Guests: Ramya Rao and Wade Anderson.