My First ASP Dot Net Experience

I'm IMPRESSED!

[txbakers]

I downloaded and installed the framework, and started with the MS QuickStart tutorial, and BOY AM I IMPRESSED!

Tonight I will write my first ASP.NET page and see how it goes.

Bye-bye client side javascript!

[Xoc]

Come back with a full report on what it does for you. People are having a hard time grasping what the advantages of .NET are over previous environments.

[andrey_sea]

txbakers, are you sure you want to say bye to the client side JavaScript? .NET controls also generate JavaScript on the client side and often times it is clearly worse than what you can write yourself.

[Xoc]

I believe that all .NET client-side javascript is optional except for the very short generic javascript necessary of immediate postbacks when you select something from a listbox, for example.

[txbakers]

I wondered about that. What would happen if the client had javascript disabled and I was running strictly .NET? I know the validation works both ways automatically(client side if available - server side always) . But would that affect the functionality of .NET?

I got a kick out of seeing javascript instead of VB script or JScript generated by the microsoft product.

[Xoc]

Yes and no. If you only have a listbox and are counting on the postback from the selection to make something happen and they have javascript turned off, you have a problem: they will click and nothing will happen. But if you also have a submit button, then you have graceful degradation and everything is fine.

[andrey_sea]

XOC, if you don't use client side JavaScript for validation then you have to rely on server side validation. It seems to me that it will slow the performance of your application since to get a message that user forgot to fill out some field you would have to do a round trip to the server.

I think this, plus the viewstate tend to create unnecessary round trips and performance drains in .NET (Viewstate creates performance drains-stores a bunch of junk in your HTML)

[Xoc]

That is the classic trade-off. You can have client-side javascript for a more interactive experience, or you can have server-side processing, but that requires round-trips to the server. Fortunately, .NET gives you the choice, and also will perform without client-side javascript depending on your page design.

The cost of viewstate is minimal. Even if you have a huge amount of it, the cost is less than that one additional icon graphic that you placed on the page. If I was trying to reduce the size of the page, I'd first optimize graphics, not viewstate. (Viewstate, for those lurking on this thread, is information that .NET places encoded in a hidden field on the form that stores the original state of the controls on the form before the postback.)

[andrey_sea]

I have found that at a typical web page with a FORM viewstate adds about 20 KB of text. This text is stored right after the <form> tag which pushes everything that comes after it quite a bit down. Does this have a negative effect on keyword density and prominence?

This is how viewstate looks:

<input type="hidden" name="__VIEWSTATE" value="dDwtMTQ2NjgyODI2MTt0PDtsPGk8MT47PjtsPHQ8O2w8aTwxMz47aTwyMT47aTwyMz47aTwyNz47aTwyOT47aTwzOT4
7PjtsPHQ8dDxwPHA8bDxEYXRhVGV4dEZpZWxkO0RhdGFWYWx1ZUZpZWxkOz47bDxDaXR5O0NpdHlDb2RlOz4+Oz47dDxpPDQ3P
jtAPEFsZ29uYTtBdWJ1cm47QmVsbGV2dWU7QmxhY2sgRGlhbW9uZDtCb3RoZWxsO0J1Y2tsZXk7QnVyaWVuO0Nhcm5hdGlvbjt

... and so on ...

Oh yeah, I forgot to mention the obvious thing - this 20 KB is going back to the server every time the form is submitted.

[txbakers]

Here is a bit from an interview with one of the developers of ASP.net in regards to the scripting:

MARK ANDERS: part of the magic of ASP.NET is, by having this concept of these server controls that encapsulate a lot of the functionality for you, it really gives you a nice way of encapsulating the different behavior that you expect, or the different renderings that you expect for different types of devices. And we do this in a lot of different scenarios; for example, we have a set of controls for doing validation, which is a very, very complicated thing to do in a web site, especially when you want to, you know, emit script code that goes down to the client and does the validation; you also want to have server-side validation for down level browsers. And we have a set of controls that will automate all of that for you. So they encapsulate the basic validation behavior, yet, if it's a rich browser, they will emit one thing, they'll emit -- script code. And if it's a down level, they'll run the validation and produce the exact same experience, except it's happening server-side, for those down level browsers.

And it will also automatically handle scenarios where clients that deliberately try to go around client-side script or deactivate client script and spoof things, it will trap those as well. And all you need to do is drop these on your page, declaratively as tags, and you can write two or three line of code against them, and you actually have a fully validated page.

[Xoc]

Good lord! What do you have on the web page? The viewstate is recording the content of the controls (compressed) to be posted back to the server so that it can tell what has changed and be able to reconstruct the page. If you have no need for that info on the server, don't have that control remember its content in the viewstate. Each control has a property called EnableViewState that can be set to False. If there is 20K of viewstate info on the page, that means that you have more than 20K of info in the controls on the page.

I think most ASPX pages have controls that have EnableViewState set to true that don't need it.

[andrey_sea]

Don't have that many controls on that particular page: 16 total controls of which 9 are drop down lists which contain most of the data. Viewstate data is 21k.

If I wanted to maintain state using Viewstate I would have to enable it on all of the controls. There is no point in enabling view state just on some of the controls, then I would have to write my own code to maintain state for them and I might as well do it for all of the controls then.

By default viewstate is enabled for web form controls, so I guess that is why most people don't disable it and maintain state and don't even know about it.