The crew talk about Microsoft Tooling with Mads Kristensen. 

Special Guest: Mads Kristensen.

 

Didn’t you write that story, The Little Mermaid?

Hey, everybody and welcome to Episode 19 of the Adventures in Angular Podcast. This week on our panel, we have Lukas Reubbelke.

Hello.

John Papa.

Howdy, everybody?

Joe Eames?

Hey, there.

I'm Charles Max Wood from DevChat.tv. I just wanna remind you quickly to sign up for JS Remote Conf at jsremoteconf.com. It's an online conference I'm putting together. We also have a special guest, and that is Mads Kristensen.

Hello!

Do you wanna introduce yourself really quickly, Mads?

Sure. I'm a program manager on the Microsoft ASP.NET and Visual Studio Web Team. So, I'm sure of making sure that all the web tooling around Visual Studio and ASP.NET is up to standard, and you know, we have a good experience for our users there. And so what I do is all the CSS and HTML, CoffeeScript, LESS, SASS, all those different editing experiences is what I work on, on a daily basis as well as some new stuff that we're coming up with, with Grunt and Bower and npm support and all that sort of stuff.

Did you say “native script”?

Native script? No, natively. Sorry. [Chuckles] Visual Studio now has natively support for Grunt and Bower, npm and Node and all those things -- which are tools that we need in our web development toolbox, so pretty exciting stuff. But that's part of what I do on a daily basis.

I just thought you said “native script” for a second there. I was going to be really geeked out.

[Chuckles] Oops. Sorry.

Joe just wants to go native.

[Chuckles] It's really early in its technology, but it looks really cool.

Awesome. So the topic that I'm showing on here is Microsoft Tooling for Angular. So I'm assuming that means like capabilities in Visual Studio and things like that to support Angular and other technologies like it?

Yup. So we've been following Angular very closely, and were over the past… longtime actually. And it's pretty clear that Angular is coming out on top. And sort of our approach to when we look at Angular versus other frameworks -- which is Backbone or Ember -- is that wanna provide like a great experience with web developers using Visual Studio for any JavaScript library framework.

But we wanna take Angular and take it a little bit further and add some additional tooling specific to Angular, because it's very evident that it's the most popular now. And you know it keeps getting more and more popular. So that’s sort of our approach to the problem, so to say. But there's more to it. It's not just editing. One thing is that we can provide auto completion and stuff like that, but we're looking at a wider set of tooling capabilities.

So one thing for instance is Swagger. So how can we take Swagger, which is sort of a REST API end point description JSON document. You know, remember back in the good old days when we were dealing with SOAP and WSDL documents and all those other stuff. It was horrible – very, very horrible. But it did have a great user experience, in that tooling could provide a lot of generation of code and proxy classes and all this sort of stuff, so that you were really productive as a developer using SOAP end point.

And so Swagger kind of gives us for REST APIs, right? So for JSON based APIs for instance. And so what we're looking at is how can we use stuff like Swagger in public web APIs, and then generate or scaffold Angular specific services and so on based on that. So really, to create a broader end-to-end Angular story into Visual Studio.

So what I got from that is that we should go back to SOAP.

[Laughs] I hope that it wasn’t what you got from it.

Speak into my soul.

Wow. Talk about reading into a question, man. [Laughter]

The productivity gain that SOAP actually provided for people that was consuming SOAP services. And so I know that in the Java world, there was some tooling there that could help with that in Visual Studio from the very beginning, had great support for dealing SOAP. So both for authoring and also for consuming SOAP services.

So I'm not saying that SOAP was either good or bad, but the developer experience. There were some elements of that that sort of got lost when everything became RESTful and there's no description of it. And as a developer we have to go and read the documentation on API and then manually implement everything in JavaScript or whatever our language of choice was. And so, there's a gap today and Swagger is like just one of those things that can help with that. And there's some great Angular scenarios this can enable as well.

So maybe I'm the only one here who hasn’t heard of Swagger before, but this is a little new to me. Is it kind of similar to WADL?

Yes. It is. So it's a way that you, through JSON, statically can describe your REST API endpoint, that describes the different URLs and here’s the parameters that goes into each URL. And you know, do you need any headers and how do you define security and all those sort of things. And it's machine readable, so that you can have tooling -- like you can have a Node module or you can have Visual Studio or whatever you want -- to generate. And it's [?] like proxy class or data layer for you based on remote APIs that you're going to talk to.

