Text transcript of show #254. February 17, ASP.NET Web Forms - Reports of my Death have been exaggerated, with Damian Edwards

Transcription

1 Hanselminutes is a weekly audio talk show with noted web developer and technologist Scott Hanselman and hosted by Carl Franklin. Scott discusses utilities and tools, gives practical how-to advice, and discusses ASP.NET or Windows issues and workarounds. Text transcript of show #254 ASP.NET Web Forms - Reports of my Death have been exaggerated, with Damian Edwards Scott chats with Damian Edwards about new features coming in ASP.NET WebForms, new techniques, controls, model binding, HTML 5 and more. (Transcription services provided by PWOP Productions) Our Sponsors Copyright PWOP Productions Inc. Page 1 of 8

2 Lawrence Ryan: From hanselminutes.com, it's Hanselminutes, a weekly discussion with web developer and technologist, Scott Hanselman. This is Lawrence Ryan, announcing show #254, recorded live Thursday, February 3, Support for Hanselminutes is provided by Telerik RadControls, the most comprehensive suite of components for Windows Forms and ASP.NET web applications, online at In this episode, Scott talks with Damian Edwards about new features in ASP.NET Web Forms. Scott Hanselman: Hi, this is Scott Hanselman and this is another episode of Hanselminutes. Web Forms, the reports of my death have been greatly exaggerated. That is the title of today's show and we've got Damian Edwards. How is it going, Damian? Very well. Thank you, Scott. Scott Hanselman: You know we actually had your buddy, Tatham, on a couple of months ago talking about Web Forms and stuff. You guys worked together on the Web Forms MVP Project before you went to work for Microsoft. Is that right? That's correct, yeah. Scott Hanselman: You guys are smart guys. I mean you're advanced alpha geeks I think. Are you guys that way? I mean if I may be so bold, you know. yeah. I might describe it that way, Scott Hanselman: I mean you like your things in a certain way and you're very opinionated in the way that you program. Sure. Scott Hanselman: I think there are some people who might have a misunderstanding about Web Forms and why would you even bother with Web Forms. There's so much hype right now around MVC, but if you look at the stats I think that probably big, big numbers, 80% of people are still using, 90% are still using Web Forms even though MVC is kind of the new sexy thing to talk about. Why do you think that the alpha geeks are going in one direction and why is Web Forms getting a bad rap? That's a difficult question. I think the alpha geeks tend to pick on many different things about Web Forms. I mean Web Forms is very good at doing particular types of things and doing those very well, and if that suits your purposes then there's really nothing wrong with using that. Then coming back to why people sometimes may pick on Web Forms for various reasons, we have to remember that Web Forms really was designed to be an abstraction over the top of the core raw particles that are involved when you're building web applications so it really abstracts away the idea of HTTP, of doing Get some posts, and even to a logic stance to dealing with web browser. I mean we really don't see an awful lot of HTML, we don't see a lot of JavaScript that the developer has to write and let's say where they want to get under the covers. I think a lot of people, when they see that abstraction start to leak, they use that as a reason for supporting the whole sort of platform down. Whether that's right or wrong I guess will depend on your circumstances, but I think those are some of the things that people have in the past pick the Web Forms for. Scott Hanselman: Well, so are you saying that there are or there are no problems with Web Forms? Or are you saying that there are problems with alpha geeks and those personality quirks cause them to pick on Web Forms? I've got to understand like which direction you're coming with this one. I think there are problems with any platform or framework depending on what direction you're coming from and so suddenly if you're doing certain types of things, Web Forms can get in your way. If you want to be able to have certain types of control or get certain advantages out of using recanned elements, you'll find that there are restrictions and caveats that come along with doing that. That was the resurgence of, I guess in the last few years, of web programming treating web programming as actual web programming and not dealing with some abstraction over the top and the resurgence in things or the rise of things like mobile devices. We're having real control over markup and what's going across the wire from your browser to the server. People are running into these limitations perhaps of Web Forms when trying to build applications using the top level paradigms that Web Forms brings like server controls and pages. We're ripe for looking for an alternative and MVC gave that alternative and it really does shine in those areas where perhaps Web Forms isn't the best suited candidate. Scott Hanselman: Do you think that when they made Web Forms that it was targeted at -- I mean people always say like it was targeted at the Visual Basic programmer, at the drag and drop button programmer. Is it fair to make judgments about a programmer's kind of inherent ability or current skill level when thinking about it in the context of a framework like Web Forms is good for beginner programmers and such and such is good for advance programmers, or this had nothing to do with it? I think that's more about what the on wrap of that particular platform looks like. I mean how high does the concept count for someone coming into this platform for the first time and is there an easy way for them to ease into building for that platform without having to learn a whole bunch of different things like in even an output, a very simple Page 2 of 8

