Server Controls vs Plugins

I think the ASP.NET world has changed completely as far as reusable code is concerned. 

Let’s start with a bit of background…

Server Controls

I remember when making reusable code in ASP.NET meant writing custom server controls that had all kinds of logic for outputting complex html based on simple templating.  Heck, remember?  I still write and use these things all the time! 

But wait a minute, what’re the server controls I hate the most?  Grid.  ListView.  Menu.

What’re the ones I use the most?  Repeater.  Placeholder. 

What the… ? The server controls I use the most DON’T EVEN OUTPUT HTML.  All they do is provide a way of controlling the output of HTML that I put into the markup myself. 

That’s the key to a good server control: CONTROL.  I mean, what good is a control that outputs a <table> tag when you want it to output an <ul> tag?  No good at all, I say.

Plugins

I remember a time when I scoffed at Microsoft’s implementation of DHTML behaviors in IE (I think they first appeared in 5.5).  I knew that the idea was profoundly useful in theory, but the DOM traversing and manipulation capabilities were so browser specific, not to mention the fact that they only worked in IE anyways) that it never had a chance. 

But what was the idea behind “Behaviors?”  It was intended, in my opinion, to add interactive functionality to existing markup.  This includes the ability to inject additional DOM elements and unobtrusive Javascript events into a set of elements that were included in a given behavior. 

“But Joel,” you say, “this is what a jQuery plugin does!”

Totally, I know.  Awesome idea, huh?

Reusable code in Repeaters and Plugins

Now, when I write a server control, it follows this pattern: Repeater + Plugin = Control. 

Let’s take the example of site navigation.  Often, it’s useful to ouput this as a series of nested <ul> tags, which each page in the sitemap represented by a <li> tag.  This looks some what representative of the site structure when viewed with no css or interactivity – you see all of the pages in the site.

Now, you could (and should) control a lot about how those lists look based on CSS rules.  You can give the first level certain formatting, and, for example, hide the sub-levels.  But how do you show the sub levels on mouse-over or click?  This is where the plugin logic comes in.  You can write a jQuery plugin to control the behavior of the <ul> and <li> elements based on user input, and it can all be done without including Javascript inside the markup (no document.write() or any crap like that). 

Where is this leading?

I am saying we shouldn’t be relying on crazy server controls to magically output html and Javascript to make pretty websites and apps. 

May ASP.NET developers hate this idea – it means they have to actually think about the markup that will be produced by the stuff the put on their pages and user controls.  “Our world is crumbling!” 

Well, I say suck it up – we should have paying more attention to client markup and less to server markup for the last 9 years or so.

.Net without the ViewState

This is what I want to see!  This is why MVC is so cool, but most .Net developers will continue to ignore it, so what do we do?  Think about the pattern of Repeater + Plugin = Control

I have one last suggestion to you, in the form of a challenge: in your next project, take out the <form runat="server"> tag from the page or master page.  It will FORCE you to stop using control that rely on viewstate, and these are almost ALWAYS the ones that output crazy html and inline styles that suck when you want to have control over your markup.

more later – joel