So first of all, it’s really good for productivity because that's very fast -- machines can do these things very fast -- but also, it's less error prone because you let the machine do good, so you know, stuff like typos should go away. I see like this is one of things that really could lift development experiences for Angular developers or for any developers needing to talk to end points. And Swagger is the one that seems to be wining. They just came out with a version 2.0. And so it looks really, really interesting. So if you haven’t looked at that yet, I would strongly encourage you to do so.

So if you're writing an Angular application as Swagger or WADL, is that something that you could potentially incorporate into what you're doing?

Yeah, exactly. I know that there are some Node modules out there that you can use today already. You basically just give it a URL endpoint and it will read the Swagger from that end point and it will generate Angular services. So, that gives you like a great quick start. And of course, you can integrate with Grunt or Gulp or whatever you want to automate this.

If you don't mind me jumping in here, I would like to actually go back to tooling. This is really interesting. So, JavaScript is just evolving at just a crazy fast pace. And the question I have is how do you sanely look at what tools, what tooling you’ve got to bring in? What you're going to adopt? When it seems that the landscape every three years is kind of just changing and evolving so quick, it doesn’t even look the same? I mean how do you approach that with such a rapid pace of evolution within the JavaScript ecosystem?

That's a really good question. I actually get this question a lot. For JavaScript and CSS and HTML, it's sort of everything evolves very quickly right now. I think we can break it up into several pieces. So one of them being some of these JavaScript APIs coming up, say the Vibration API or Battery Status API or whatever. At some point, it becomes a W3C recommendation. And that happens pretty fast now. And so everything that's standards based and W3C approved and all those sort of things, those are a must-have. There's no way we can not do that, we can’t not add support for that, auto completion and other things to that. So that's one aspect.

Another aspect is what are the browser vendors do? And so we look at Blink and of course IE and Firefox and WebKit to figure out what are the browser vendors doing. What are sort of the new things. And we always want to be on the bleeding edge as much as we can. So for instance, my start page when I open my browser is W3C news. So I always know like what's the latest JavaScript APIs out there or CSS APIs for that matter or CSS modules, so that I can keep everything up to speed and up to… like the lates and greatest at all point. And it's really challenging because it is that fast.

what are the browser vendors doing and what does the W3C recommending.

And the third is what are people actually doing in the real world. And so, we get a lot of feedback from user voice and from Twitter, and all sorts of other places from people saying, hey, we should do add some Angular specific tooling. We wanna have better validation and better auto completion. And all sort of things for Angular specifically. And for Bootstrap, the CSS [inaudible] And so we take a lot of input and figure out, like also looking a little bit in the crystal ball, does it make sense to make a big deal out of Angular, for instance. We got a lot of people asking for it, but is it something that we would wanna spend a lot of resources improving the tooling for? And so we have to balance all these things.

I think I know the answer to that.

[Chuckles] Yeah. So the answer is definitely, we wanna do stuff for Angular, yes.

But hey, I think that's an important point you brought up because just because a lot of people are clamoring for something doesn't always mean that it's the right thing for that company to do or even for the community. Sometimes what we want isn't what we need, right? So I think just because… especially in this world of “JavaScript flavor of the week” or “web component of the week” kind of thing comes out, where you know, Angular is in that category, but how does Microsoft differentiate between, “Wow, a lot of really vocal minority people are speaking out about this.” Or is it just this thing we look at in that sense or this thing we look at and, “Wow, this got some staying power and we need to go after it.” And how do you differentiate between what's real and what's more temporary?

Yeah. That's sometimes very difficult especially early on, when projects start out because let’s take jQuery as an example. Back then, we had a lot of different general purpose JavaScript libraries out there. JQuery was one, the Dojo tool kit, we had Prototype and all these other ones. And at that point in time, jQuery hadn’t won, right?

And so sometimes when it's like that, in Microsoft, we actually ship in Visual Studio support for jQuery. And we did that right around the time when jQuery won. But we actually prepared for this maybe a year before when it was still an open question. Like, is jQuery going to be that the one all be all or what? And so we kind of just looked it, and said, “Okay, we kind of feel like the user experience around JavaScript was a little bit better than the other ones.” And it just so happened to be lucky for us, I guess, that jQuery won. But it could have been some of the other libraries.

