Those Dangerous UpdatePanels and “The Intern”

At my current contract I am saddled working with an intern. He’s a bright kid, and he’s gone through three years of school, but I’m kind of staggered by how much he doesn’t actually know! Development is extremely difficult because he doesn’t know much about JavaScript, AJAX, jQuery, CSS styling and positioning, Web Services, C#, UpdatePanels, LINQ, Ruby on Rails, MVC, DLL Libraries, ReSharper, and the list goes on and on! It’s hard to believe what eight years of experience teaches you, and I’m finding it difficult, and sometimes limiting because I have to move at a slower speed bringing him up to speed.

I was using some cool features of jQuery to do AJAX instead of using UpdatePanels, but when The Intern wanted to do some AJAX he got totally lost. In the end I taught him to use both jQuery and (despite how dangerous it is), Ihow to use UpdatePanels.  In the end I encouraged him to use the UpdatePanel with his pages, read on to find out why.

1.  Updating the DOM using jQuery and Web Services is an Advanced Skill

Oh yes, both you and I can look at the code and figure out exactly what is happening.  We see the JS file linked in the ScriptManagerProxy control, we can follow the JavaScript code to the webservice call, and even more, but it is a very advanced skill.

2.  Updating the DOM using jQuery and Web Services Reduced Maintainability

Even with all of my knowledge, it’s still a long, messy trail of code until you get to the end (the web service). You’re crossing several files, including C#, ASPX, JavaScript, and ASMX files.  In my opinion this drastically decreases maintainability and makes the code much less readable and obvious to other .NET developers, even those who have read Encosia’s article.

3.  Using UpdatePanels Doesn’t Change the ASP.NET PostBack Model

The UpdatePanel is just another ASP.NET tag.  The PostBack model is retained, you still have Button OnClick events, you still have TextBox.Text, Page_Load etc. All of the code is still retained within one ASPX/ASPX.CS file pair. Almost any .NET developer, no matter how junior, should be able to follow this code. That makes the code maintainable.

In the end, even though jQuery will be shipping with future versions of ASP.NET, the .NET Framework, and Visual Studio, it’s still a relatively new concept. We need to proceed with it, but this is new ground so we have to blaze a trail that the slower movings guys can follow.

One of the big benefits we have as .NET developers is the MSDN Library. I like to use MSDN as a scale for maintainability. If it is in MSDN then I consider it general knowledge that a new developer should know or be able to find easily. Otherwise I have to document it really well so that at least a mid-level developer should be able to figure out my application.

We have to be careful that the people maintaining the code behind us know what we’ve done, otherwise our awesome code gets rewritten by newb developers who can’t figure it out. If we can write maintainable code then hopefully the developers behind us will learn something and eventually become more advanced in their skills too.

One Reply to “Those Dangerous UpdatePanels and “The Intern””

  1. I hear you on the “grossness” of UpdatePanels.

    We use RadControls from Telerik so RadAjax abstracts away the UpdatePanels even further. I was finding them terribly slow.

    I found an exceptable compromise was using the built in AJAX model but doig all my updating with JS callbacks through ResponseScripts.

    Performance was good and I got to ignore some of the code holding things together.

Leave a Reply

Your email address will not be published. Required fields are marked *