3 sort of a UI from that platform? In terms of Web Forms, I mean it's very easy to do the Hello World example. It's very easy to get some data from a database and display that on the screen with, you know, in this day with a fairly rich experience. I agree that it allows sorting and page, an approach back for paging and those types of things. The stand is business application UI for sure. But if you were to try to build that from scratch with raw HTML or JavaScript and some type of server-side programming, it would take you a lot longer than dragging a couple of controls on and then configuring some properties and hitting F5 in the Visual Studio. So I'm not sure whether it's certainly valid to judge whether a platform is suitable or not for various types of programmers based on their competencies or not, but I think there's certainly an element of truth to the assertion that Web Forms was built to really help the VB programmer looking at the business client of that programmer. Scott Hanselman: Yeah, not the VB language but the typical Visual Basic programmer of the early mid- '90s who was not a... That's right. They're basically used to a design surface and event driven programming and those types of things. Scott Hanselman: Right. But the thing that I'm trying to get my head around is that is it somehow -- two examples. If somebody takes a data control and drags it from Visual Studio onto the design surface, hooks up a database and they have a grid. Another person does something from the command line and generates the exact same result and creates some code that does a for loop that makes a grid except they did it using a scaffolding system. The output is identical effectively, but one of them is considered an advance programmer doing really cool stuff with the new framework and the other one is just dragging and dropping. Is it a matter of programmer bigotry where it's easy but not to easy? How is drag and dropping somehow less noble than typing rake from a command line? That I think it is. Again, I'm a big exponent of using the right tool for the right job and that includes not just what you're trying to output but the experiences and efforts involved by the people actually building the things. If those tools match all those outcomes for the things that you're trying to achieve, then I don't think it's in anyone's place to tell you that you're using the wrong thing or that what you're doing is somehow inferior to what other people are doing. I think we, as programmers, tend to be -- I mean you said before Tatham and I are fairly opinionated, that can be. Now if you look at that framework, we've made some opinionated decisions about what's there and what's not but that's not to say that I think it's the developer's job to judge other developers on these things. At the end of the day, we're all just trying to do our jobs and to write good code. Or even if we're not trying to write good code, write code that works. Scott Hanselman: Yeah. So I'm looking to see here and tell people that doing this thing is completely wrong. I will have a heated argument about it, but I'm not about to tell them that they're completely wrong and they should be doing it this way without really giving consideration to what it is that they're trying to achieve. Scott Hanselman: Yeah, yeah. It's funny that people are still teasing me about making the website for the other podcast that I do with Rob Connery, This Developer's Life. We made that website in Web Matrix. Yeah. Scott Hanselman: You know, there has been some gentle ribbing about having done that in Web Matrix because people still think that it was kind of a toy. We actually had Rob on the show and talked about the fun that we had in making that. I wonder if I had built it in Web Forms if I would have been teased from a different group. I'm sure you would have no doubt. I think no matter what technology you choose, you would likely get teased. Maybe MVC is the cool kit and it's smoking behind the backseat at the moment. No one is going to pick on them, but everything else I think is fair game. Scott Hanselman: Well, it's funny I always talk about the whole car versus motorcycle analogy, the idea that MVC is a motorcycle. It gives you lots of control and it lets you feel the road beneath you and of course you could fly off the motorcycle and really hurt yourself. But ultimately if you really want that kind of magic of driving, use MVC, use a motorcycle. Sure. Scott Hanselman: Web Forms is the kind of the minivan with a car. It's got more cargo space and it lets you take the kids to the store. It just doesn't look very good. Like myself, now that I've got kids I drive - - I like to call it a crossover vehicle. That's man-speak for a swollen minivan. But you know, I tell myself that it's okay. There's really nothing that's wrong with that because most people drive cars, most people use Web Forms, and I know that in.net 4.0 there was a lot of stuff that was added to Web Forms to make it better. ViewState got 30% or 40% smaller. You basically have the ability to have CSS change the rendering of any control using advanced templating. So even with the old funky controls that people have forgotten about like the ASP Wizard control and stuff Page 3 of 8