So, we don't always know. We're humans. But we try to make the right choice based on all sorts of different factors -- and it can be difficult. And jQuery, I use that because that was the first one. We did Bootstrap as well. So at the time Bootstrap came out, there were other things, Foundation and the other ones. And then I think Bootstrap was the right choice -- but it's not a clear winner. Bootstrap is very popular, but what about Foundation? What about Skeleton? What about the other CSS frameworks? It's not as clear as jQuery was.

And I think you guys have different levels of commitment, I would say. So some other times, you're kind of just “dating” the framework. Like Knockout, I felt like you guys did some things for the tooling to light it up inside of Visual Studio but you didn’t go all the way on it. And I think that was probably a good decision with that where it's a popular framework we need to have some support for but you kind of limit where you go. But then other ones, you're not just dating it. You're kind of going for the long haul, like with jQuery or Bootstrap. Is that kind of how you would categorize Angular? Were you doing that or will it be more than the “dating” period?

I think right now, we're sort in between “dating” and “long haul.” We're definitely betting on Angular, but as you all know, the landscape is changing. And with 2.0 coming out as well, we've had to just think about how we're going to implement things to, you know, maybe have like provider models, so we have a 1.3 and 2.0 provider that will feed auto completion into the HTML layers for instance in these two different scenarios. And so we have to look at the implementation and the time we spend and the resources we at throw this because as in any other software team, the resources you throw at one feature, you're taking from something else. So it's always a balance act.

So you're saying you gave Angular a drawer in your dresser, right?

[Chuckles] Yeah, exactly. They sort of moved in, but we're still working on the implementation and it's actually starting to look really, really good. And I'm so excited for the stuff that we're going to do with Angular. But back to your Knockout point, we took a bet on Knockout and that was before there was a clear winner on any sort of data binding framework out there.

And then we sort of stopped. We figured out that this was… you know, Angular came out and Ember came out and so on. And Knockout wasn’t used as much anymore. And so we kind of stopped. We did smaller things to Knockout from that point on, because we have to react. Because if we spend time on Knockout, we can’t spend time on Angular for instance. And so it's always a balance. And that’s sort of the curse of the program manager, right? To figure out what that is balance. But hey, it keeps my job interesting at least.

so we have this free extension for Visual Studio called Web Essentials. So there's a lot of cases where we simply just have no idea, either how to create tooling for a specific framework or specific structure or W3C standard for instance, and so we wanna try it out. So we used this free extension called Web Essentials that anyone can install into Visual Studio. That’s sort of our playground and where we put all the cutting edge, very modern sort of web technology just to see how it lasts. Will it stick? Does users like this?

And we iterate on it, and we get feedback and we get community contributions. It's all open source, so the community help is out there. And they tell us what they like and what they don't. And they give us a pull request to fix stuff. And at some point, when the feature is baked, we can move it into Visual Studio proper. And so some of the Angular stuff actually started in Web Essentials, so then later on was… now we're moving it into Visual Studio proper. So there are different ways we can get around our… our “ignorance,” I was about to say, but when we have those things where we simply don't know who’s gonna come out on top of these different frameworks and so on. Makes sense?

Mads, how do you support let’s say Technology X, but do it in a way that it doesn't come at a cost for let’s say Technology Y and Z? So obviously, Angular is a really strong framework. It's doing well. But, let’s say you had somebody who wanted to do a .NET/Ember project, is how would you support Angular without being restrictive and forcing developers down a certain path?

That's a good question because a lot of people, they want zero restrictions and zero guided paths. They know what they want to build and they know what components they wanna use. And then you have another group of developers. They sort of look for a prescripted path. And so we have to cater for both scenarios. So when we come out, say, “We suggest that you use Angular and Bootstrap.” That's our official statement. Like when people ask, we actually say Angular and Bootstrap.

And for some people, that's not what they want, so we have to make sure the tooling works if you wanna… let’s say wanna replace Angular with Ember for instance. So the way we kind of go about it is that the foundation or the fundamentals of what constitutes a good IDE -- in this case, Visual Studio -- has be in place. So for JavaScript, HTML and CSS and LESS and SASS and all this source stuff, we have to make sure that at the bottom of everything, that we have a super solid foundation. So that when we wanna add features on top of that specific to Angular or Ember or whatever that might be, we can do so without sacrificing anything else, because the level of support that’s general, that’s shared across any framework -- JavaScript framework for instance -is super high.

