ASP.NET and Other Frameworks

August 25th 2008

My most recent experiences at Cyber Sprocket are entrenched in ASP and Visual Basic Dot Net. Contrary to what many of you may expect, I've found no urge to blow my brains out with a shotgun. It turns out that throwing oneself into the gutters of Microsoft technology programming is not that bad.

I am humorously unproductive in this scenario though. Hmm—is ‘humorously’ the best word here? Sure. I imagine my approach to the framework is pure comedy to veterans. For example, I initially made no use of the <asp:*> tags. I had seen them in passing but only remembered them in the way I commit to memory each individual tree along the highway. “Why am I going to use <asp:DropDownList> when I have <select>?”

Lots of reasons, apparently.

The Value of Friends

Sitting next to me at work is my co-worker, drinking buddy, and bitter tennis rival Paul Grimes. Or as I like to call him, “Hey look at this for a second.” He's spent much more time working with ASP than I have. You could take the number of days I've used ASP and VB.NET, multiply that by the number of atoms comprising Jupiter, take the reciprocal, multiply that by zero, and add a few years and you would have his experience. Which clearly dwarfs mine. Although I destroy him with my mathematical reasoning, as this paragraph demonstrates in spades.

For reasons I will describe merely as ‘just because’, I am unable to compile or test the VB.NET application in question. This is a fairly interesting and dangerous way to learn a new development environment. I never know if my ASP structure is correct or if my VB code is up to snuff until I hand it over to Paul, henceforth referred to as the Compiler.

Details on ASP.NET

The mental blueprint for applications which ASP.NET anticipates is unfamiliar to me. For example, this idea of putting data sources in the markup alongside my HTML. I had heard—maybe in an article in Redbook or something—that ASP.NET encourages the Model View Controller paradigm. Grafting SQL queries onto the skeleton of the View strikes me as breaking MVC's bones.

But I can see a benefit: if a page element is generated from the results of a query, having that query as close as possible to the element markup is a win, as it eliminates searching you may otherwise have to do. You may even write parameter placeholders in these queries which are later filled in by functions. Overall I find this design concept to be useful, that of closely tying together markup elements and the data sources which populate them. It reminds of my SQL::QueryCache Perl module, and in my spare time I may extend it to put an ASP spin on things.

Frameworks in General

I'm actually not all that crazy about large, over-arching frameworks. Reinventing the wheel over and over is no pleasure of mine, but I want frameworks to stay the Hell out of my way at the same time. This implies small and lean, as I have found that when a framework attempts to predict my every need it serves to only burden me with vines of functionality that must be hacked down.

We are beginning another large project at Cyber Sprocket using a Perl framework that Lance and I have developed over the past weeks: Zinc. The application will serve as the first true test of Zinc considering its scope, which is no joke. Lance and I share a dislike for unwieldy frameworks, the likes of which are popular these days. So I'm curious to see how our slim construction of Zinc affects the creation of our target application. And more than that, in which ways we extend the framework throughout the course of development. There is general agreement that as much should be kept out of the framework as possible, that additions should be made only when they can be shown to have a useful purpose for a wide-variety of applications. We'll see how well that holds up.

And to end all this, a question: what web frameworks have you used, or if you haven't used any, is there a reason why? Which would you recommend or not recommend?