Developer Focus

[00:00:00]
>> Mike North: Visual Studio Code is an open source project, and although the binaries are proprietary, the code base is completely open, right? You can look on GitHub at Microsoft/vscode, and you can see exactly what's going on here. A lot of the interesting stuff is sort of it exists in official plugins of sorts that are brought into the base Visual Studio Code experience.

[00:00:25]
But it's really nice to see some of the work that Microsoft is doing to open up their efforts around this. One of the benefits we're going to enjoy as we start to dive deeper into this project is the close collaboration that's happened between the VS Code team, the Microsoft Edge team, the Visual Studio team.

[00:00:50]
And by that we mean the sort of heavier IDE-like experience. And then finally, the TypeScript team. So all of these are sort of developer-oriented teams that are trying to build great tools for us to build apps with. And you start to see that there's a lot of good symbiosis going on here, I guess is the right word, or synergy to use a business buzzword.

[00:01:17]
In particular, we see it like TypeScript and VS Code, they seem to be coordinating really well.
>> Mike North: So one of the benefits of having started this project only a couple of years ago is they get to learn from other past lessons, other attempts that didn't sort of take off in the JavaScript community in terms of providing tools.

[00:01:42]
Heavier IDEs are definitely not the way to go, right? There are people that use WebStorm, and are productive with it, and enjoy it. But oftentimes they will find that their whole team does not want to use WebStorm. Or they're an outlier, a successful outlier and no judgment here.

[00:02:02]
If that works for you that's great. But we wanna empower a broad swath of the developer community. And in particular when I started using these heavier IDEs, it's like if I open up a JavaScript project in something like IntelliJ, I find it's about a two-week process of as I hit walls disabling pieces of functionality, right?

[00:02:23]
Telling it, no, I do not want you to watch Node modules and to try to index all of those dependencies that's potentially thousands of files there. Just focus on the code that I'm writing until you end up having to sort of beat it into submission. Once you get it there, it can be nice, but it is a hurdle.

[00:02:42]
It is sort of pain that users have to go through before they can actually get to where they feel like they can move fluidly.
>> Mike North: So code does not impose a lot of opinions on users, and I'm talking about Vim here. That is an example of something that imposes opinions on users where you have to learn all of the magic keybinding incantations.

[00:03:08]
And I wish that my my brain did not reject Vim in the way that it does cuz I've made significant efforts to try to become proficient with that. Plenty of developers swear by it and claim that they can move faster and edit code. And they look like wizards when they're selecting five lines and editing them all simultaneously, but you have to learn all of that.

[00:03:35]
You have to sort pick that productivity hit as your transition into Vim from something else. One of the great things about code is that you can install a key mapping from whatever editor you are already familiar with. And you should be able to basically keep using the same keystrokes, keep practicing your same familiar habits, and the editor will do what you expect it to do.

[00:04:01]
So you get to bring your keybindings with you. And I love to see that we favor, code teams to favor open standards over the proprietary format. So these files like .jsconfig or .editorconfig, they actually predate Visual Studio, but they work equally well in a Sublime or in an Atom.

[00:04:23]
Sometimes you need a plugin to find something that will look at these files and to incorporate them into your development experience. But it's good that the existing standards are being adopted rather than some special magic XML file that like it's just for this particular editor. This means that we don't have to necessarily, there is value in checking these files into a project and sharing them amongst the team compared to the question of whether we should have the Eclipse project, the IntelliJ project, the NetBeans project, all as files that are checked in, all maintained.

[00:05:03]
Each of them has a different way of maintaining their tasks and things like that. So it is good to adopt what already exists rather than to find something new.