I write a lot of web applications, but I don't like JavaScript. Too many applications made today are forced to be browser applications when the functionality clearly indicates a desktop solution.

There, I said it. I never did much client-server programming so I can't really be accused of holding on to something who's time has come. There are certainly many benefits to web applications too, not the least of which is ease of deployment to the end user. However, after doing several applications that overused javascript in the worst ways (Like implementing a QuickSort that could sort table rows using the DHTML object model) I became very tired of Javascript, with its many idiosyncrisies and fragile nature. I have been accused lately of going too far down this anti-script path. In ASP.NET, its just too easy to set items to auto post back and create the desired effects from within the safe and familiar environment of my favored, garbage collected, strongly typed and compiled language of choice.

To be fair, I view the fact Microsoft has put a great deal of effort into making it easy to deploy WinForms applications via the AppUpdater block and features in VS.NET 2005 as support for my opinions. Web Services + Thick Client + Easy Deployment = Best of many worlds. Even Sun had it figured out several years ago when the came up with Java WebStart: why not run a desktop app via a shortcut to a web site that checks for updated versions of the code it needs to run? Of course, writing desktop apps in Java is less fun than covering yourself with papercuts and jumping into a pool filled with ice-cold lemon juice, so JWS does them little good.

My point in all of this rant was that .NET is wonderfully extensible in many different ways. It was suggested to me that server-side code could be written to generate some basic and common client side Javascript actions, such as making it so that a radio button list could hide or show an ASP:Panel depending on its selection, without postbacks. Seems simple enough, but if designed properly it could be the first step towards bigger and better things.

Without doing any code experimentation yet, I can think of 3 ways I might set out to do this:

Ineritance

Inherit from controls already in .NET to add the functionality desired. For example, create a custom RadioButtonList that is smart enough to generate client side events to perform some action. The problem with this is that I want to leave inheritance as a last result. I may purchase some 3rd party component that I wish to add this functionality to, meaning extending the base controls may not be an option.

Builder

Some type of builder pattern may be appropriate, where the attributes needed to provide the desired run-time functionality are added via logic encapsulated in Builder classes that operate on otherwise vanilla ASP.NET web controls. The downside of this solution is that it seems like it could be a little more dran-n-drop than adding a few lines to your code behinds manually.

Custom Control Library

This idea is intriguing, although probably slightly overengineering a simple problem. We could probably create a library that would allow us to write ASP code such as the following:

<library:ToggleVisibleRunat="server"  ShowValue="Yes" HideValue="No"  Target="loginPanel" Event="IndexChanged" ID="Clientaction1" NAME="Clientaction1">

          <asp:RadioButtonList Runat="server" ID="showLogin" AutoPostBack="False">

                   <asp:ListItem>Yes</asp:ListItem>

                   <asp:ListItem>No</asp:ListItem>

          </asp:RadioButtonList>

</library:ToggleVisible>

<asp:Panel Runat="server" ID="loginPanel">

          ... other stuff here ...

</asp:Panel>

With this type of metaphor, we could also allow dran-n-drop coding, and allow the values such as "ShowVaule" and "Target" to be configured via the Properties Grid and .NET's most excellent design-time support. I will think about this, and come back after some experimentation.