4 like that, you could make it output divs and UL s and LI s and stuff like that. That's right. Scott Hanselman: What's coming next though? Everyone is saying that all the hype is around MVC, but what do we know about the next version of Web Forms and then also what can you do with Web Forms today? It's interesting you bring it up that people have this perception that perhaps Web Forms isn't being the best today. I mean you just pointed out that with the latest release which is coming up to 12 months now, so it's not even I think 10 months since we released that, there was a significant investment in Web Forms in.net 4.0. You've mentioned a couple of things there. We also did work about controlling client IDs, and then there was a lot of work that went in sort of the base ASP.NET level that Web Forms got the advantage of as well. After the next version, we're really continuing on this idea of, well, ASP.NET is a foundation framework and then on top of ASP.NET sit other frameworks that plug into that depending on how you want to go about building your applications and from time to time there will be things that get built in one of those smaller frameworks that are shipped with that framework and then eventually it realized, well, this is a really good concept and it doesn't just fit inside this framework. Perhaps we could pull the cost to one of the other ones. So as an example, in the MVC world we have the idea of model binders which may pull a lot of sense in MVC. I mean MVC is very codefocused and the idea that you would use some code to access your data and then generate a model that you give to your view but then when that request from the browser is coming back in you don't want to have to do that left-hand, right-hand sort of code to take the user input and push that back into your model. So we have the concept of model binders do that for you. So we're looking at that concept for Web Forms and having a look at what's required today in Web Forms to say use something like Entity Framework code first. When if I want to, if I'm quite happy to write code to do my model management in the middle tier off to the database using something like EF code first, how do I go about using that with Web Forms? Well, today if you want to use a GridView, you'd have a couple of options. You could put a GridView on your page and then drop an object data source on to the page next to it and I could think of the GridView to use that object data source, and then you would have to create another clause that the object data source is going to look at which is the clause that would then have your code in that that does the EF code first work. Then if you needed to wire up certain inputs into those methods like your CRUD methods that would exists on that clause, you would have to go back into your page markup and declare a bunch of parameters on that object data source to pull all of those values through. So if you look at the markup, I mean you could do all this with the designer but eventually a lot of people will have to jump into the markup to configure this stuff and you'll see a lot of markup in your page. It's just that at the end of the day all you want to be able to do is call my database context.customers.get, whatever, and so we're looking at how we can make that a lot easier. So rather than having to have say an object data source from the page, you can just have the GridView and just point that directly at the methods in your codebehind and they're going to go off and do whatever it is you do to get data and then also take care of some of that left-hand, right-hand code for you so that when the user clicks the save button whether it's on a GridView row or a FormView edit template, the values associated with that action automatically bound if you want, model bound if you like, to the method that you've declared as being say the update method in that case. So that's the case. So we're looking at bringing some of those things across. Scott Hanselman: Hi, this is Scott coming to you from another place and time. Are you using Agile Practices to manage your software development? There are lots of tools in the market that manage the steps of a project but most of them focus on individual roles. Get ready for a solution that caters for the success of the whole team. The guys at Telerik introduced TeamPulse to the Agile Project Management Tool that will help you gather ideas, estimate, plan, and track progress in a common workspace. Finally, companies, regardless of their size, can use a lightweight and convenient tool that makes all the stakeholders work as a united team even if they're in different countries. By combining intuitive interface and the power of Silverlight, TeamPulse removes the road blocks that you typically face in applying Agile in an effective manner. No more lost data, no desperate systems, no lack of critical analytics regarding the health and velocity of your project. See for yourself, get a free copy for five users in one project at telerik.com/teampulse, and please do thank Telerik for supporting Hanselminutes on their Facebook fan page, facebook.com/telerik. We do appreciate it. There wouldn't be a Hanselminutes if there wasn't Telerik helping us. So yeah, one of the things when I'm running a lot of Web Forms code that I'm doing is digging around in the HTTP request. I mean that's almost half of the kinds of code that I'm writing when I'm messing around. Like you called it left-hand, right-hand code. The idea that I want to dig into the HTTP request, Request.Form, Request.Query String, pull that stuff out and stick into my object and then take that object and do something with it, that's really tedious code. It can be a huge portion of the code-behind. So with model binding, that just kind of collapses, doesn't it? It does and I think one of the other things that people pick on Web Forms for is the Page 4 of 8