So, we don't look at it as we're sacrificing Ember for Angular. We looking at it as we wanna create the best experience for Ember that exists. That is the goal. And “insert your framework of choice here.” That experience in Visual Studio for your favorite framework should be the best that you can get from any IDE. What just we're saying is we're going to add a little bit extra to Angular. We cannot be specific to each framework out there because there are literally thousands of frameworks. So we cannot add specific tooling to all of them. We have to pick and choose. And so we’re doing that with Angular, but we're not doing it by sacrificing any other experience because the foundation is sound across all of them, if that makes sense.

Great answer. Thank you.

so, Mads, we're talking about all this cool stuff, but the thing I'm looking forward to is the Angular stuff that you're talking about and what's coming down the road. I know you can’t share with us a lot of details, but what I'm asking you to clarify a little is I see a lot of cool stuff coming out of Project K and its all server based. And I saw the tag helper stuff that Damien and Scott Hunter have talked about in different podcasts, which is all server based generation of client code. But what kind of things do you see or envision that could happen for the client side space -irregardless of what's on the server?

So for the Project K, you were mentioning. That was the codename for ASP.NET -- the next version of ASP.NET. So yeah, we can have the… since ASP.NET of course is a server driven platform and language, we can let the server add some stuff for the clients. And that's for our productivity gain. That's also for… basically what we've built with ASP.NET is to have Angular directives or actually web components on the server. it's really, really cool. So the W3C web components and Angular Directives are sort of similar in some aspects, right? And we're going to have the same capabilities on the server.

And what's really cool about that, we can use the server to get us familiarized with the notion of custom elements and attributes and all this sort of stuff. And I have that generate Angular code for instance, or web components code. And then slowly, we can sort of let the user do more and more on the client side. But you know we can introduce them to the concept and make them productive from day one, using the server. So that's one aspect and I'm really excited about the possibilities there, actually.

On the client side, there's a lot of the things we can do. And I think we have this technology in Visual Studio called Browser Link. And so Browser Link a web socket connection to any browser. So what Visual Studio is doing is that it's actually opening a web socket end point in the Visual Studio process itself. And so, any browser -- without any plugins -- can then communicate bidirectionally -- back and forth -- to Visual Studio. That means Visual Studio can send JavaScript to be executed in the browser, and the browser can send back information to Visual Studio, that will then make Visual Studio react to whatever that might be.

And for Angular, there are a lot of things that makes it hard to get started with. Or maybe not hard, but there's a lot of gotchas. And something really silly, but forgetting the ng-app attribute is just one of those things that we see over and over again, that people waste like hours figuring out, “Why can’t I make Angular work?” And then they figure out they forgot the ng-app. What would be really nice is if Visual Studio could just tell you immediately right there that, “Hey, you forgot this attribute that's why nothing happens.”

You have to remember that Visual Studio have to cater for server side like for ASP.NET, right? So that means that statically, it's not really possible to analyze what the response is gonna be. We have to actually serve it in the web browser through a web server to figure out what the actual rendered output is going to be. What’s the DOM going to look like. What's really cool about the browser link technology is that it lives inside the view port. It lives in the DOM. So, it can access everything on your web page, and send information back.

So very, very quickly, we can identify issues or these could be issues like, “Hey, Angular doesn't work because you forgot about something,” or it could also be, “Hey, we’re noticing that you're doing certain things, but there might be better ways to do the same thing in Angular.” Like Angular specific stuff. And we can start flowing that information back into Visual Studio in real time. Like we're talking milliseconds here. So what’s really cool is that after you just write some of your templates or a controller of what it might be, we can immediately give you the feedback directly within the JavaScript editor, HTML editor. Saying, “Hey, this is not the optimal way of doing it.” And we can even have a way for you to fix it as well.

So I think a lot of the sort of next generation web tooling will be more in this sense. Like more a holistic end to end analysis of what the webpage is actually doing in real time. I think you know, we can do that for Angular, and we can do that for Bootstrap -- we can do that for all sorts of things. And I see that is gonna come in and it's going to more and more important going forward, because it's not about Angular any more. Angular is one piece of the puzzle. There's a lot more to it. So it's difficult to isolate just Angular and say we're only going to concentrate with Angular. That's only part of the story for your website. There's a lot more other things going on.

