Sunday, December 16, 2007 3:03 AM
When I first heard about the MVC framework, I was intrigued by one aspect that didn't seem to make sense: that the layouts of pages were not done with a designer, and that outputting the dynamic aspects of the page were done by pushing markup to the presentation from the controller.
Blasphemy! We've been developing in ASP.NET for the last 7 years or so WITH the designer, which was a huge feature to add to web development (and still is)! Now we're given a framework that removes the need for a designer? Now we have a framework that won't help me bolster productivity by removing my need to understand the underlying markup and abstract that away into a set of windows-like control metaphors? How will I do web development on this framework?!
That's been the response of many when they realize the seemingly ugly truth that lurks beyond the promises of better testing, better integration with 3rd party open source tools, and the removal of the postback mechanism.
But the response is wrong. The response is similar to an addict, when you tell them that their life will be better without their targeted addiction substance. They recoil, they rage, and they can't see the message for what it is.
I'm going to make a pretty strong statement here, and I'm not excluding myself from this statement in the least: ASP.NET developers are not web developers...they're ASP.NET developers. They're dependant on the tools provided in Visual Studio, with the myriad of controls and data sources that can be dragged and dropped at will. They're comfortable using skin files for decorating their page elements and in click-dragging their tables to create a layout.
But take away their tools...take away their controls...take away their skin files...and they crumble. Why?
Because we've lost site of the basics. We've lost site of what the web was and is still built on: HTML, Javascript, CSS, and the HTTP Protocol. Those are the four pillars of the web, and a web developer needs to grasp an understanding of those things first before tackling the abstraction benefits that ASP.NET provides.
How many of us understand why we get the little red squiggleys in our source view when we capitalize our tag attribute names, or don't wrap the attribute values in double quotes, or have even stopped to really wonder what the DOCTYPE tag specifies? We don't, because the current state of browsers accepts loose HTML and we've grown accustomed to ASP.NET abstracting so much away that we've become lazy in understanding how our chosen technology actually works.
So don't try and figure out what the MVC team was thinking when they released something seemingly backwards...ask yourself why it bothers you so much that you'd actually need to understand the markup that's being output by your application. And then decide if you're a web developer, or just an ASP.NET developer.
D