5 lack of testability and it's easy to see that if you open up a general typical code-behind file for an ASP.NET Web Forms page you'll generally see a lot of this type of code, a lot of this UI CRUD sort of code. It's very hard to test because the ASP.NET base classes, the Web Forms inherently aren't remarkable. They're not easy to substitute things for to run them outside of the ASP.NET Web Forms runtime. So if you wanted to make those things testable, you have to write a layer of your own abstractions and then move all that code out into another clause and then you have to have another framework sitting there doing the glue for you. So I think model binding, in the context of Web Forms, will kind of help because any code that you can remove from your code-behind is A) less code you have to write, and, B) less code you have to test and so less code means less bugs generally. Scott Hanselman: So is this the kind of thing that we're going to see as an add-on or Futures? I mean one of the things that the ASP.NET team has kind of done lately is releasing new add-ons to things like MVC as MVC Futures. Is there a Web Forms Futures where I can use these kinds of things today? Are there other future Web Forms features that someone could be playing with after this podcast? Not immediately. If you go to the ASP.NET CodePlex file today, there is a Web Forms section and I believe the only thing in that Web Forms feature section at the moment was the CSS Sprites prototype that we shipped last year which you can certainly go and have a look at to get an idea of some of the things that we were thinking about. In terms of the release mechanisms for the things that we're talking about now, at the moment these are all being talked about going to the next version of Web Forms. Now Web Forms, we have to remember, is actually part of ASP.NET. It's not like MVC in that the Web Forms assemblies and types are actually in the.net framework base class library itself. Unfortunately, when we want to make changes to some of these things, it can be difficult for us to do the out-of-band which is a term that we use to say when we want to release something that's not part of the main shipping vehicle for.net or Visual Studio. Now that doesn't mean we can't all the time and date. When we first release the MS AJAX framework in version 1.0, that was done as an out-of-band on top of.net 2.0 at that time and then eventually that rolled back into the framework in.net 3.5 Service Pack 1.0 I think. Now for this, we're still in early planning so it could go either way, but at the moment the thoughts are we'd go into the base in the next version of the.net framework but that's not to say that there won't be other things that we can do for Web Forms before that next version of the framework comes around. Scott Hanselman: Do you think that's Sprites thing will make it in there? How many things make it into a future release or make it into the product and how do you decide that? I think it's not very different to any other software planning mechanism or exercise. I mean I've been here for a year now and I think when I came to Microsoft I really expected it to be different. I've been a software engineer for over 10 years and I've worked in lots of very big software projects but all web-based. I was a web developer and came here expecting it to somehow be different, but I can tell you that it's not. We have a list of features, we have a back log if you like that we keep adding to as time goes on. We collect customer feedback, we talk to customers, we talk amongst ourselves, we're prototyping generally, and then there comes a point when we need to start looking down features or whatever the next release or the next version of what it is that we're building is and we go through a process like any other group building software would. We do a cost analysis of how much it will cost to build a specific feature, what do we think the benefit to customers is by doing that, how does it fit in with the strategy that we're trying to adhere to, and there's really nothing, I think nothing magic that goes into that process. In terms of how we're going to make the decision this time, it will be we have a stack rank list of features that we would like to see in Web Forms. We look at how many resources we have and how much time we have and then we draw a line underneath where we can't do any more work anymore. Scott Hanselman: All right. So there are a number of things that are coming in in Web Forms. What else do we have that is moving over from MVC? It seems like MVC is rubbing quickly. It's being developed. We're already on version 3.0, and because it is out-of-band that gives us the ability to do that. With Web Forms, we're moving a little bit more slowly at least in the short term. Are we bringing other features over from MVC and incorporating them into Web Forms in the next version? Sure. So one of the things that Web Forms, sorry, MVC introduced in version 3.0 was the concept of unobtrusive JavaScript but in the form of validation and AJAX. So for the next version of Web Forms we're looking at bringing across at least the validator portion of that. Today, there are serverside controls called validators in Web Forms that you can use and drop on your page that give you a precanned validation facilities and you tie them to the controls on the page like a textbox and you say this is required. But if you actually look at what gets emitted into the HTML markup, in order to facilitate the clientside validation there's a whole lot of JavaScript that gets big arrays of stuff that gets spewed out into your HTML page when you use those things. So we're looking at cleaning that up by using the same mechanism that MVC does today whereby we rely on jquery validate to provide the client-side validation sort of base framework and then we use the HTML5 data-attributes to inject the metadata required to drive Page 5 of 8