And so I think in the next two three years, we're going to see a lot more -- not just by Microsoft and Visual Studio, but I think across the board -- it's gonna be much more like holistic analytics and those sort of tooling efforts that's coming in. Because at that point, everyone is going to have auto completion and all these sort of stuff for Angular, Ember and “insert name here.” So, I think that's the main difference and it's going to be huge productivity gain.

I think there's a lot of really exciting things happening right now in this whole space. I think what's cool to me is the recent announcements about Microsoft going open source and .NET and all these great stuff and ASP.NET and vNext or whatever version it's going to be called. This is great, but the cooler thing with me is how it seems that Microsoft and Google on the open source world, there's just more of this communication. I don't know if it's always existed in back rooms of bars with cigar smoke before, but it seems to me -- from the outside looking in -- its more visible, the kind of conversations that are going on between these different companies in the open source community. Because I know when I was in Microsoft, it’s like, “What's an open source?” And now, you guys got a whole foundation there based upon it. Is that the direction you see everything moving into more open, more collaborative?

I do. So on the ASP.NET Web Tools team over here in Microsoft, we've been doing open source and sharing ideas in the open and coding in the open for years now. And we're seeing now like a lot of other teams, they are doing the same thing and it's awesome. But we also see it, I think, is this a general trend where like the big companies out there… we are better together as a unified community, right? Gone are the days where you could say, “I'm a Microsoft web developer because I do ASP.NET.” Because you just don't do ASP.NET -- or PHP for that matter, whatever it might be -- you also have to use Bootstrap and Angular or you know all these different tools. You use Grunt and Gulp, and Bower.

And so your tool chain is now so spread out, you know, it’s coming from all over the world, it's all open source -- and it's a better world because of it. And I think like a lot of the big companies are realizing that. And so everyone seems to be moving in that direction. I think it is great. I think this is the best time being a web developer, as far as I can remember back. And so and I'm very excited about this.

Because it looks like everyone just wants to make the world better, right? And so the competition becomes, “Well, who can make the world the world better first? [Chuckles] Who can have the best tooling for Angular first? But hey, by the way, let’s open source it the same time.” So everything becomes better for everyone, and now it's just a race of who can implement things first and so on, which is really exciting because it really brings competition back. Like if you identify yourself as a Microsoft Web Developer, in the past, you wouldn’t have looked to these other stacks and other tools.

And so where's is the competition then? You can just wait for the next thing coming out of Microsoft or JetBrains or whatever other… like if you're not a Microsoft web developer. But now, because everything is in the open, the tooling and the competition is now more fierce than ever. And you know as with the competition, the winner is the little guy in the end. We all win from that. And so I think this is so exciting. And I think we've just scratched the surface.

So I wanted to talk a little about the TRX thing, the Task Runner Explorer that you guys have put together or use specifically it sounds like. And I'm going through Scott Hanselman’s blog post here, which we'll put a link on the show for. And I see there’s stuff like Grunt files and Gulp files support and Bower support. If you could hit some of these specifically, I know early on when I tested some of this, it wasn’t reading the files right. I know you made some fixes to that on the betas. But if I use Task Runner Explorer in Visual Studio to run Gulp or Grunt, do I lose anything over running it through terminal? Is there anything I can’t do there? Or on the other side, is there anything I can do in Visual Studio with this plugin that I can’t do through terminal?

Yeah. So we've been very specific when we started writing the support for Grunt and Gulp into Visual Studio to make sure that it has to work with just with your regular Grunt file. Everything that works from the command line has to work within Visual Studio. And that nothing Visual Studio specific should be added to your Grunt or anything like that -- Grunt file or Gulp file -- for it to work. This was absolutely paramount. So the was that I could take any web project on GitHub, clone it to my local machine and start using the Visual Studio tooling for Bower, Grunt, Gulp, npm and so on to make it work. That paramount and that's how it works today. So we are still in the beta phase, we're not completely done yet. But that was absolutely paramount. So that was one thing.

The other thing was if you were to use those tools, because you can use them on the command line, so what is the purpose of adding this stuff into Visual Studio if you can use the command line? It has to add value. So the idea is that you can keep using the command line. So since ASP.NET 5 now runs on a Mac and all this sort of stuff. So imagine you have a team where you have one person in Visual Studio, and you have one person on the Mac sitting in Sublime Text. And the person sitting on a Mac should use the console -- the command line -- to run all the Grunt tasks for instance. But the person using Visual Studio can get this [??] for saying, “I don't like to use the command line for certain things. I'm going to use Visual Studio for that.”

