044 AiA Visual Studio Code with Erich Gamma and Chris Dias

00:00
Download MP3

02:28 - Chris Dias Introduction

02:38 - Erich Gamma Introduction

03:38 - Visual Studio Code

06:25 - Task Running Support

09:13 - Cross-Platform

09:58 - Branding and Searchability

13:51 - Philosophically, what were the driving factors behind Microsoft releasing a cross-platform tool?

19:10 - Preview => Release Timeline

  • Extensibility

22:04 - Core Features

33:13 - Testing

  • Problem Matchers

36:31 - Angular 1 Support

37:29 - Snippets

38:04 - Debugging Support

40:07 - Speed

41:00 - Features and Tooling (Con’t)

  • Peek
  • Find All References

45:40 - Getting the Latest Versions

47:13 - Visual Studio Code vs Sublime Text

Picks

Chris Dias, Erich Gamma and John Papa - Visual Studio Code: A Deep Dive on the Redefined Code Editor for OS X, Linux and Windows (John)Visual Studio Code Connect Link (John)Rob Eisenberg: Getting Started with Aurelia and TypeScript (Ward)Blue Man Group (Katya)ng-vegas (Joe)[YouTube] ng-vegas Channel (Joe)The CodeNewbie Podcast (Chuck)Ask Me Another (Chuck)[YouTube] Getting Started with Angular 2 Developer Preview (Chris)Jonathan Turner: Using TypeScript in Visual Studio Code (Chris)Emmet (Chris)The Computing Universe: A Journey through a Revolution by Tony Hey and Gyuri Pápay (Eric)

Transcript

