Should the web be object-oriented?

The enterprise-level development community has long held the stance that Object-Oriented Programming (OO or OOP) is the best method of developing software.  But does this really apply to web development?

For almost a decade, Microsoft has devoted its web technologies to the principle that HTML should be OO.  ASP.NET WebForms is still their Internet flagship.  As a VB developer 10 years ago, I had the thought, “It be great if there was a way to publish my VB Windows apps to the web!”  A couple of years later, voila! Microsoft took the WinForms principles and applied them to HTML.  In the words of Chris Daughtry, “Be careful what you wish for, ’cause you just might get it all…  and then some you don’t want.”

Web pages are composed of HTML which is nothing more than text with markup for presentation.  The browser does translate the text into a Document Object Model (DOM) but the server has no direct connection to the DOM.  The server should only care about generating HTML script rather than worrying about client-side state.

However, an ASP.NET WebForm does exactly that.  It utilizes form postbacks and hidden form fields (like ViewState) to keep the server synchronized with the client-side DOM.  In some ways, this is a brilliant idea and brings a real OO feel to web development.  Unfortunately it is not without its drawbacks.  The developer has lessened control over the resulting HTML.  Often the document becomes bloated with large ViewState that needs to be passed back-and-forth.  Some HTML magically appears at run-time such as references to JavaScript libraries.  Element IDs you named in your HTML (i.e. <asp: Panel id=”myelement”>) are renamed at runtime by ASP.NET (i.e. <div id=”ctl00_formcontainer_row5_myelement”>), meaning that you need to jump through hoops to write custom JavaScript.  Seemingly simple objects become a mess of HTML with ASP making the decision on how to render the output for each <asp:___> tag.

This isn’t a rant about the perils of ASP.NET but rather a chance to examine the philosophy of bringing OOP to web development.  In my opinion, it doesn’t belong.  The server is a document generator and the browser is a document reader.  One could argue that WebForms is an attempt to simulate the browser’s DOM in the server, though most would argue that it’s an attempt to simulate server-side objects in the DOM.  In either case, it’s clever voodoo that makes HTML generation more complex than it is.

Before moving to the .NET world about 6 years ago I had worked primarily with “Classic” ASP and ColdFusion.  While these were limited languages compared to .NET, I have grown to miss the simplicity and flexibility of dynamic HTML creation that they offered.  Both web languages were largely procedural.  Some OO concepts existed and OO support has grown in ColdFusion.  Still it has occurred to me that the use of procedural code for HTML generation fits the bill far better than forcing OOP on a simple document scripting language.

Don’t get me wrong – OOP is invaluable for development of the lower tiers of an n-tier application, namely the repository (hopefully implementing an object-relational mapper) and services.  Data persistence and business logic are perfect for OOP.  But the same principles don’t apply to the presentation layer if your goal is to create HTML.

What’s my point?  Well, don’t fall for the assumption that OOP is always superior to procedural design, especially when it comes to HTML generation.  When I want to dynamically create HTML without surprises, I prefer a simple web language (ColdFusion, PHP) over WebForms any day.

But, alas, I’m committed to the .NET world.  What can I do?  Okay, technically I could eliminate all <asp:___> tags and use simple HTML in my ASPX pages.  Then I’d skip the whole postback lifecycle, essentially treating ASP.NET like “Classic” ASP.  But that would be the “wrong” way to build sites with .NET (even though I’ve considered it many times).

I have personally been using Castle MonoRail for 2 years.  MonoRail is a .NET implementation of the increasingly popular Model-View-Controller (MVC) design pattern.  For creation of HTML it allows plugging in various view engines.  I typically prefer NVelocity which is a very simplistic template language.  There are some drawbacks (such as lack of Intellisense for NVelocity) but HTML is treated as a simple document once again.

Microsoft is seeing the light as well.  They have branched off ASP.NET into two directions:  WebForms and MVC.  Like MonoRail, Microsoft’s MVC doesn’t force server-side representations of client-side objects.  It will also address MonoRail’s glaring shortcomings:  lack of strongly-typed views, views being interpreted at run-time (instead of compiled), lack of 3rd party support, lack of documentation and lack of human resources (developers).  I’m sticking with MonoRail for now, but as MS continues to improve their framework and adoption of Microsoft’s MVC grows, the choice will become obvious.

Kick it on [Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]