So if we made it super simple. You can just have… we have a little Test Runner Explorer that lists all your Grunt and Gulp tasks, and you can just double click one of those tasks to execute it. That's a simple little thing. But what's more important is normally in IDEs, you have a lot of different gestures that you could do all the time -- sort of in your muscle memory. So in Visual Studio, you hit like a keyboard combination and it takes off a build. And that build takes like a couple seconds or depending on the complexity of your app. And what we want to make sure is that you probably have a built task built in Grunt. Grunt build. Wanna make sure that you can associate any Grunt task, or even Grunt target to an event that happens in Visual Studio. Such as I wanna build, before build, after build or if I clean my output. So you probably have Grunt cleaning somewhere.

So the really cool thing is that you cannot [??] to all that, and your muscle memory stays intact. When you hit the keyboard shortcut that builds your app on the server or the server code, the C# for instance, afterwards or before -- that's up to you -- it also kicks off the Grunt task. And so this is really cool for productivity, and also easing people in to using those tools because they don't have to learn new gestures or anything. They can keep using it the principles that they have known for years for software development using Visual Studio.

And then the final thing is Grunt Watch. Grunt Watch is really cool. It's sort of this file system watcher that makes sure that every time you change the file, that it then runs the right Grunt task or Gulp task to do bundling and minification and compilation of copy files and so on. And what we're doing there is saying, “Hey, when you open up the project in Visual Studio -- your web project -- it automatically starts to watch tasks,” because that's probably what you want. So you can set it up to do that. And we then have this console where all the output is streamed into Visual Studio. So there's a console there. You don't actually need the console at all, to do any of those stuff. But what's cool is because we sort of executed in the context of Visual Studio, we execute Grunt and Gulp, the output, we can start analyzing.

So we're looking into is when you run JSHint or you run Karma, Jasmine tests or whatever, that we can scrape that output and give you immediate feedback directly within Visual Studio. So if you're in a JavaScript file, you forgot a semicolon, you save the file, we can immediately give you that JSHint warning right there in the editor where that semi colon is needed. So you don't have to always go to the console to see what happened. And you forget about it, then you have to come back and all these sort of things. It just becomes a normal part of the workflow.

And the same for tests, right? We had like in Visual Studio, we have this test explorer or test window where all your unit tests are. We can start feeding all the information in from Grunt and Gulp about your tests, and have a full integration there. So the idea is that you decide at what level you want to use Visual Studio tooling. And sometimes, you just wanna use the command line. But you decide at what level you wanna have Visual Studio to help you out. And that's important.

So, that brings up a lot of interesting questions. That sounds all great. And I wanna make sure understand something. So when I'm using Gulp and Grunt or one or the other, I probably wouldn’t have both, right? [chuckles] in my project in TRX. Would I be modifying those files? So when I add those post build, prebuild, or things like that inside of Visual Studio or TRX, would they be modifying the Grunt or Gulp file or where is that stored?

Yeah, so we've been [chuckles] back and forth on this for a long time. And what's happening and the solution we're going for is that it doesn't change the Grunt or Gulp file, except that it adds comment at the very top. And that's basically just a commented out JSON object that says, “After build, run the name of this Grunt task.” And we have to save it in the Grunt file or the Gulp file js itself because there's really no other ways to put it. Because you're going to have a Grunt file that’s part of your project, right? It's in the project route.

But then you can have a Grunt, instead of putting it there, you can put it higher up in the folder structure. So let’s say you have two projects. You wanna have it above those. So there really is no… the whole notion of a project, granted Gulp has no idea what that means, it's just a file in disk and you can run it, but the idea of projects doesn’t exist, so we have nowhere to store this. And so adding a comment at the top is sort of the only way we could do this in a good way.

Okay. So that's cool. So you’re a little bit intrusive but it's not to get in my way of my coding in any way -- which is cool.

Exactly. And if you delete them, you just use the bindings to the events of Visual Studio. No harm will come of it. So it's up to you. We're actually looking into are there other things we can do, like store the information in a separate file somewhere next to a Grunt file or Gulp file js.

Yeah. I don't know how I feel about that because that this thing is if you create yet another file, it's just one more thing I've got to maintain somewhere. So I kind of like the idea of maybe you can put a comment on the bottom of the Grunt file. Get her out of the way. [Chuckles]

Yeah. Exactly. So we're looking at optimizing that and figure out what's the least intrusive we can do that.