CHRIS: Does that include jokes about the fur coat?[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]**[Does your team need to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours -- AngularBootCamp.com.]**[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development. Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]**[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “ _ angularadventures _ ” you'll get a $10 credit!] **CHUCK: Hey, everybody! And welcome to Episode 44 of the Adventures in Angular show! This week on our panel, we have John Papa. JOHN: Hey, everybody! CHUCK: Lukas Reubbelke. LUKAS: Hello everyone! CHUCK: Joe Eames. JOE: Hey, everybody! CHUCK: Is Katya there with you? JOE: She is not yet.. She will be.. And I just apologize in advance for my terrible chest cold [chuckles].. CHUCK: Alright. I'm Charles Maxwood from DevChat.tv. We've got two special guests. We've got Chris.. Is it Dias? CHRIS: Dias. CHUCK: Dias. And Erich Gamma. ERICH: Hello! CHUCK: Do you gentlemen want to introduce yourselves really quickly? CHRIS: My name is Chris Dias. I am a Program Manager on a Visual Studio Code team. ERICH: So now I'm not allowed to use more words than you did, right, Chris? CHUCK: [Laughs] CHRIS: No, you should use more words.. ERICH: I'm Erich Gamma. I am a Distinguished Engineer. I'm running a team in Zurich, small lab with 8 developers and we work on this thing we will talk about, Visual Studio of Code. I joined Microsoft four years ago, and before that, I did auto things like Eclipse, JUnit, Patterns, stuff like that. CHRIS: That was a lot more. I can go on a little bit more, like background. [Laughter] CHUCK: Go ahead. CHRIS: I've been in Microsoft for 21 years. I've worked on develop fulls almost the entire time, everything from answering the phones on Visual Basic 2 and 3 to shipping .Net frameworks, languages, and for the past few years, on this project, which also has different flavors if you think of Monaco as your website so VS Online as your website, and the Monaco Editor, all part of this project. I'm in Redmond. And as Erich said, the Engineering team is mostly in Zurich. CHUCK: Very cool. So Visual Studio Code, do you want to give us an overview of what that is? Maybe how it's different from Visual Studio, the Studio? CHRIS: Yeah! Visual Studio Code is a new lightweight code editor redefining what a code editor is. If you think of a Spectrum of Editors and IDEs, Editors on one end just being your regular Text Editor, Notepad++, Sublime, things like that and IDEs like Visual Studio or WebStorm or Eclipse. On the other hand, Visual Studio Code falls along that line much closer to the editor end of the spectrum. So it is a lightweight editor but it adds a couple of things that really enhance the end development experience, we call it the Core Interloop, which is the great IntelliSense or code editing and understanding experience and debugging. So great editor out of the box but with some of the key things that you need to edit for development that typically rarely available in bigger IDEs. It is Microsoft's first cross-platform development tool. ERICH: Maybe one thing I would add in addition to what Chris said, if you look at IDEs, there are lots of good stuff in there like IntelliSense debugging, but that falls to auto things like for almost each framework that exist, they integrate it so [incomprehensible]. We took a different approach here, we only took the inner loop stuff functions from the IDE, but we also say it's okay to do things on the command-line. So it's not everything that you do like publish to a website needs to have a button in the shell or the Tool. That's kind of we respect and honor all in the command-line, and that's a way to keep you more on the Editor end of the spectrum and not on the IDE end of the spectrum. CHRIS: We work well in opinionated workflow. So if you've got a workflow that you've got, then Visual Studio Code just fit into that and not cause you to change the way it should work, but enhance it. JOHN: The other way I like to look at it is, in Visual Studio or an IDE, there is a very opinionated way that you should do things and lots of things or buttons clicks is very mouse heavy and everything plugs into a certain predefined workflow where it makes more difficult to plug in to how pretty much any developer you pick across the street would want to do their workflow. Whereas an Editor like Sublime (the canonical example), you can do whatever you want, you're relying to mind your own tools, you could use an Editor and the terminal and a browser and find the things that work together, I think that's where Visual Studio Code falls more on that side, where everything is keyboard-heavy, you can pretty much say, "I want to work this way or that way," and define your own workflow and your own tasks. So, it's not that, again, one is better than the other. So much of it is kind of if you want any more tailored workflow to the way you work, I kind of like how Visual Studio Code works for a code. WARD: One of the things I think that's cool, and as long as though that separates it from the Editors (and I'm hoping you guys can comment a little bit about your ideas on this), is that there's often -- let's suppose you shell out to a terminal or console and you're doing your command-line thing -- there's often information that's displayed in that console that could really improve the developer experience if it flowed back in. I often find that Visual Studio Code can do that. I wonder if you guys can comment upon that as a principle and what special things you do for that. ERICH: You mean the additional information we keep it kind of in context that is kind of, in the inner loop that comes from selects general tools like Git, what are your outgoing changes, what are the incoming changes? WARD: That's just one example, but.. ERICH: Errors? JOHN: I think great example, errors.. And I can imagine that I might have my own tool that will be splitting things out and some of that material that comes out would be useful to flow back into a VSCode in a way that somebody returning a VSCode could click on something and see it jump there. ERICH: One area where we want to really do that, because you have this tools that produce output like Errors but you really like to see them in YouTube because you want to quickly navigate the errors, you want to jump to them, what we have built is a lightweight integration of task running so that it can define a task that does something and then you give us some additional meta information about the task that allows us to integrate the output from the tool, from this external tool, into the Editor. That's what we call "Task Running Support". For instance, you can define a regular expression that extracts the error information and we can then present that to you in the tool again, in the loop, where you develop. That's one of the design points we have. The open allow things to run outside but pull the stuff into the Editor that you want to have at your finger tips to improve your navigation on the standing. WARD: That's really great because I don't have to then go look on the output find and its line 58, go back into the IDE, do a go to and find 58; I can just see it there and bang! I'm at it. ERICH: Yup. CHRIS: We talked about before we want to fit into existing workflows. We don't want to make you have to rewrite your Gulp tasks, but we want to be able to surface just the right amount of information to make you more productive, which is why we have this Task Running System that basically says, "Hey, here's your existing set of tasks. Just tell us what the regular expression is and then we'll do the rest of the heavy lifting." To add that thing that you don't normally get but what you need in sort of that core interloop. JOHN: If I've heard you correctly, we're this kind of place then is something we've tried was having the TypeScript linked our code through a task and then code effectively, uses a regular expression to pull out the different errors or warnings, and then toss them in codes, errors, and warnings pallet. Is that correct? ERICH: Yup, yup. Exactly. CHUCK: I want to interject here really quickly and just point out.. I don't know if this came up, I might have missed it because I was playing with code on my machine and it runs on OS 10, Linux, and Windows so anyone who tuned out because they were like, "Oh, it's Microsoft; it'll only work on Windows," it's not the case. CHRIS: Yeah, I almost forgot. We almost forgot, yes [chuckles]. JOHN: Yeah. In fact, that's the biggest reason I was pushing toward. I've got to admit, I have not used code for more than 5 minutes on Windows. Since I've been playing with this, all I've been using it on is OS X on my Mac and it's been my de facto editor for the last several weeks. So it's been phenomenal for me. As there holes in it still, I still think there's a few gaps that need to be improved but, to me, it's been an amazing cross-plat story. CHUCK: The other angle on this that I want to talk a little bit about is that, when I install IDEs like Visual Studio -- not Visual Studio Code, but Visual Studio or some of the jetbrains one like IntelliJ or RubyMine -- they just, in a lot of way, seem like they're overwhelming, and this is a really, really simple interface. So is this a completely different product? And if so, why did you name it Visual Studio? CHRIS: It is a completely different product from Visual Studio itself, but we named it Visual Studio Code to keep it in the Visual Studio family of tools. Visual Studio itself has a very high satisfaction rating amongst developers. And we just say, "Hey, what's a great tool?" it's Visual Studio that's always sort of very favorable. And when you ask people, "Hey, what is it about Visual Studio?" a lot of things that people say, "Great IntelliSens, great debugging experiences." So what we're trying to do with Visual Studio Code is to expand the footprint of  where we have developer tools offerings in cross-platform and have an offering in this space where Visual Studio doesn't exist today. By putting on the Visual Studio brand, we get the umbrella of Visual Studio so the good news to that, we get the, "Hey, we need your reaction, the franchise features of Visual Studio IntelliSense debugging surface himself in Visual Studio Code. But it is a completely different products. ERICH: But I like to point, to franchise should be very similar. The strong points of Visual Studio on the desktop going to bring into Visual Studio Code. CHRIS: Yup. WARD: And forget the franchise issue for a second or whether that's a great name everywhere, but one of the challenges that you've set for yourself is to how to search for an information about code, Visual Studio Code, and that includes within user voice and everything else and not run into all of the user voice and problems, stats and solutions and so forth that relate to Visual Studio proper as opposed to Visual Studio Code. And you can't search for the word code very well because that delivers everything so it's been a bit of a challenge to filter out the things that filter to the things that are Visual Studio Code specific. Are you guys doing anything to address that? Or, we're just going to suffer out here? CHRIS: Yeah, we recognize the search ability problems with the name. But as we build up more context -- because there's not a lot of things that actually go out and search for -- but as we build up more content and do more stuff, we're actually working very hard to do Search Engine Optimization and things like that so that this information will level up when necessary. It's a known problem, but it's a tradeoff we're trying to balance. CHUCK: Hey, at least you didn't name your programming language "Go". ERICH: [Laughs] Or, "Go To", yeah. No, but I think we now track to hold feedbacks since almost a week or more than a week, and I must say, I have the same fear. What I found with the new social media -- now we have a Twitter hashtag, you have a Twitter account name -- if someone blogs about it, there is also Tweet or using the #vscode. So for us, it didn't work as badly as I expected. We found the blogs because there's a corresponding Tweet about them. My whole team, almost everything in the whole team -- we're all coders, we're all testers, now we're all feedback trackers -- and so far, it went pretty okay. JOHN: I think part of that, the reason, Erich, is that a lot of -- this was announced last week at //build/, was it last week? A week before? CHRIS: A week and a half week ago, yup. JOHN: Yeah, in San Francisco, and things went well there, and the audience for that is obviously very Microsoft focused, which I think why Visual Studio Code is much more a familiar term with them. But it also brings up the same question that I've heard a lot even from the Microsoft crowd. The Microsoft crowd are saying, "Wait a minute, is this Visual Studio on a Mac?" which I'll let you guys address, and then the not-much like crowd is like, "Wait a minute, it's Visual Studio, should I ain't be looking at this?" And I think Lukas had a similar question that kind of goes along with this and I have to refer to him to kind of drive into that? LUKAS: Thanks, John. So the question I have is being involved with kind of the open-source community is putting out a tool like this is outside of the, I think, the picture that people stereotypically paint of Microsoft. So if I may ask, philosophically, what was the driving factors behind releasing a cross-platform tool? ERICH: It was just a logical step, given all the cross-platform often. I use PNet, of course CLR, it's still logical step to deal on it, pair the libraries with the tool so that you can develop with the libraries on every platform and have a great developing experieince. That was a logical follow up of open-source making all the other technologies like Roslyn available cross-platform and so on. LUKAS: So how much resistance you guys foresee community that traditionally is just kind of seeing Microsoft and kind of  disclose like you have to delve into their ecosystem, which I think when you're in the ecosystem it's really nice, but now it's like, "Hey, we're a totally different thing here, check it out." What are your thoughts about actually reaching out to a community that traditionally may not actually even consider Microsoft Tooling is a viable thing and all of the sudden now, you put this amazing tool chain in their laps? CHRIS: I think that's one of the key things we have to go and do. But until we had this tool, we had no way to go and talk to anybody outside of our ecosystem. We ask, "Hey, you could do .Net cross-platform," but we don't give you any tools of anyway that actually do it. And we saw a huge interest in the open-sourcing and cross-platform of .Net. It's like third, I think, in Hacker News of all time. But we had no way to talk to developers or go out and continue with that story so we had something that was a cross-platform tool. So now that we have that, we can go and talk to the Python crowd, the PHP crowd, anybody that is doing something that is not traditionally on Microsoft platform or in Visual Studio itself. Now we have some way to talk to you and offer up something that has a value that you may have heard about some good things in the Microsoft Visual Studio world but you can't use it or it's like, "It's big, it's heavy, I don't want to use it." But now, we can provide you these cool tools. And that's part of the motivation behind what we're doing. As Erich said, it's a natural evolution but in order to talk to these people, you need something that talk to them with. JOHN: And Chris, something that I really am grateful for that you guys went down this road on is, for years, I would say I came from Microsoft world, I was spoiled with all the wonderful tools that Microsoft had. When you're working at .Net, you're livid and you kind of take it for granted. But when I moved over doing fulltime open-source and pretty much moving off the .Net stack a couple of years ago, first thing I realized is that, "Wow! There's really a dearth of great Tooling out there!" I tried WebStorm, IntelliJ, Bracket, Sublime, Atom, Vim, TextMate, the list goes on and on, and they all had something great about them, but none of them were quite what I was used to from the Visual Studio world, but in the same sense, I like the speed and efficiency of an Editor; I didn't want a full IDE. So in a lot of ways, I was really being self in saying I would love to have a Microsoft-based back tool on a Mac platform being a node JavaScript developer this day. But I'm curious from you guys, what do you get out of it? Yeah, you can talk to people now, but what's the benefit and what's going to keep you guys delivering more features in this? CHRIS: The benefit is we do get to go and talk to more audiences. It's pretty simple. At the end of the day, we'd love it if people are building stuff that runs on Usher and they're storing their stuff in Visual Studio online and all these different services that we offer or consuming offers 365 APIs. From Microsoft as a whole, that's what we would hope people do. But that's like Step 1 and Step 3 profit. Just even get started like we really want to just be able to have something, being able to go and engage more and more developers with tools that we traditionally can't offer or talk people with. There's a long term goal of we're hoping that people would use more of our APIs in our platforms. But quite honestly, right now, our goal and the benefit of it is that we're just able to talk to more developers. We can have that conversation. Because if I can have a conversation with you about the tool, then we can have another conversation later about something else, whatever that maybe. But really, at this point, what we just want to be able to do is to offer for better Tooling experience accross platform, take Visual Studio where developers are, meet them where they are and have to say, 'You know what, in order to use our tools and all the stuff that we have, you have to come to Visual Studio, you have to come to the windows." In this day and age, that just doesn't work anymore. So I think you're seeing not only us, but Microsoft as a whole making this [incomprehensible] where we're reaching out and going where people are instead of saying, "Hey, you have to come to us." That's Step 1 for us, and then we'll figure out what's Step 2 and Step 3 look like. But really, we just want to make a connection with people; I'm bribing them with great tool. ERICH: We want to be relevant to developers. CHRIS: Yeah. ERICH: The developers today, they're not only Windows, they're on all kinds of platform. Like John has said before, he's on the Mac since I don't know long. We want to be relevant to all of them. CHRIS: Yeah. ERICH: And that's why it's important. It gets you connected. JOHN: Right now, you guys are Preview, we're always in the wonder, when is the release going to be? And then what features are on your road map and what are you building towards? CHRIS: We're at Preview right now. I think there's a key set of things that we need to go and do. First and foremost, finish up our extensibility story. So we released Preview without releasing its extensibility story because that's still being developed by Erich and the guys. But we wanted to get the tool out there and get into people's hands so we can get feedback on the functionality and we can see where people are going to extend it and start to have a conversation where we can get feedback on that. That's the biggest thing of it on our road map, our background. From there, there's a million things that we can go and do and add to the tool. The trick is deciding what to put in and what to relegate to another tool that's in the tool chain, and not put it into Visual Studio Code. I think, at the end of the day, building another IDE that is 3 gig download or something is not what we want to do. So, we're looking at -- we've got quite a big backlog of features that we want to go and add and what we need to do is figure out what goes in the core of the product such that you've create inner loop is enhanced by those things, and the things that go in the core product that any extension were blind to take advantage of. Outside of that, shipping things has extensions to the tool and then overtime, seeing what is popped there or what should be in the inner loop and maybe elevating those or promoting those to be in the court tool itself. So number one is our extensibility model that enables tons and tons of scenarios that we can't go and do everything on our own so it's a well proven model. From a timeline perspective, Erich, do you want to talk about timeline? What you're thinking? ERICH: Well, timeline Preview, one thing we should mentiion, it sounds Preview but you were [incomprehensible] since quite a while, its cope base has some mileage. I think that's one point I'd like to make. And then, I guess, the goal is set us for the extensibility somewhere set over summer if we want to really nail it. It's not as if you have nothing. You didn't build this monolitic clog. So if you look at the code structure, there is actually a plugin folder that has plugins in there that's for each language to find the plugin folder. It's just that we take APIs very seriously also when the API sent the development model, then we just found it. It didn't have the maturity to release it at Preview, but we can make great progress on that over the summer. CHRIS: One of the wild things that we've seen over the past week and a half is people actually going in and figuring out that plugin folder structure and then [chuckles] striking modification underneath its whole and we haven't even published anything. So it's been amazing. CHUCK: So the reverse engineering, the existing plugin set that comes with it? CHRIS: Yup, yup! LUKAS: It's JavaScript, right? CHRIS: Yeah. JOHN: Can we take a quick step back just for remembering? A lot of people haven't touched this yet, it's only been out for a week or so.. What are the main features, what are the main selling features that if I"m a developer and I use code, these are the things that I'm going to get or benefit from that really no other tool does this well as code? What are those things? JOE: I think we need to also start off with the feature that pretty much everybody cares about if you don't have it, nobody will talk to you about it, and that is multiple carrots. CHUCK: Multiple what? JOE: Multiple carrots. ERICH: Multi cursor.. Of course, yeah, which we have. Yeah, we have that, yeah. JOE: Well, I think, that's it! Once you have that, everybody will use it. [Laughter] ERICH: No, but everybody has it by now. There's actually one feature which we don't have multicursor that you can easily select in extra cursor so if a matching string, which we will add for the next update. CHUCK: Kind of related to John's question, I'm going to just throw this out there and it may color your answer a little bit but, you said that you don't want to change people's workflows too much, but it seems to me that if a tool does something really well it's going to, and it's going to benefit them, it's going to change the workflow and it's going to benefit them, what kind of features are in just the core functionality of code before we add any plugins that are going to enhance people's experience? ERICH: One idea we have -- because editors have one strength to support many, many different languages, that's what the strengths of TextMate, Sublime, you get coloring, you get all kinds of stuff for them. And what we set -- okay, coloring is great but you want to go one level further and how can we achieve consistency accross all these languages? For this reason, we're not only an editor that gives you mulitcursor, we're also an Editor that keeps it kind of a language toolbox -- how you show IntelliSense, how you do a Rename Refactoring, how you do a Reference Indication, how you show Parameter Hints -- that's one of the things which also helps us to preserve consistency accross languages and helps us, as opened this platform, that all these concrete languages which behave and have the same features as we have build now for TypeScript or C#. That's where we want to go to. You want to have that all languages or at the deep, at the very good level, not only coloring, but also IntelliSense, Refactorings, Reference Searching, Find All Reference and things like that. That's where we want to land it yet. If you look at our language support right now, we have 3 levels, and not all languages are at that level. That's also why we're so interested in Plugin Architecture; to help others, to help us, to push more languages to the happy level. CHUCK: Yeah, we need our high school integration. [Overlapping talk] ERICH: We enable and test noticing well people [incomprehensible]. If you look behind the scenes [of] what the code is, it is a multi-process architecture in that brain for TypeScript so the brain for C# doesn't drawn in the same process as the UI, it drawns in the separate process and talks in this process using a simple JSon based protocol. Now what is enable is that the same brain can be used for different editors. That's an interesting, also an open idea so that you can use the same brain for different editors and this is in fact what's happening. Like the TypeScript brain, he's also available in Sublime. If you really like Sublime better, you can use it in Sublime. But we use the same -- we call it "Language Server" -- in Sublime as in code. That's another interesting aspect of code. For C#, we use only # as the brain to give us its IntelliSense, which also available for Sublime, Brackets, what have you. JOHN: We heard from Joe, and I agree with him, the multicursor's a big awesome feature that needs to be expanded but, what are those top, Chris and Erich, 3-5 features that you say are just the killer features for using code? CHRIS: For me, it's IntelliSense out of the box and cross workspace IntelliSense. Like if I"m doing an ASP.NET V5 application, I just get rich IntelliSense experience powered by the Roslyn compiler, which is an amazing API; we'll see a bunch more come out of it, which is Navigation understanding so like Go To Definition, Find All References, things like that. That's one big thing. The other big thing for me is Debugging and being able to debug directly from within code. I'm an old VV guy so having an ability to just hit F5 and break on your first line of code without having to do anything is a great sort of experience. Those are two key things for me. The third key thing for me with code is through the lightweight IDE -- I keep trying to say IDE just from a historical perspective -- but the lightweight environment, that's keyboard-driven. So everything comes out of the command pallet, you can navigate and access all the functionality, the tool to the command pallet. It's lightweight, there's no tool bar. There's just a simple folder view of your files. It's a very simplified environment unless you focus on what you need to focus on which is writing your code, debugging it, and you have quick keyboard access to everything on its own. So there's great IntelliSense thing, but also the lightness and the keyboard access, to me, are key things of code. ERICH: The other thing I would add is the protect structure is just files and folders, it's not kind of a lot of metafiles. Of course, metafiles, like what other files in a project, but really for a user, user, it's very simple thing: you open a folder, we try to find the protect context based on the folder layout. So you'll find the prototype chase that ASP.NET finds, send the ask in step one you want to use and will use it as the context to then the intelligent, I'm providing intelligence accross many files. But Chris is right, it's really the franchise function they coded well before. But this in consistent failure accross many languages kind of densed. JOHN: So you guys have built -- I mean our side of this for a little bit now that's why I wanted to talk about this -- but you guys have built a really cool Editor and I love how it works really well in the TypeScript world. So if you're using TypeScript, to me honestly, I don't think there's a better Editor that you can use out there, and you guys can go check out the features online and see what's there, but what about in how the JavaScript world is working? What if I want to use a Gulp with this? What if I want to use Grunt? If I want to tie in my Karma testing files, how does like all to integrate in with my current JavaScript workflow and what kind of features do I get there? ERICH: There is definitely node that existing tools like JSon, whatever you run for external tools for Gulp and Grunt, this task running integration you want to provide, you can describe what it do and how to analyze the output from it. For that, you want to be fully open. That's what it support and that's what we also have, as a JavaScript developer. One thing one has to realize, that you said, it's the best tool for TypeScript. One reason why built TypeScript is that it's very hard to build excellent tooling for JavaScript because it don't have type information to give you great IntelliSense experience to give you a Find All Reference experience. For that reason, there is of course gap when it comes to the level of support for TypeScrlipt and for JavaScript because that was the whole reason why TypeScript was built -- to enable intelligent tooling. So if that's where you're going, John. JOHN: Yeah, I think it is. And something kind of blew my mind was when you're showing me some of the Tooling, and I was writing my code in Node or in Angular, also when I get this green squigglies under the word Angular or under maybe Restify inside of Node. And by clicking a button there, it actually pulls down -- tell me if I got this wrong -- but it pulls down the d.ts files off the definitely types GitHub site and then splits it in a folder in my project, not in my distributed code, but just in a sub-folder called Typings. And then all of the sudden the tool code now knows about all the types and the InteliiSense and hints in order completion for Angular and the client and like for Restify in the server. ERICH: Yeah, that's a good point. We couldn't talk about how we build it later, but the whole thing is built with TypeScript and of course we laugh writing a large scope basic TypeScript. We have learned a lot longer, and for that reason, we want to leverage TypeScript to the maximum. What's nice about TypeScript, (1) side product of TypeScript is that all of the sudden, you get Type information for libraries in the syntax, which is actually nice to write so you don't need XML to describe what are the signature of JQuery or whatever, can we use TypeScript for that? So one idea was, for us when we build the JavaScript Tooling, is also the leverage. All of these artifacts we get from TypeScript, they'll open also for JavaScript. That's how we get this d.ts support and that we leverage this Type information in full libraries to make them available to you for JavaScript developer. This has some limitations when it comes to your own code. But IntelliSense full libraries can be very rich and be very good experience even for JavaScript by defect that you have Type information for libraries because we all use libraries and we also get APIs all the time. WARD: Yeah, that's what kind of blew me away as I'm sitting there typing, and I don't remember the syntax for Angular half the time, I don't remember syntax or anything half the time so I just copy and paste what was that before. Now, I can just type in Angular.controller and I get the syntax or the controller meta signature looks like and everything just kind of flow. And it's even more so for me for things like this Node libraries that I rarely use. I use them like once every project every couple of months. Now, I'm getting IntelliSense in those things. The key for me was, I don't have to touch TypeScript. I like TypeScript but if my project is all JavaScript, I'm still getting this tooling IntelliSense, which I never got before. ERICH: That's really cool to hear. We believe it failed because JavaScript developer, how does he react to d.ts file, but it's always very easy and natural. Of course, there's some meta files which makes my tool better so I just take it then and I'm happy and go with it. WARD: Yeah, it's one of my favorite features, too. Even if I wanted to never write a line of TypeScript, I would get over the idea of having a single comment line at the top that said -- actually, not even in the top of the file, you can put it in some place offscreen, you don't even see it. And I have a single one in there that referred to d.ts file and I've got some help. I paid that price any day. That's really a wonderful feature. ERICH: And it looks like the Angular guy is also the development team came to same old conclusions that goes to say to have this Typing information that's why Angular 2 always now also included in TypeScript, which I was very happy to hear about. JOHN: Yeah, I got to say, I switched over to code 100%, and by doing Angular 2 code recently in code, I understood the code -- well, I hate saying code in code. [Laughter] JOHN: By doing Angular 2 inside of your Tool -- I'll say it that way -- it's really litten up a lot of features for me that has made it easy so I'm still learning the APIs for Angular 2 and it's just automatically flows now to the tooling, which is making it easy to learn new things. WARD: Yeah, it's kind of a gateway drug to TypeScript, actually. The ability to drop that reference in. It's a gateway drug. I like that. I want to talk about something in the workflow that you guys have described it in the site and so forth that I'm not seeing and I think I'd love to hear your thoughts on it, that's Testing. Let me step back a little bit, when I think about, before I put anything in user voice, I ask myself the question: "Am I putting something in there that relates to something I do every hour of everyday that I write code?" If it doesn't fit in to that like it shows up in any hour at which I throw a dart, then I don't think it belongs in VSCode. That's kind of my screen at the moment. So one of the things that's in there every hour is Testing. And yet, I"m not seeing in any of the tutorials and so forth so far kind of workflow around Testing. I'm not saying that Testing belongs in the Tool, but I'm curious about the workflow. ERICH: No, Testing is definitely part of in the loop but we treat it the same way as building. It's a task you're on and of course you want it more frequently like you want to build more frequently, you can run your Test more frequently. And for us, it's a task. If you look at the Test Run today, most of them are textual anyway; they're on the test like mock or whatever and they show errors and they show tech traces. So they're following the same path enough being a task that you're on regularly. And we actually support that you can also have a special key binding to Command, Shift, Key that it can run a Testing task easily. WARD: If it's a Test, as the Test results, the Test failures flow back into VSCode in some way that I can then click on something and get to the line either of the Test or something around there? That's the problem? ERICH: Yes. So maybe we should document a little more, but that's the idea. A Test failure is a tech trace and you can define regular expressions, problem matters that will show up as links you can click and navigate to, for instance. JOHN: Great! So it's just a documentation issue? That's all I'm asking for [chuckles]. ERICH: Well, we have thought about it. But for us, now, we don't want to build a UI for Test running given that that will seem to like command-line based Test running UI a lot or the browser based one. WARD: Well, I completely get that. I'm only talking about that feedback cycle and how I can create a -- if I saw an example -- how you create that feedback cycle for your own matters and stuff so that I could build my own tasks and it can flow back in. Once I have that pattern and example how to do it, I can use any Test runner in the world, and I'm okay. JOHN: Yeah, I think that's good area. They call these things "Problem Matters" and Erich wrote me one for actually scanning the TypeScript output and then making the app went to code so I could click on the lines. But I think that's kind of where there's a curve there. I hate regular expressions personally so learning first for the regular expressions, I've got to go do that and then just the code syntax to say, "How does that problem matter have to be defined?" I think one's at stare, that opens the door to anything around externally. I can then add those to the command pile up to say, "Alright, I have these errors or issues that a command-line will gate me, now go to this line and this far". WARD: Bingo! That's what so powerful about VSCode and we just have to learn how to use that power a little better. That's my hope for you guys. Or, somebody! Maybe we could.. CHRIS: I think it's great. We should do a doc or we have docs on how to do Node and ASP.NET V5 and Debugging, but we don't have anything on Testing so maybe I'll do that this week! KATYA: Do you have any specific features to support Angular 1 and Angular 2? ERICH: For Angular 2, that has recently covered. Because Angular 2 is running TypeScript, then they have d.ts, they will not declare their stuff as beta before they have d.ts for their APIs so we support that fully. For Angular 1, if you do TypeScript, I think that's also [the] feedback we get from Angular folks -- we're in good shape. The question is, what specific support we give you for JavaScript? And there, we have added some Angular specific support that it can at least get some IntelliSense on injected services. That's what we added. The challenge there is for user. It's not always clear. When is there a support, when there isn't support. So there are some gaps there. JOHN: Do you get the, instead of Angular 1, you can't pull on the d.ts files and get at least IntelliSense, but I think having it figure out what injected services you have and what its APIs are, that would be really key. ERICH: Yeah. WARD: Yeah, missing that. Yeah, that'd be great. JOHN: What about things like snippets and what not, can you get Angular file templates and also in-line code snippets working? ERICH: Right now, we have snippets that come with each language, they're close. We will support you as a defined snippets, and we have a hidden mechanism right now, which we don't want to document because we want to slightly change them and make it more smarter. That's definitely something that will come. Yeah, we will support snippets and then we hope that someone like John Papa [incomprehensible] snippets for Angular 2 code. That's where we want to go. JOHN: I'm all over that. WARD: Yeah, and I've got some weight in the wings for Testing, too. On the Debugging front, Chris, can you explain why I had problems debugging when I'm running code against ASP.NET in Windows? CHRIS: Yeah. We don't have debugging support for ASP.NET. We have two target runtimes so we have debuggings work in the Preview. One is Node and that runs on Windows, Mac, and Linux. The other is Managed Code running on mono on Linux and OS X. ASP.NET, we're working with the core sealer guys to bring up debugging on that stack accross platform so I think there was a build really showed a little bit of cross platform debugging of an ASP.NET app in Visual Studio. So we're working with those guys to get that exposed in a way that is out of process so we can consume it in code. But the reason we can't do it is because even on Linux or on OS X is that the ASP.NET V5 apps are being compiled by the Roslyn compiler and the debug mono data isn't being written out, there's nothing to debug. When you're on mono, you can compile with the debug switch and then there's the debug mono data in there and we use the soft debugger (APIs is able to debug on those platforms). So it's just something that isn't available to us yet, but we're actively working on that. So the story is a little bit confusing really what you can do on what platform, but we'll get that nail down here soon. WARD: Well, I onlly bring it up because I'm trying to use VSCode in Windows instead of Visual Studio because I like it! [Laughter] WARD: So there's kind of vote of confidence for VSCode. I really like it. Only the other day, I was saying, "Well, let me try the.." oopps, I can't [chuckles]. CHRIS: Yeah, sorry about that. ERICH: Not yet. WARD: Not yet. So.. ERICH: But the UI will be the same as for Node. There was the same idea; one have a consistent, as you know from Visual Studio, accross different languages because you have built the same debugging UI, different structure that it can plug in to different debug engines. So once you get the core seal already back, then we'll be laughing. WARD: Sweet. I was at least the one person waiting for it [chuckles]. JOHN: Well, you guys solved the problem that a lot of us have been complaining on for years. I've been at the Microsoft inner circle like Ward and I, and that's Visual Studio has become very bloated. It does everything for everybody and they've been trying to trim it down to make it faster and they've done a good job with that, but in the same sense, it's still an IDE and it's always going to be an IDE. So this gives us an option in the Windows world as well to work with Microsoft Tooling or otherwise and actually move fast. So, kudos on that end, but.. WARD: I don't want to let go of that. I'm telling you, I lived in the Windows world lot and I was running Sublime and Brackets and WebStorm, and now, I even know I have Visual Studio at my right hand and still, now that I've got VSCode, I'm using VSCode because I like it. So that's a vote for VSCode even if you're in the Windows world. JOHN: And to be clear, even WebStorm to me is too slow, Windows or Mac, so what. I love the fast and speed of Atom, Bracket, Sublime, and Code. To me, I'm up on those 4 in that grouping. But I want to switch gears for a quick sec to talk about some of the features you guys have in the Tooling that I just love. When I discovered them, I looked like a kid in the candy store. Like you've got these things -- I might get the names wroing -- like there's a Peek feature where you can hover over a function and then actually show a small little window that actually shows that code without losing the context of the file you're in. CHRIS: Yeah. JOHN: And then there is Refactoring and Find References, and Find All References was amazing to me. Can you talk about some of those? CHRIS: Yeah. Talking about Peek, specifically, it's an interesting story behind Peek. Actually, there's Peek in Visual Studio, but we pioneered the whole Peek UI in the Monaco Editor and Visual Studio online for as your websites and now, of course, it shows up for Visual Studio Code. The idea with Peek is that, when you're scavenging your code and just trying to understand what things are, you don't want to constantly open up new files and clutter your environment so we thought it would be interesting if you can think about just being able to peek into whatever that code is behind that method or whatever it is. Instead of overlaying, we basically just separate the code or we split the code at that point and we show you the file behind that but just enough to give you a flavor of what's there so you can quickly see what's going on, you get enough landmarks presented to you in the Peek, we can understand if that's some place that you want to navigate to, and if you don't, you can just hit Esc, it goes away and it doesn't take you out of the context that you are in. That tested quite well so we actually promoted that one even up to Visual Studio itself. And we use that for a lot of cases where we do things like write in-line the code. Again, you're not overlaying what you're working on and you're not losing the context that you're in. WARD: If you're listening to this and you've never used VSCode or never seen Peek and you think all that in some of the Editors, I've never seen it in another Editor, that's one of the best features so it's worth cheking out. ERICH: Cool. But there's a matter of pattern behind it. I have to talk about patterns. We found the way how we can keep things lightweight, if you pull them into the Editor. So Find All Reference, don't open another window whatever, just show it in context with all of these code lengths as we do for C# total light bulb. As many things as possible, put them into the Editor and not separate and that's why I was thinking you can add making Editor very rich without adding weight with overall experience. [Laughter][overlapping talk] WARD: I totally believe it. It's worth like the anti.. don't do things modally if you don't have to. ERICH: Yeah. JOHN: It feels like it's right there, not leaving. And half of the time, I'm not interested in opening up a new file and losing where I am. I just want to know how that thing works that I'm about to call. JOHN: Yeah, and what's cool about that is it's not just a little modal window. You can actually scan. Let's say -- let's put it concrete here -- let's say you're inside of a Controller in Angular and then you want to peek into the data service that it's using that's been injected, you can actually peek into that data service, keep the context to the Controller, and actually scroll through an Edit, the data service in-line as you're seeing a little window pop-up, and then you can close it or control or you can go right to their file. But what I like, too, really just recently is their feature called Find All References, which is kind of similar where I could say, "Alright, I've got this data service and I don't know where it's being injected." I'm about to change an API and I can Refactor and make it change in every place, but before I do that, I don't want to see every place that's injecting this factory or service. So you can actually use Find All References to pull that up in a window and it will show you all the files and lines of code and, in the same kind of Peek, structure will show you all the actual like probably 10-20 lines of code from that file. I find that immensely useful when I'm refactoring accross the entire project of thousand files. These are things I haven't seen anywhere else in the code editing world. WARD: It seems like every time we ask Erich or Chris a question, John and I are talking about or doing fanboy on it.. [Laughter] WARD: But still, we invited you guys for a reason, not just to fanboy it. But there you go.. JOHN: So let's talk about what we don't like.. [Laughter] JOHN: I think we kind of hit that one. Lukas brought up the extensions, right. So the extensions have to be there and they're going to have to come into play. The experience in C# and in JavaScript right now, I know Chris pointed out some of the debugging isn't there yet for the ASP.NET features, I think the JavaScript side, it's good, but it can get better. There's got to be better IntelliSense or help for just plain old JavaScript even without the free your own code, I would say. ERICH: And we also found that people end up to unhappy things like [incomprehensible]. We built our own because we had, at some point, history on our browser. So yeah, I hear that point. WARD: ES6 would be nice. ERICH: That will come in the next spring. Next in the rule. Yeah, next update. JOHN: So talk about that in a sec, how do people get the latest version of these drafts? ERICH: As we develop as a team, we came with 3 weeks prints and we just made our first draft available. We have an automatic update mechanism built in based on the infrastructure we're using. Now we use a gate up electron that comes also with a skrill framer, which gives automatic update. Our plan is we're working this 3 weeks prints and at the end of the print, we want to first make the draft available to all the adapters or pioneers. They get an X as a development feed or stream of changes and they can get that one once maybe one week later. We will then switch over the automatic update for everyone to the new version. So you'll be one week delayed before after we have stabilized a sprint before everybody gets it by doing all some sanity checking and stress reduction by having one week of stabilization by a smaller set of early adapters and pioneers. WARD: So when I signed up for your insider's program, did that put me on that track? ERICH: Yup. You definitely get a priviledge to be that. Maybe we can be able to everyone. But we hope that the insiders, we hope that insiders are willing to be early adapters, yeah. WARD: That was as easy as clicking a button and say, "Yeah, kick me in," right? Now, did I miss something? ERICH: No, but at some point, we will then tell you to change to feed from which you want to get your updates, and that's just editing one JSon file, then you get it. WARD: Nice. CHUCK: Is there anything else that we absolutely have to cover that we haven't yet? KATYA: I'm just wondering why people might use this one instead of Sublime? CHRIS: There's a few things, the way we think about this. One is, out of the box, you get brain tells and experience and you get a great debug experience. And we talked about certain limitations of the targets for debug at this point. But without having to doing anything, without having to go and download extra extensions, out of the box, you have this great end to end inner loop editing experience. That's one reason, right? You don't have to go and configure things and set things up and figure out what works and what doesn't work. But at the same time, we talked a little bit about this briefly. We're building the Tool and the compulsary Tool in such a way that if you're a Sublime user and you want to use ASP.NET V5 apps with Managed Code, then you certainly can go and do that because we have the omni strap plugin that we use in code, it also works in other Editors. So we think that we've offered set of features and experiences which are better out of the box than other Tools. But if you continue to use other Tools but you've leveraged parts of the platform that we're building, that's okay, too. And it goes back to what we've talked about very early on in that conversation which was, in Step 1, we just want to be able to have conversations with developers and reach out to developers with richer set of Tooling that they have today and getting outside of the Windows box, the Visual Studio box and say, "Hey, you know what, all this Tooling should be available to anybody in their Tool of choice." So we integrate into the existing workflow, and that includes an existing Editor or we provide a richer experience that integrates with the rest of your workflow. So you have the choice. ERICH: Giving you choice and can also help to make a choice. Actually my team also contributes to this omni # and TypeScript services to make them better. We will improve them, which also makes them better in Sublime. To truly show you, we want to be open and we want to give you a choice. Of course, we hope you make the right choice. CHRIS: [Chuckles] ERICH: I told you, I'm biased. CHUCK: Alright. Let's do some picks. John, do you want to start us with picks? JOHN: Yeah, I'll start this off. I'm going to be a little self-serving and open this closure, there's a video up on the web that Chris and Erich did that they invited me to do at Microsoft Build two weeks ago. I thought it was a really great opening 15 minutes from Erich on where Visual Studio Code came from and where it fits in that scale between Editor and IDE. And it sets the stage for the way we used to held it from scratch or the way it lean on other Tools that are out there, and I learned quite a bit about how it's built, which was really interesting to me. So I'll put that link in our chat so that we can put that up on the website, but definitely check out that video. Chris and I also did demos in that, but Erich's part, I thought, was just superb for laying the ground work out there. And if you want, my second pick will be, if you want to learn about Visual Studio Code, best thing you can do is go to their Visual Studio Code website, which we'll put a link to the show. Again, I think it's Code.VisualStudio.com. ERICH: Yup. JOHN: They have a connect link. And at that connect link, they've got links to the program that Ward mentioned, Stack Overflow, for questions, they've got direct feedback, they've got their blog. So definitely, you want to check that out. My favorite part there is the user voice site where you can actually request features and vote them up. CHUCK: Alright, Ward, you have some picks for us? WARD: Well, I've second that you should take an hour and go look at the /build// presentation by Erich, John, and Chris, which will open your eyes. My second pick, I know a lot of Angular people are kind of curious about a related project called "Aurelia" by one of the guys who used to be on the Angular team, Rob Eisenberg. There is an interesting post on Aurelia and TypeScript, which I'll put in the show notes. Part of what makes it interesting is to see all the people who are voting for turning Aurelia into TypeScript, rewriting it in TypeScript, which team is quite, well, into do it, just want to know how the community felt, but that was an eye opener for me so check it out! CHUCK: Alright. Katya, do you have some picks for us? KATYA: Yeah, my pick for this week is the "Blue Man Group" because I got to go and see them in Vegas. LUKAS: I saw them twice! CHUCK: Nice! Joe, do you have some picks for us? JOE: Yeah, I'm going to pick "ng-vegas". We just got finished doing that this last weekend and it ended up being just a really great conference. I was really pleased with how it went off. We had a party out at the pool, something you don't normally see in a lot of conferences, so I was disappointed that nobody came and actually got in the pool. But it was actually a really, really great conference. I think it went really well. We had a lot of fun times and there's a lot of really cool tuxo. If you haven't bought or you need a tuxo so far, definitely go and check out the tux from the YouTube channel, I'll put the link to it in the show notes. CHUCK: Alright. I've got a couple of picks, they're podcasts this week. The first one is "The CodeNewbie Podcast" by Saron Yitbarek. Really good. She's talked to a whole bunch of people. The last one I listened to is actually kind of a round table between her and one of the other people that was in the bootcamp with her, Scott Hanselman. So, that was kind of fun, to listen to him, talk about finding jobs, stuff like that. And the other pick that I have is called "Ask Me Another". It's a game show, word games. Anyway, it's a lot of fun. It's an NPR podcast, but I don't hold that against it. Those are my picks. Chris, do you have some picks for us? CHRIS: Yeah, I've got a couple here. There's an "Angular 2 Dev Preview" talk by one of the guys at Google who actually uses VSCode in there. That's one. There's a great TypeScript and VSCode blog post that Jonathan Turner did. And the third one was, we didn't talk about it at all, it's basically just "Emmet". We have Emmets for built in to code. Erich actually did it, so I'm surprised we didn't talk about it at all. But any place in your CSHTML files, your HTML files, you can do Emmet so it's a very quick keyboard access to writing on chose HTML so try it out. CHUCK: Alright. Erich, do you have some picks for us? ERICH: My pick is more of the build we were kind of proud. We'd be 12 hours been on top, number one, on Hacker News. We just also press and try to short what's current, you cannot bring the past. I guess now, one week ago, we're no longer relevant so I took some days off last week and my pick is actually a book, it's "The Computing Universe: A Journey Through a Revolution" by Tony Hey and Gyuri Papay. I like to read signs, stuff, of course, short is the better, and they really enjoyed kind of being away from this Hacker News time, 3 minutes on top of whatever, to just go to the computing history and reading against know about hardware or software algorithms, the amazing touring machines and so on. So that's my bore, old-fashioned pick. CHUCK: Alright. Well, thank you both for coming and talking to us about this. CHRIS: Thanks for having us. ERICH: Thanks for having us, yeah. CHUCK: I think it'll be a terrific resource for people to go check out. And we'll wrap up the show, we'll catch everyone next week![This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]**[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]**[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]**[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]**

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.