6 that validation framework into the page directly under the controls that you want to validate. Now when I say HTML5 I'll say immediately, for people who I think know HTML5 and Web Forms, what does that mean for backwards compatibility? People have to remember that HTML 5.0 isn't just about adding new stuff to HTML. It's also about rationalization of things that were already supported by lots of browsers. I'm just making them part of the standard. One of these things is something called expand out attributes or expand out properties. I think many web developers have discovered that they can just add extra properties to their HTML elements and while the browser may not understand them and they don't quite get validated by any HTML validator, you can happily access those values from JavaScript using the DOM once that HTML is serialized or parsed I should say. So the Data-Spec inside HTML5 is just a formalization of that. So it just says any attribute on any element in an HTML5 document that begins with Data dash and then something else is totally valid. That's an attribute that you can put anywhere and the intent for you is to put any values in there that you want to be able to essentially harvest using JavaScript once the page is loaded. So people don't need to be worried about that not working in older browsers, that will work just fine and we're looking to take advantage of that to clean up some of the JavaScript that we output in terms of validation in the next version. Scott Hanselman: In Web Forms, is there something fundamental about Web Forms that makes people think it makes bad markup or bad JavaScript, or is it certain controls output different things? Do you understand what I'm saying? Like is there a control I should avoid or how can make, can I make a Web Forms application where I can say view source and have it be pretty? Well, you can definitely do that and this is some of the talks that Tatham and I have given in the past. They've been very much about this point. Now if there were in the past some controls that we would recommend you completely avoid because they just didn't give you the control that you needed to stop at outputting things like wrapping in a table tag, now back when these controls were originally developed, I mean we think back this is talking six, seven years ago now, that wasn't really frowned upon. Using tables for layout in HTML was the flavor of the day, but we know better than doing that now. So as we've mentioned before in.net 4.0, almost all that was cleaned up. If you use the.net 4.0 rendering mode, you find it very difficult to find a table in your markup that was generated by ASP.NET unless it's for tabular data, say the applet of the GridView. So it's actually a lot easier than it was back then and especially now you can control your ViewState much more granularly as well and control your client ID. It's especially much simpler to get cleaner markup. Now before that we use the party or out-of-band libraries I guess to help doing this. There was something called the CSS Friendly Control adapters. The ASP.NET was built on this foundation of an adaptable control rendering system so even if your button control doesn't output what you wanted to output, there is actually the mechanism for you to completely change what that outputs and there are a couple of ways you can do that. You can subclass a button control and then overwrite. This runs a method which is kind of the grid force or parch or you can register a control adapter which is a little bit easier, perhaps not an awful lot easier but essentially maintains the behavior of the control. But at the point where it gets rendered it will shell into your logic to go ahead and render that control instead of using the default rendering. But you really don't have to do that much these days if you're using.net 4.0 because it is just much better than the markup is. That said, you don't have to use a server control. I mean we talk about Web Forms a lot but there's nothing stopping you writing ASP.NET pages, so ASPX pages, and using user controls and master pages and that whole sort of front-end mechanism there but you don't have to use the GridView if you don't want to. There's nothing wrong with using a repeater or a ListView that is fully templatable and handwriting your markup to get the applet that you want. I mean you still get benefits in doing that. The LIstView, for example, has a lot of behavior that is completely separate from the way it is displayed. So the ListView supports paging, and editing, and inserting in different templates for all those different modes and you don't have to worry about controlling what mode it is currently in. It will just do that using the command mechanism inside ASP.NET Web Forms but you still get full control over the markup. So there is a middle ground between just giving the Web Forms pages and controls, full control over what they I'll say just delegating to them to say, hey, you render all the markup and I don't really care about that, just give me the behavior. And at the other side where you don't use any controls whatsoever and you're just back to basically running classic ASP but with ASPX in line with.net pages, there is a middle ground I think and the framework Web Forms MVP that Tatham and I put together was really designed hitting that middle ground. There is some value in using some of the built-in controls in Web Forms but if you want a little bit control around testability and around coding and patents, then this framework can help you do that. Scott Hanselman: By default, when you upgrade from.net 2.0 to.net 3.5 to.net 4.0, do your ASP.NET pages automatically start outputting better markup or do you have to do something to tell them that? You have to do something. Unfortunately that would be a breaking change and we try to avoid the breaking changes when they're associated with an upgrade process. So if you start a new.net 4.0 project, you will get the new rendering. Page 6 of 8