What do you think about, you guys mentioned Bower and testing, I've got two questions on there, and I'll kind of let you answer them is I've seen some of the Bower integration you have now, and the direction I'm leaning people towards -- and maybe this isn't the one you guys want -- but if I'm building a package and instead of using NuGet for clients and libraries, I'm talking Bower these days. So even in Visual Studio, which the hesitancy I have there is in the past, Microsoft has wanted to create tooling.

And they kind of said, “Well, we like this thing, like Bower but we're going to make you go down this particular road with it.” If I use Bower with Visual Studio, do I get the autonomy to use it the way it's intended? Meaning, I can put the Bower folder anywhere I want to install web components and use the full power of Bower? Or am I restricted in some way? And then the second question is related to Karma. Can I do Karma running of tests with Angular inside of Visual Studio and see all the, you know, my thousand tests with the red/green and all that kind of stuff?

First question first. So for Bower, just like with Grunt and Gulp, it should work exactly like you want it to work. Everything you’ve been doing in the command line should be supported, right? I should be able to clone any website on GitHub that uses Bower, and it should just work. And so that's the philosophy here. And it does just works. So it doesn't have the legacy that NuGet kind of brought, where it was very opinionated about what folders to put JavaScript in and things like that. There's nothing like that. You can drop a bower rc file and rename the folder, and the tooling will still work. So that's the idea. You use it exactly the way it was meant to be used and visual will just do that -which just support you in doing that. That's very, very important.

And so the reason why we're saying, “Okay, let’s do Bower instead of just doing NuGet,” which just sort of have been the approach before, is that everything is everything is on Bower. The world is on Bower. And the better experience is right there. So why reinvent the wheel? Like the internet already decided that this was a good idea. So at the end, the internet wins, right? That's just how it is. So, why try to force a lesser experience onto people, when there already are good experiences out there. Now, granted Bower has some problems, right?

And you can use npm in the exact same way. And you can use npm instead of Bower if you want that for some of the packages and we will support that equally. You get full auto completion for package names that we get directly off from the npm registry and from the Bower registries as well. So we give you that full editor experience. So when you just edit Bower JSON or package JSON, we give you that full fidelity auto completion, not just for the structure of the JSON file, but for the individual package names that you want. And so it's really a rich experience. And again, you don't have to go to the command line. Just save the file and things are being installed for you.

I don't think you can hear that, but that's the sound of all the developers listening, clapping and saying thank you for not forcing us into a corner. [Laughter]

Yup. [Chuckles] That's great. So the other question was “What about your karma tests?” So we don't have that yet. And so the idea is that the Test Runner Explorer in Visual Studio which is what runs all your Grunt tasks and Gulp tasks and so on, is completely extensible. So I'm already talking to people that wanna build support for other things than Grunt and Gulp. So we have some scriptcs build systems out there, Broccoli, Brunch and so on would be interesting to pull in. It's extensible.

What's also extensible is the way that you can you can write an extension that reads the output from the console, and identify maybe using regular expressions or however you want to do that. It can read the output from Karma, and says, “Oh, this karma test failed and this succeeded and so on.” And then integrate that with the entire Visual Studio extensibility APIs, right? So there's an extensibility API for the test adapters that runs that gives you that test window in Visual Studio. And so you can flow everything through there.

And now, we know the names of all your tests, right? So we can list the names in that window and you can just double click it or they will run that. Because the Test Runner Explorer is nothing but a proxy for the user -- between the user and the command line. It doesn’t actually do anything on its own, it just calls the command line. So it calls the exact same commands that you would do from the command line. And so everything that we can find out through the command line or by parsing your Karma or whatever you want, we can flow in and the make a first class citizen of inside Visual Studio. We're not there yet, but that's definitely on the plan. That would be so cool.

Awesome.

So I just have a quick question: if you guys are already looking at AtScript.

I know that they TypeScript team here -- which is not part of the ASP.NET and the Web Tools team, unfortunately -- I know that they are in conversations with the Angular team about figuring out how to do this, but I have no idea.

Good answer.

All right. Any other questions before we do the picks?

There is something that always comes up that I might just answer. I'll ask the question and then I'll answer it myself. [Chuckles]

Okay.

What about Yeoman? So short story, we do not have Yeoman support in Visual Studio. We actually do have a prototype that the MS Open Tech have built, so I assume that's open source somewhere. But we're not planning on building that into Visual Studio, because we sort of have our own template system there.

