ASP versus Me: A struggle for control

I have long avoided the use of frameworks for most of my coding. In development of desktop applications, that is closer to the standard practice than it is in web development. Sure, in desktop development, you'll pull in a package here or there to provide some functionality. Or maybe interface with a dll instead of writing your own drivers. But In web development, there are TONS of frameworks which will do fantastic things for you.

I avoided frameworks for a few reasons. The first was simply that I didn't need them. Over the years, I have had to deal with a wide enough range of coding situations that I felt fully able to accomplish my tasks dealing with base language constructs. Switching to a framework seemed like something that would slow me down rather than speed me up, since that switch would require learning the framework instead of producing useful code. Why waste the overhead in hours when I can crank out the code myself?

The second reason for avoiding frameworks was that bad programmers use them. I have worked with people over the years who cobbled things together with frameworks without ever understanding the basic technology driving them. As soon as you asked for something that wasn't readily available from the framework or a plugin, they would be out of their depth. Why would I want to mimic what such a programmer was doing?

The third reason for avoiding frameworks was that I like having full control over my products. Through things that are abstracted away by frameworks, I stood to lose some of that control. I didn't want coding to become a process of "I know how to do this by hand, so how can I configure OMG-Code-It-Fast to provide the same thing?"

A shift in my thinking occurred when I took a class in AJAX web development at Johns Hopkins. There, I was forced as a part of the assignments to spend time with jQuery, Prototype, GWT, and a handful of others. I saw that while I didn't need them, their functionality could both speed up my development time and produce cleaner, clearer code. I saw that they don't have to be a crutch for bad programmers; they can also be a tool for good programmers to more easily do more with less code in less time. I saw that neither the learning process nor the coding process has to be all-or-nothing with frameworks. There are a lot of shades of grey along the way. If I wanted, frameworks could be used only for speeding up specific tasks. Making complex processes easier. And the learning process could be an incremental one - picking up the pieces I need when I need them.

In many ways, moving from the LAMP stack to ASP.NET development is a lot like adopting a framework. ASP.NET offers a plethora of controls which can then be configured in a dozen lines to accomplish things that might have taken hundreds of lines of code when done coded manually. But sometimes the simplest tasks are aggravatingly difficult due to that abstraction (made worse, I am sure, by my comparative unfamiliarity with ASP). I find myself continually sliding up and down on the scale of integration, using ASP.NET server-driven controls to generate some elements of the page in order to benefit from easier server-side access (especially for more complex database interactions) and using manually structured HTML elements for many others in order to benefit from easier client-side access (especially for actions based around Javascript and jQuery). I think either style is fine, but it does feel a bit dirty to mix the two. Hopefully I am right in thinking that another parallel between shifting to ASP.NET and shifting to frameworks is that incremental steps work perfectly well.