2nd May 2009

Don't hate me for my .NET

I'm an outcast trying to fit in... at an event like FOWA I'll feel like working with .NET is akin to admitting to owning the Rednex single 'cotton eye joe' from the glory days of '94... but then I'll go to a Microsoft event and feel like a pariah obsessed with miniscule details that I shouldn't worry about (unobtrusive javascript.. element ID and exact markup control...).

A generalisation this may be but it highlights the difference in perception between languages such as PHP/Ruby and .NET in the world of web. So much so that people often don't even list .NET when they reel off examples after the phrase 'your language of choice'.

I don't so much want to 'put the record straight' just to put forward my experience starting out with PHP and moving to .NET, with a sprinkling of the stuff I usually hear against .NET.

Background

Following a pretty standard path I started out in web development with static HTML, moved on to being scared by CGI then dabbling with javascript and later some PHP and Actionscript (with some VB6 and Java studying thrown in there for good measure too). This led to my first full time role being as a PHP developer, which later evolved into a C# position.

.NET WebForms vs. Everyone Else

The first thing I (and many others) realise when moving to .NET (Webforms) is that it's really not the same paradigm. In fact I'd go so far as to say that if you skipped straight to learning Webforms, you haven't learnt web development. What you've learnt is winforms. And the reason for this is that that was the intention of Webforms - to assist winforms developers in making the leap to the web and to mask the lack of state.

The 'innovation' therefore of postback/viewstate persisted server controls was that as a developer you didn't have to worry about working in a stateless environment as you did with other languages. Nor did you really have to worry about the actual markup output (in the same way that you wouldn't worry about how the pixels rendered for a button in a windows app). Submit buttons and Select boxes can have server side Click and IndexChanged events and before you know it you're well away without worrying about html or javascript or even css (if you went with some rather questionable attributes available on server controls for presentation).

What this caused however was a largely negative view of .NET from the non .NET side of the tracks, and it's generally the sort of stuff I continue to hear.

1. Poor Markup
   • Large amounts of encrypted 'viewstate'
   • Large amounts of generated javascript
   • Crazy ID attributes
2. PHP (or misc web scripting language) is easier to use
   • .NET feels more like Application Programming rather than web scripting which can make it seem overkill for small tasks.

However this is not an attack on .NET (whether people know it or not). This is an attack on a particular way of coding in .NET webforms. Yes, Microsoft pushed .NET to be used in those kind of ways but that doesn't mean you had to do it that way.

In the same way that developers don't use the visual interface of Dreamweaver to generate their markup .net developers don't need to use server controls and viewstate. Just because it's there and assists some people in their needs doesn't mean everyone should use it.

Much of my recent work for example has relied heavily on generating Xml as the content and using Xsl to create the presentation, thus bypassing the majority of asp.net server controls and their associated scripts/viewstate/long ids.

Without taking this approach you can still make your own user and custom controls, but be smart about how you make them. Turn off viewstate when not needed, use standard html controls when you don't need the functionality provided by an asp server control and use repeaters with your own standard html templates rather than .NET rendered gridviews.

.NET or not .NET?

It could be argued that doing these kinds of things is not '.net' but thats not true. It may not be entirely '.net webforms' but you are still using the power of the .net frameworks class library. You are still using the, in my view currently unchallenged awesomeness of, Visual Studio (and yes I've used eclipse.. it's not as amazing as you might like to think) and you're still getting the ability to write in the same language for your website, windows services, silverlight, xbox and windows applications.

Admittedly it's unfortunate how long it has taken for the release of asp.net MVC (although lets be honest PHP weren't flying off the blocks with full and complete OO support so no-ones perfect). However the key is, as with so many things, that the quality of your .net output is down to the quality of the development.

Wrap up

I too, when I was asked to swap to .net from PHP, thought .net was an overcomplication. "I want to just call the database and do a loop outputting html in my markup. I don't want to put a GridView in the markup then in a 'code behind' 'load event' access the database and databind to the grid".

It's a leaning curve as with all things. My early PHP was, going back on it, messy to read and understand as it was all mixed in with markup with include files all over the place. Similarly my early .net work probably relied on an overuse of server controls. As you get in to something you get better at it. And although .NET seemed like a greater move away from static pages than PHP (which is probably why I saw it as an overcomplication) I now personally love working with it.

I'll wrap this article up briefly with some reasons I like .net that either I haven't found at all, or have found harder to do in other environments/languages.

• Similar syntax to java/javascript/actionscript
• Reusable classes across web applications, windows applications, windows services, IIS modules, xbox games
• Very easy to cache with a large variety of inbuilt assistance
• Extremely OO friendly

I'm not saying .NET is the best, or amazing, but its certainly not something to be looked down upon or avoided purely because it's Microsoft or because of a misunderstanding surrouding it. Over the time I've been using it it's got better and although the picture I paint in the intro to this article is still true, it is less so nowadays. Css Control Adapters have been around a long time to assist with poor rendering, MVC is upcoming, and along with things like ClientID mode the bad things are going or easily avoidable.

I'm not sure I've covered everything I would have wanted to in this post, as it is such a vast area and this was really just a one sided conversation from the POV of .NET not being quite as sucky as many people think. Please fire any points gripes or questions at me.

---

Mini Glossary (for those .net virgins among us)

One form to rule them all

Webforms asserts that each page has one form that contains all elements rather than multiple forms as and when necessary. Or to quote...

For example, most ASP.NET Web pages contain a single server-side Web Form, with multiple Web controls inside the Web Form. The Web Form is an HTML control (System.Web.UI.HtmlControls.HtmlForm). Those Web controls inside the Web Form are children of the Web Form.

Postback

Form field data is posted to the server and used to repopulate form field values automatically e.g. if you change an instance of a textbox server control before posting back .net maintains the value you posted from the first screen. Similar to the following manually achieved effect in PHP:

                            <textarea name="body" id="body" cols="40" rows="5">
                                <?php echo htmlspecialchars(stripslashes($_POST['body'])); ?>
                            </textarea>
                        

Viewstate

The encoded (and optionally encrypted) first hidden field used by .NET as a means to persist programatically set control properties.

                            <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMTMwMTcxNDUyNmRk4HWhWoozWLYUelHWkPH2E67bXGo=" />
                        

A control will gain its final value after the following cascade: Initial declarative value, Posted value from Request.Form (if postback), ViewState value (if changed via code after a postback).

Crazy IDs

Until the upcoming 4th version of .net developers were not trusted to know if there server control IDs were unique and because the built in viewstates, postbacks etc relied on it someone decided to make damn sure that control IDs were unique and context based on their location in the control heirachy. This led to ids like "ctl00_asp_menu_links_ctl03_contextLink". Which, if someone added a parent or reshifted markup slightly, would change. Particularly helpful for clean client side development.