Editor's Note: Welcome to .NET Rocks Conversations, excerpts from the .NET Rocks! weekly Internet audio talk show. This month's excerpt is from show 731, with Scott Hanselman, principal program manager lead in the Microsoft Developer Division, who makes the case for why the diversity of ASP.NET -- comprising Web Forms, ASP.NET MVC, Web Pages, and many other tools -- works for developers' benefit.
Carl Franklin: What are you doing lately that's really got you excited?
Scott Hanselman: I work for one of the many Scotts at Microsoft right now. So I work in Web Platform and Tools, which is now Azure. Actually a lot of people get confused about that. I was talking to some folks at a presentation I gave in Canada recently, and they said, "So, Scott Gu left. Where did he go?" I was like, "Well, no. Scott is in Azure." "Okay. Where are you guys? He left ASP.NET, right?" "Well, no. He took all 600 of us with him." So in fact, all angle brackets are underneath Scott Guthrie, which is cool. So any angle bracket or curly brace generation is still under Scott Guthrie. So ASP.NET, IIS, all of us, we're all in Azure.
CF: So Azure, then, I guess, has expanded its definition of what it manages. Is that what you're trying to say?
SH: Well, I guess I would say it's that you can either say we've moved under Azure, or Azure has moved over us.
CF: Yeah, and that's what I'm thinking.
SH: Right. So like before there was Azure and then there was IIS, ASP.NET, and we're different divisions. Now, since Azure is like Windows in the cloud, and ASP.NET is one of many end nodes and all these other things -- or things to make curly braces and angle brackets from either Windows or Azure -- we're kind of all in the same group, so really it's more of an organized thing. So it's actually pretty cool. It's worked out pretty nice. We had a very nice release of Windows Azure with lots and lots of new improvements and better publishing and faster performance, and Node and open source in the cloud, and the SDKs that are on GitHub.
CF: Node is especially cool and getting a lot of lip service these days. We did a show on Node.js, and man, just very exciting stuff, and now, of course, Azure has fully embraced it.
SH: Yeah. And Azure is not about Node, but Azure is about making anything that could go in the cloud awesome in the cloud.
CF: Yeah.
SH: So I know that Node is really exciting. Node.js, is, of course, the server-side JavaScript. But people then overreact and think, "Well, that's just a new thing. Do I need to know that? Is that something that I need to throw away all my ASP.NET and start doing that?" It's just another kind of vehicle. If someone came out with a three-wheeled car, are you going to throw away your four-wheeled car? It's a different kind of a deal. Node is cool, but it's a tool on the toolkit. So I really want people to start thinking about carrying around a toolkit of a number of different things. One is Node; another one might be SignalR, which is the real-time framework that we use in ASP.NET that gives you Node-like real-time long polling and web sockets for ASP.NET, and it doesn't require you to have any Node if you don't want it. There are a lot of tools out there; use the one that makes you happy, is the point.
Richard Campbell: Well, I guess my question then is, what else is a tool in that catalog? You've mentioned Node and SignalR. Are there other comparable tools? I mean awfully different, but comparable.
SH: OK, so comparable tools to Node. There are a lot of frameworks that do real time. That's just one aspect of Node. The other aspect of Node is being able to do non-blocking I/O and having an event model that makes sense to the JavaScript programmer, and then also things like . . . like I said, "real-time" is in quotes, kind of real-time communication, but long polling or WebSockets style of communication. If you wanted to get into that kind of stuff and do it in ASP.NET and didn't want to mess around with another framework, you'd use SignalR.
RC: Right.
SH: And that's kind of one of the "pillars of .NET" -- in my opinion, the new .NET. I'm trying to think about ASP.NET in a more unified way rather than a bunch of different frameworks that end up splintering the community -- where there's Web Forms people, and they never talk to MVC people, and they never talk to Web Pages people. We've got a lot of tools in the ASP.NET kit: Web Forms, Web Pages, MVC Web API, WCF Web API, SignalR, jQuery Mobile, and on and on. Knockout.js. If you were to pick just one, then yeah, ASP.NET would be kind of the lonely world. But if they all work together really nicely and you could pick one here and one there, then that would be pretty cool.
In fact, you can. So if you're putting together a website, and you want to do the whole thing in Web Forms, cool. And then you want to add a real-time chat system, add SignalR. And then you want to add an API and maybe make like a Twitter Web API and do some JSON, maybe throw in Web API. And then maybe you want to add some dynamic pages that someone could change really easily, like a poor man's CMS, you might throw in Web Pages and CSS/HTML files. And then you might want to do some client-side data binding, put in KnockOut.
Someone might say, "Well, that's a hybrid application. You're building some kind of Frankenstein monster." It turns out, that's how people do work. They use the tools that they need. So rather than, here's a hammer, start pounding on screws, I want people to really think about the rich tools that ASP.NET has developed into and stop thinking about silliness like MVC versus Web Forms. Does that make sense?
CF: Yeah. I think your main point is a really good one, which is that people tend to think, "Oh, I've got to choose one thing." People tend to think, "OK, well, I'm using that, and this is dead."
SH: Right, exactly.
RC: You just mentioned the weirdest one, I think, of the bunch, which will be mixing MVC and Web Forms together.
SH: Which isn't actually weird at all.
RC: OK.
SH: There are so many sites that do that. There are so many people who do that. I mean, Web Forms, you've got this component-based system that has a very easily composited technique. You can bring in a piece of functionality. It's going to occupy a square on the page, and it's going to have both client- and server-side components, and that's a useful thing. If you want to do a line-of-business application or get stuff done quickly, that's a really great way to do it. MVC is a really great way to control every single byte on the wire. But features that are cool in MVC also find their way over into Web Forms, like Web Forms in .NET 4.5 has model binding. If you remember in 3.5 SP1, they got routing. Web Forms and 4.5 get unobtrusive JavaScript. We're going to see some really cool jQuery controls coming soon. There's lots of cool stuff that you can do in Web Forms, including HTML5.
Now some people might say, "Oh, well, Scott is just trying to convince us that we should still care about Web Forms, and this maybe is some kind of weak attempt to, like, astroturf the discussion around Web Forms." The point I'm making is [to] use what makes you happy, and there are lots of things to choose from. But arguing about Web Forms versus MVC is really arguing about regular screwdrivers versus Phillips screwdrivers.
RC: They both drive screws.
SH: And they both drive different kinds of screws.
RC: I keep thinking, "Hey, I want to support that point that I think we made." [We meet] a lot of folks when we're out at conferences who are building apps with Web Forms, and it's not just legacy. It's what they know. It's how they're productive. They make stuff that way. But most of the time when I hear about Web Forms and MVC combined, it's a migration path.
SH: Yeah. I understand why people think that, but I don't think that it has to be a migration path. A migration path implies that I'm going somewhere, and I'm leaving behind something that I don't care about.
RC: Right.
SH: And I think that's an overly simplistic way to look at it. If you're migrating away, sure, yeah, do your thing. But the point I'm trying to make is, use the parts of the tool that make you happy and [that] work for your company, and remember that it's ASP.NET underneath. Like, this isn't five, six different competing products.
RC: Right.
SH: This is five or six subsystems that sit on top of a product that works quite nicely, and ASP.NET is what folks are selling here.
RC: Yeah, in the end it's all ASP.NET. One way or the other the pipeline is involved.
SH: Yeah, absolutely. And that's the lowest common denominator. That's the base of the pyramid, and if you go even further, it's IIS. I mean, what makes Node really run well on Windows? Well, Node runs great on Windows by itself, but if you really want enterprise-level Node, you put it under IIS, and then you get recycling, and you get better-processed lifetime, and you get multiple processes that can be spun off based on load. I mean, you get all of the cool IIS stuff, which [are] the same nice features that ASP.NET gets. You kind of get the idea, right?
RC: Yeah. But doesn't it actually . . . and then you throw Azure into the mix, which sort of changes IIS and the whole underpinnings to some degree.
SH: Yeah, yeah. Absolutely.
RC: I mean, is that part of the story now -- that I could have a clear migration path over to Azure as necessary?
SH: You know me. I always try to keep it real, and I always try to make it really clear that I'm not ultimately selling anything. Everything in our group is free. Microsoft just wants you to buy Windows. So as long as you buy Windows, that's fine. I don't really care. But I wouldn't say it's migrating over to Azure, as is having a choice of deployment should just be a matter of picking it. If you look at Scott's presentation five virtual weeks ago, he basically filed a new project and made an MVC project, and then said I'm going to publish it to Azure and did. It didn't involve a bunch of machination to try to make the thing a special Azure thing. He just said Azure was a target. So migration implies a big deal while simply targeting a different place.
RC: Yeah. So Azure is just another web server you could target, the same way you could shift from your testing server to your production server, and so on.
SH: Exactly. Right. And Azure has virtual machines that you could target. You can target IIS, or you can target the classic kind of Azure services that are web services. It's up to you.
RC: But you know, I think Microsoft is partly responsible for this competition between the platforms because you just said it yourself, file new MVC project versus file new Web Forms project.
SH: Yeah, yeah. And I think that I would prefer, and I've said this many, many times before, so this isn't giving anything away, but I've said many times before that when you say file a new project, it's too imposing. It's too scary because it implies this false decision that needs to be made.
RC: Right.
SH: So wouldn't it be nice if you could file a new project, and to see one thing and maybe like some check box or something. I don't know.
RC: Because in the end, if you create a Web Forms project, there's no reason you can't add the MVC libraries and start building MVC-based pages.
SH: Yeah, yeah. I suppose. Why not?
CF: So you think the evolution of Visual Studio should be that we shouldn't have to know our tools before we use them?
RC: Nice.
SH: No. I think that when you open up your toolbox, you should see a nice organized bunch of tools that can allow you to use them together. The organization of the toolbox when you open it up is very scary. It's like, "Whoa, there's a lot going on here. What am I going to do?" I think that's unfortunate. So there are things that we can do to organize the tools in such a way that they're not so frightening.
There's much more! You can find the full interview at dotnetrocks.com/default.aspx?showNum=731.
Richard Campbell and Carl Franklin are the voices and brains behind .NET Rocks! They interview experts to bring you insights into .NET technology and the state of software development.
- Email: Richard
- .NET Rocks!
