It’s Smart to Challenge the ASP.NET Status Quo

One of my personal goals for our little ALT.NET movement is simply challenging the status quo for building .Net applications.  We might end up exactly where we started from, but let’s at least take a look around for other alternatives and really consider whether what we’re doing is the best way.  A perfect example is the reconsideration of basically everything we know about developing web applications with WebForms. 

The specific argument I’m reading about today is about whether or not it’s appropriate, useful, or downright evil to use inline scripting in the actual markup page.  Here’s what I’ve been reading today.  More from me after the break.

  • It’s About Being Disciplined and Open Minded (Steve Harman) – Actually the title pretty well sums up what I think anyway, but that’d be a pretty short post now wouldn’t it?
  • Crazy Talk: Inline Scripting and Code-Behind (Rob Conery)
  • More Crazy Talk: Inline Scripting and Slinging Text (Rob Conery)
  • Have We ASP.NET Geeks Lost Something? (Rob Conery)

     

  • To be honest, I’m mostly a spectator in this argument because I’ve barely done any web development since 2002.  I’ve done two WebForms projects but most of the heavy lifting was in the backend and middle tier, so my opinion needs to be taken with a grain of salt.  If nothing changes between now and then, I’ll be on a MonoRail project in January and I’ll spend parts of December remembering how to do HTML and JavaScript.

    Like many other people, I use ASP classic circa 1998 as a byword for sloppy spaghetti code.  The code could get absolutely heinous as everything but the kitchen sink would be poured into a single ASP page.  I learned ASP classic largely by reverse engineering the ASP pages that MS Access 97 produced from its wizard functionality.  Looking back, I know that my early code was atrocious.  Later on we started to experiment with pushing more and more functionality out of the ASP markup and into nonvisual VB6 COM components, but that never felt smooth and wasn’t widely accepted because of the deployment irritations of COM components.  Putting more logic and control in stored procedures was another choice that many of us fell into out of frustration with COM or ASP, but I refuse to open up that can of worms again.

    When the early plans for ASP.NET and WebForms were announced I was ecstatic.  Treating the elements on the page as stateful objects in an OOP fashion?  Brilliant! 

    I had to jump jobs to get out of my noncoding architect role to do it, but ASP.NET was finally in my grubby little hands.  One of the first screens I built was some sort of grid with a requirement to activate some sort of server side function or navigation when a cell was clicked.  I don’t remember the details, but it was the kind of task I could do in my sleep with a little bit of client side JavaScript in the old world order.  In the new world order I had to know about all these new events off of the DataGrid control and learned that WebForms played hell with client side scripting by screwing up the element id’s.  I was thoroughly irritated and it never got better over the next couple years.  I thought then, and still do, that WebForms makes many things harder instead of easier.  The cool design time stuff doesn’t make up for how much more complex WebForms is compared to classic ASP.  ASP classic suffered because we didn’t pay enough attention to separation of concerns.  Maybe the better answer would have been to conquer the Separation of Concerns problems with ASP classic instead of trying to so drastically changing the development model.  We need to continue to question WebForms just in case it’s not really the right answer for web development.

     

    Other Questions (with very loaded phrasing )

    • WebForms out of the box doesn’t do much to promote separation of concerns either, so what did we really improve? 
    • If we’d beaten the spaghetti code problem in ASP classic instead of drastically changing the UI model, would we be better off today?
    • Might we actually be better off working directly with HTML elements and JavaScript than trying to use a very complicated set of abstractions on top of HTML?
    • Is Visual Programming really the fastest way to build software?  Because if it’s not, we need to rethink most of the .Net tooling.
    • Is Visual Programming really the most approachable way to build software?
    • Every other platform uses inline scripting, and most other platforms also use some sort of MVC framework or another.  Wouldn’t it be advantageous to work like that?  Wouldn’t moving .Net web development closer to the more common model make it easier for us to switch platforms and to onboard folks from other platforms onto .Net?

    About Jeremy Miller

    Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
    This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
    • Jiho Han

      I also was getting tired of ASP.NET WebForms development. I think it was a mistake for MS to mimic the “fat client” model for development. The two are just two different (winforms and web dev). The new MVC sounds like it might work. I had tough time with the eventing on WebForms and control hierarchies, when they get built, when they don’t, the viewstate, etc. etc. Unnecessarily complex IMHO.

      I am very glad to be doing mostly WinForms development now.

      What I really think, and always have been thinking, is that HTML/JavaScript/CSS is not an application development platform. We make it work but at what cost? When people started building simple apps using

      tag and simple javascript, people saw it and immediately embraced it. Now we have AJAX and the whole WEB 2.0 thing. It’s the wrong direction. HTML was meant for documents, not applications. I’ll take Silverlight/Flash or any other embedded runtime over HTML/JavaScript/CSS any day.
    • Dan

      @Scott, Jeremy – Yes, the “page lifecycle” as a stateful process that endures between postbacks is a faulty concept that breaks down when you dynamically add controls etc. The web _forms_ model does imply this lifecycle, unfortunately.

      In most cases, a good application of MVP will allow your views to be postback agnostic and you don’t need to mess around with the page lifecycle concept.

      If you’re dealing with dynamically added controls, then it gets more tricky. However there are solutions that allow you to restore dynamically added controls to the control tree on each request (adding the controls again during the Init phase – DynamicControlsPlaceholder can do this automatically).

      This is a good thing in a way as it forces you to work with the reality of a stateless web request rather than our friend the leaky abstraction. The “request lifecycle” mechanism (in terms of the Init, Load, PreRender etc phases of an individual request) comes into play here – I think this is what Tinco was standing up for.

      The process of making a complex object graph available for editing, where you’re using control inheritance and dynamically adding controls based on the subclass of each object is quite complicated and will be difficult on any platform. However I’ve been happy with the way that WebForms has allowed me to implement this. A Response.Write or templating solution to this particular problem could get very messy indeed and would probably not be as conceptually clean as creating a hierarchy of controls that reflects the object graph.

      Sure, there are plenty of things I don’t like (“one form to rule them all” especially and all that design time data access nonsense), but I’m trying to redress the balance. There’s plenty of good stuff in there that allows you to write effective code.

    • http://lazycoder.com Scott

      @Tinco

      “What other way than procedural do you want a page lifecycle to be? ”

      Well that’s just it, I don’t want a page lifecycle at all. That’s an artificial construct created by the Webform framework. Overriding the methods is exactly the pain I mentioned earlier. All I want are the objects. I like the objects, I don’t like the fact that code out of my control changes the state of the objects at various times and that if I want to influence the state of those objects I have to override and babysit them.

    • Tinco

      @Scott: What other way than procedural do you want a page lifecycle to be? It’s just like that, you get a request, and you handle it. There’s various events you can handle to create your controls dynamically and methods you can override. Also .net offers various object bags to persist states between postbacks.

    • Tinco

      * WebForms out of the box doesn’t do much to promote separation of concerns either, so what did we really improve?
      > We improved separation of concerns by having a App_Code and App_Data folder where you can put your model and controller code. (separated by object orientation)
      * If we’d beaten the spaghetti code problem in ASP classic instead of drastically changing the UI model, would we be better off today?
      > That problem was even solved by asp.net 1.1, you can just separate everything in classes and projects. There’s never the need to spread your code through clumsy .asp files.
      * Might we actually be better off working directly with HTML elements and JavaScript than trying to use a very complicated set of abstractions on top of HTML?
      > asp.net has something called a .aspx file, you can edit it to be working directly on HTML elements like any other webdevelopers language. Low level controls like the repeater and masterpages will give you a lot of control over your rendered HTML, if you want to go quick and dirty you can use the premade usercontrols.
      * Is Visual Programming really the fastest way to build software? Because if it’s not, we need to rethink most of the .Net tooling.
      > I don’t think any webdeveloper actually uses the visual programming features of visual studio for more than dragging the premade or selfmade controls to the place they desire configuring them but then further tweak them in codebehind, because you can’t make a cross browser website without looking at your html.
      * Is Visual Programming really the most approachable way to build software?
      > Does anyone claim it is the only way asp.net offers?
      * Every other platform uses inline scripting, and most other platforms also use some sort of MVC framework or another. Wouldn’t it be advantageous to work like that? Wouldn’t moving .Net web development closer to the more common model make it easier for us to switch platforms and to onboard folks from other platforms onto .Net?
      > asp.net offers controls like the repeater and the gridview that make inline scripting unnecessary. Also by making it possible to package selfmade user controls it’s very easy to create your own framework and share controls with others.

      I don’t really understand why you’re blogging about asp.net when you haven’t worked with it for 5 years. Also did you miss microsoft’s announcement that it will be releasing a asp.net mvc separation plugin for visual studio?

    • The Other Steve

      “I’d very strongly disagree with that statement. I like having the code behind, and in WinForms too now, but the code behind is VIEW code, not a controller. The idea that the code behind is an equivalent to MVC separation of concerns is a myth.”

      Not saying it’s pretty, but that did seem to be the intent of Microsoft when they came up with the code-behind model.

      “Since we all make far more than the average worker, don’t you think we can really expect a little bit of learning in order to work more effectively? Is MVC or MVP really hard, or just strange because it’s not that well known?”

      Yes, it’s why we get the big bucks. What I find more interesting. I go to an MSDN event or some user group thing at the Microsoft office, and I look around and everybody is well over 30. The youth is non-existent. I think MS is facing the problem that every “enterprise” product maker faces, and it’s hard to start up in it. So we make it harder, more encompassing, and we lose the n00bs. The n00bs go off and program in [something else], which they then start clamoring for more and more and more stuff, and in time as they get older it becomes the enterprise product maker and at age 45 they look around and wonder where everybody else is.

      Think about it a bit. I guess the point is, having those avenues for people to quick throw something together even if you regard it as shit, is a path to bring people in that you can train in the ways of yoda.

    • http://www.lazycoder.com Scott

      @Dan

      The big problem with ASP.NET Webforms as they exist now isn’t with the object representation of the HTML page, it’s with cramming the nice OO model into a procedural page lifecycle. Once you need to do something out of sync with the page lifecycle, say create controls dynamically and have them remember their state between postbacks, the pain becomes very real and evident. And that’s just a simple example. When you get into unit/functional testing, the pain becomes even greater.

    • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

      @ Brian,

      “However I fear that we are adding another layer of abstraction on top of ASP.Net.”

      I see the MVC framework as stripping away a lot of abstraction and working much more similarly to the underlying HTTP pipeline.

      @ Joe Chung, the only thing I told you to do is to question WebForms. If after that you’re still happy, then it’s fine

      @DevKm, this is close to childishness. MSTest was berated for being an inferior knockoff of NUnit. Those resources could have been poured into something else that would have provided value. The MVC framework was let out of the bag in March somewhere else. The MVC framework potentially makes things better.

      @The Other Steve,

      “WebForms code behind is already a form of MVC. The .aspx page is your view, the .aspx.cs page is your controller. You can build asp.net with this very seperated… the code behind in completley seperate modules even.”

      I’d very strongly disagree with that statement. I like having the code behind, and in WinForms too now, but the code behind is VIEW code, not a controller. The idea that the code behind is an equivalent to MVC separation of concerns is a myth.

      “But as others have pointed out, these layers of abstraction make it much harder to learn how to program in .Net. There is a steep learning curve.”

      This is a neverending argument/problem. Yes the extra layers require more learning, but I’d argue until I’m blue in the face that it’s worth the effort. Since we all make far more than the average worker, don’t you think we can really expect a little bit of learning in order to work more effectively? Is MVC or MVP really hard, or just strange because it’s not that well known?

    • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

      @Dan, thanks for the comment.

      Well said, but much of that could have been done in simpler ways. I had something similar to the ViewState in an ASP app ages ago. The DOM-like thing can still be done and be useful in the new linear MVC lifecycle.

      “I don’t understand why the entries for the recent “Be the 50th Person to Write a Negative Article about WebForms with the Term ‘Leaky Abstraction’ in it” competition do not take these advances into account.”

      I purposely left our “Leaky Abstraction” because it’s become a cliche. Yes there are advantages, but might these advantages been realized without adding the extra complexity of the WebForms lifecycle?

    • The Other Steve

      WebForms code behind is already a form of MVC. The .aspx page is your view, the .aspx.cs page is your controller. You can build asp.net with this very seperated… the code behind in completley seperate modules even. I believe the CommunityServer project is built this way, if I recall correctly.

      I never did ASP. I was involved in the infrastructure side of the house back then trying to keep ASP apps running. There’s no way I’d go back. The ASP model was so badly flawed from the start, such that even the simplest of applications would inevitably fail in a catastropic manner. Not because of coding problems, but because the OS/IIS would take a dump. This was a side-effect of COM and how dreadfully awful that was.

      What’s wonderful about .NET, IMHO, is that we can have discussions about how we should use it. We can experiment with different models, and are not stuck being able to use it only in one way or another.

      The introduction of AJAX has made things worse, in that now one page can contain multiple discrete functions. So even your code behind can become spaghetti. I’ve been working with the MVP pattern in recent months, and I find that eases much pain.

      But as others have pointed out, these layers of abstraction make it much harder to learn how to program in .Net. There is a steep learning curve.

    • DevKm

      MSTest is bad, but MVC is good. Why? Coz Soctt revealed it to ALT.Net folks first? Funny indeed.

    • Mike D

      The new MVC is not the answer it’s too far in the other direction, MVC is a great concept, was doing it in ASP before I even knew what MVC was. What we really need is a new web form model that uses MVC at the control level.

    • Joe Chung

      “To be honest, I’m [mostly] a spectator in this argument because I’ve barely done any web development since 2002.” Quoted for effect. If you aren’t doing ASP.NET development, please don’t tell us who actually do it for a living what we “should” do.

    • http://brewder.blogspot.com/ Brian Brewder

      I’ve been asking this same question for some time now. There are things I really like about ASP.Net and I wouldn’t go back to classic ASP by choice, but ASP.Net certainly made something that was already somewhat complicated and made it even more complicated.

      The separation between the UI and code in ASP.Net makes it much easier for experienced ASP.Net developers to maintain the code, but the learning curve is much higher with ASP.Net and their seems to be far more opportunities to really screw things up than in classic ASP.

      I haven’t had a chance to really look at the new MVC architecture that Microsoft is putting out, but it seems pretty cool. However I fear that we are adding another layer of abstraction on top of ASP.Net.

      As long as developers are paired with more experienced developers while they are learning and stick with a platform long enough to be good at it this additional complexity is ok (the additional features are good!), but I feel pity for the poor suckers that have to maintain my first ASP.Net application :).

    • Dan

      ASP made developers think in a top-down way, e.g. Response.Writing the page from the opening html tag onwards and throwing in bits of business logic along the way. Sure, templating and COM could be used by the conscientious among us, but there was very little to encourage clean and reusable UI code.

      With ASP.Net we have a fully fledged OO language, allowing real software development principles to be applied to UI development. You can’t equate WebForms solely with design-time RAD shennanigans (MS certified or otherwise). As always, it’s what you make of it, but with ASP.Net WebForms that “it” is now a lot more powerful. There are a many cross-cutting concerns that have been addressed by abstractions in the WebForms model and they are there to be taken advantage of.

      1) Is the WebForms approach of considering the page as a hierarchy of page elements (controls) a bad thing, when you compare the alternatives? This is, after all, what the cool AJAX kids are doing with client-side DOM manipulation.

      2) In turn, this allows us to develop reusable page elements in the form of WebControls/UserControls. The control hierarchy allows you to break down a page into a set of components in a way that observes SRP (e.g. controls that care about one thing, such as generating HTML from data supplied via a public property without caring about anything else) and the responsibility driven design approach (some controls are “displayers”, others play a “coordinator” role by handing off events between other controls).

      3) In turn (again), some kind of element id generation is crucial if you’re writing re-usable elements, from something as trivial as a calendar control onwards. Is the INamingContainer solution such a bad thing? It is not that hard to inject the ClientID of a control into your JavaScript code. Is it that bad that your controls are automatically assigned an id like “control1_summary_price_item1_startdate. What is the alternative? Maybe a more open-sourcy solution will use a different character to the underscore and people will love it.

      4) The controversial ViewState is basically an abstraction of manually adding hidden form fields. In principal this is not evil. ASP.Net out of the box encourages you to rely too much on this feature. However my main point is that Webforms allows you to write pages that aren’t overly reliant on unnecessary viewstate.

      I don’t understand why the entries for the recent “Be the 50th Person to Write a Negative Article about WebForms with the Term ‘Leaky Abstraction’ in it” competition do not take these advances into account.

      The root cause of UI spaghetti code on any platform is a lack of discipline and attention to well-known software design principles (especially something as simple as DRY). Is it because the more experienced coders tend to move towards what are seen as more complex areas of development like the domain layer, while the juniors are left to “just” generate the HTML?

    • Kris

      I’m currently on a contract trying to breath some life into a thoroughly mangled ASP.NET application. Having seen the equivalent in ASP, I wondered just a few days ago if it was really better under ASP.NET. With WebForms, you have more complexity, and more ways for inexperienced and unskilled developers to get it wrong. A big part of what was wrong with ASP was how people were designing applications with it, and not necessarily the technology itself. I think you can grok ASP *much* quicker than ASP.NET today. You can write clean ASP pages, but it requires discipline.

    • Dan

      That questions are now answered even by Microsoft with the MVC project.

      But I actually believe the WebForms model was a brilliant idea when .net was in beta stage. A layer of abstraction for fighting the differences between browsers ( IE, Netscape… )

      Imagine yourself building a web framework 7 years ago and now hearing people talking about how it is outdated… of course it is !!! :-)