The good ol' days of Response.Write and Server.CreateObject
One of the many projects I'm working is an ASP classic app; we're extending it with new ASPX functionality, which is interesting in its own right, but as I peruse the ASP codebase I'm constantly struck by how primitive old school ASP feels compared to developing for the .Net framework.
With ASP, a modest form of object orientation (through VBScript Classes) and code reuse is achieved through this web of include files. I remember doing my share of this development back in the day, and considered it cutting edge then; we created some sophisticated stuff! Around 1998-1999, me and a colleague had this cool idea where we'd place all our logic in COM components for ease of debugging (remember trying to debug in InterDev on a remote server?) and compiled performance -- plus, we'd be able to reuse DLLs easier than a convoluted web of include files. We took the idea further, and called it “VBML” where we'd have proprietary tags (“<VBTABLE src="“tblDataBaseUsers“/">” etc.) that rendered as special content (all generated by our COM components); every asp page would run through our proprietary “magic parser.” 100% generated HTML. We had MTS rolling, SQL Server, and thought this was as brilliant as beer in a bottle!
In retrospect, we were marching down the same path as the Microsoftians. Our VBML never took final shape, it was always a work in progress with lots of theoretical elements we never got around to implementing. Thank goodness Microsoft did -- and then some. The .Net platform introduced powerful elements like the cache, viewstate, and a new Page processing model our VBML hardly anticipated -- us amateurs were barely scratching the surface!
Anyway, I think all that ASP classic experience, the VBML years included, serves me well. I understand the underpinnings of the .Net framework and appreciate the measures it takes to ensure proper component versioning, etc. People new to .Net, without the hard-earned perspective many years of Response.Write and Server.CreateObject() provide, are at a serious disadvantage when doing more sophisticated .Net development. Experience counts for a lot in this industry, even if it's in a different platform or language!
Happy .Netting!