Speaking of WebForms, they blow. I figured that the company that produced the major disaster known as FrontPage and Word would create a WebForms that was both not bloated and not convoluted. Surprise, surprise: the implementation is both. The alternate way of talking about WebForms that I’ve seen—server-side controls—is indicative of the oddity that it is. Controls are quite the client-side technology and any implementation of controls on the server is wrongheaded. Except that controls aren’t actually implemented on the server, the references to the server-side controls are transformed on the server into client-side representations.
So a call like this <input type="button" id="_buttonPush" value="Push Me" runat="server" /> gets wired to an event handler in the class file or in the code-behind file that gets fired when the button is pushed. Oh, sounds like Flash, right? That’s pretty cool. No, it actually fires off a POST that is automatically interpreted by the ASP.NET receiver, which is always the same page incidentally unless you’re willing to go through some serious gyrations, and routed to the event handler you’ve declared and linked. This is all done to get some fairly marginal benefits, as far as I can tell. It’s very much like <cfform> in this respect since both get you form validation and event handling through weird concoctions of Javascript interpreted on the server side by ASP.NET or ColdFusion.
Frankly, I’d rather write my own code to handle form submissions and I will continue to believe that until I find some unobtainable-otherwise value. I don’t expect that I’ll find any, but I’m going to keep my eyes open. I never found any value to <cfform>, but that’s just me.