However, for ASP.NET 5 -- the new version of ASP.NET -- we actually have Yeoman generators for that. So you can go in and say yeo generate ASP.NET and you can create an MVC application or NancyFx application or something like that, and have everything scaffolded. And that's all developed in the open on GitHub. And it works really well. We're going to put our stuff at Yeoman but we're not necessarily going to have Visual Studio integration for Yeoman.

Cool. All right, well let's go ahead and do picks and stuff. Lukas, do you have a pick and a tip for us?

I do. And I'm actually going to combine them. So I was working on the sample application for AngularJS In Action and upgrading it to 1.3. And I've been using the ng-messages and it's just a really nice sub module. And before, I had to do a lot of ng-if this [??] show this or ng-if this, and so it was just kind of a lot of… it just became [??]. And so, a big shout out to Matias and the team. They did a really good job in 1.3 with the Angular forms and specifically ng-messages. So if you're not using it, look into it – yearofmoo.com – he has a great article. It's just a really nice tool to have in your toolbox.

Very cool. Joe, what are your pick and tip?

So my pick is going to be a book I've reading recently called Strong Fathers, Strong Daughters. So if you happen to be a father listening to this podcast and you happen to have a daughter -- or might have a daughter soon -- I highly recommend this book. Great book written by a medical doctor about the effect of fathers in the lives of their daughters. Really enjoying it.

And then my tip is going to be Plunker. if you don't know Plunker, learn it because it's awesome especially for Angular.

All right. John Papa, what are your pick and tip?

So I've got some picks here. Basically it's the whole connect event that just had the Microsoft team, I think it was last week. It's been a blur. It could have been a year ago. Right now, my mind is so wiped, of doing open source for .NET. And they basically announced .NET has been open sourced, which means that the way I interpret that is Mano may no longer need to be a major player there, because [??] and .NET on Linux/OS X and all that fun stuff.

And now, Visual Studio is they got a new edition called Community Edition which the way I read that too is it's going to be free for a lot of people like education and students and the small businesses, and the enterprise versions as well. But the important part is the community edition is not only free but it's not crippled either like some of the former versions like the Express and things like that. And go check out the Connect event. That's the second half of that pick is I would put some links here in the show, to go watch some of the videos. But it's pretty amazing the turnaround that the Microsoft community has done over the last couple years.

And I guess my tip for the Angular side is I've been immersed -- totally immersed -- in the build process recently for Angular and JavaScript. And recently, I just rewrote a bunch of my Gulp commands to use wiredep, filerev and usemin. And I've found that, wiredep, not so much, but usemin and filerev really made my Gulp processes much simpler and easier. Where I was actually able to eliminate like 100 lines of code out of my Gulp file. So my picks of Angular are get to know things like usemin inside of Gulp and the filerev.

Awesome. I've got a couple of picks. The first one is the Entroprogrammers podcast. I was a guest on it two weeks ago. And then last week, they actually invited me back to be a permanent member of the panel/mastermind group. And it's a fun chat. So I'm going to pick that.

And then my tip is I’ve found a countdown timer for Angular, which uses a Directive and it was really easy to setup. So I'll put a link to that in the show notes. It's angular-timer. And hopefully you’ll like that. Mads, do you have a pick today or a tip for us?

I have a pick, yeah. So I've been playing around with the JSON lately – a lot. And you know, one of the things with JSON is that sometimes you have a specific format that you need to adhere to. So let’s say write a Google Chrome extension, right? You have a manifest JSON file. And that's where you specify all the different settings and so on for your chrome extension. Now, it's really easy to do typos or forgetting certain things in files like that. And so that's why JSON schema exists is to help us out with that.

And so what I've been using lately is a Node module called [TB4?]. It comes as a Grunt task as well, but it actually helps you… you can set it up through your build process to make sure that all your JSON files are adhering to a schema, so that you can avoid like stupid mistakes and typos and stuff like that. So I think that's great. The world needs this sort of stuff.

Awesome. All right, thanks for coming, Mads. It was fun to talk. And I know a lot of people are out there using Angular with Microsoft technologies. And so, I think this will really help give people some direction on what capabilities are there and what's coming up.

Awesome. Thank you. It's my pleasure.

All right. Well, I don't think we have any announcements. And Joe took off before I could ask him about ng-conf, so be excited for that. We'll catch you all next week!