7 But if you upgrade, you won't. Now to change that you need to change the setting in your web.config file and in doing so you'll probably find that there will be things that break because generally what happens is people take a dependency at some point in the development of an application or Web Forms application on the markup that's being emitted. They might write some custom JavaScript to do something on the client or they might have some CSS that's targeting the markup that used to be outputted by Web Forms and that would have changed the rendering mode so they're going to have to go and change that stuff as well. Scott Hanselman: Okay, okay. So what kind of things am I going to run into though? Like is there a limit to what I can do on Web Forms as far as making view source pretty? Could someone create a Web Forms application that you wouldn't be able to tell it was Web Forms? I mean you've got routing also, right. You can make pretty URLs in Web Forms. Yeah, you can. Yeah, I mean there are a couple of limitations. One is around the form tag. Now Web Forms is geared around the concept of a server form and you'll see that in the markup of any Web Forms page. You'll have a form but not equal server tag. You could only have one of those per page. It's not per control. It's actually per output of page. You can only have one of those. Now that doesn't limit what you can do in terms of building multiform pages and certainly MVC doesn't have this limitation at all because it really has no concept of a server-side form. It just looks at the raw request information coming in. That doesn't mean you can't use multiple forms in Web Forms, but you can't have more than one server-side form. So then, yeah, the follow-on question for that is to go, okay, well, what's the limitation of not having a server-side form? If I have a server-side form and then a clientside form, what can I not put in the client-side form? Now there are certain ASP.NET server controls that require being inside the server form to work properly and they'll actually throw an exception if you put them outside of a server form. But I would certainly recommend to people, if they're building UIs that have multiple web-based UIs with Web Forms that have multiple points on the page that require input, then certainly it's worth looking at using multiple forms if those other portions of UI don't require the complex server controls to surrender those. A classic example is if you have a search box in the header of your website. There's really no point in having that search box inside the server form for ASP.NET Web Forms and you actually have to work around that sometimes because if you have one form in your HTML then the action of the entity in the HTML becomes an issue because an HTML form generally expects to have a single submit button and when you hit enter inside any field in that form, that's the button that gets submitted. Now when you look at ASP.NET Web Forms, it's kind of designed to have a single web server form and you can put as many button on there as you like and then it would use the, it would actually figure out which button you clicked base on a number of different factors that it can do. But that was all very much based on clicking. If you just want to be able to type in something and hit enter, you have to set extra properties in Web Forms to say, hey, this is the button that I want to be inadvertently called as clicked or have those click event rise when the user hits enter while I'm in this textbox and it uses JavaScript to do that. So it's really not the most elegant way of doing that. If you're just putting a search box at the top of your page, put it in a different form, put it in the clustered form. It's just a textbox in the submit button, and then you don't have to worry about that. When the user is in that textbox and they typed in or hit enter, it's automatically going to use that button, that clustered button there because it's in the same form. Scott Hanselman: Yeah, yeah. I've actually done that myself on my own site because the dasblog, the blogging engine that I run has a single server-side form of course and then I've got some search boxes around the outside and I do some, just one or two lines of JavaScript to pull that information out of those form fields and then put them through the process regularly. Well, it sounds like you guys are thinking a lot about Web Forms. I'm kind of surprised you're thinking about it pretty deeply. Are we going to see some Web Forms' cool stuff in the next couple of months or the next year? Yeah. I certainly hope so. I mean as I've said, we've mentioned a few things that we're working on for the next version but I think there are other things that we're working on that we hope to get out before then so certainly some things around our move to jquery as our preferred AJAX model. Expect to see some more information about that in the coming months, and not just information but hopefully some more concrete things that you can actually use inside Web Forms as well as MVC of course to do with AJAX and jquery and things like that. We're obviously keeping a close eye on HTML5 as well, and we get this question a lot about when does Web Forms going to be upgraded for HTML5. The truth is there's really nothing stopping you using HTML5 today. I mean HTML5 is a kind of a horrible term because it encompasses so many different things and we really don't know what customers mean all the time when they ask that. But in terms of concrete things, certainly the next version of the templates that we build we'll use some HTML5 as much as we can. That makes sense. You know, we're always looking at what the browsers or where the current browsers are caught up to and what makes sense to add as functionality in the base framework to take advantage of whatever new capabilities of the browsers have. I think coming up at MIX you'll probably see some talks there about Web Forms and HTML5 working together and maybe some talks more about what we're planning to do in Page 7 of 8

8 the next version of Web Forms as well. So I think you'll see it's a talking more about it like we ought today and if you come along to our conferences you'll see us continue to talk about it as well. Scott Hanselman: Very cool. Well, thanks a lot for taking the time to educate me on what's going on in Web Forms. I appreciate it. for having me. Not a problem at all. Thanks Scott Hanselman: This has been another episode of Hanselminutes. We'll see you again next week. Page 8 of 8