Crazy Talk: Inline Scripting and Code-Behind

As if I haven’t been flamed enough in the last few days (and I still have a few minutes left on my Fire Ward), I’m going to challenge the notion that Inline Scripting is a relic of Web 1.0, and that it has no place in today’s ASP apps. I take a slightly different view, and that is that many times inline scripting is preferable because it forces you to write less UI code, decreases ViewState abuse, and can result in cleaner, more manageable HTML.

Inline scripting gets a bad wrap in the ASP world. Many people avoid it like the plague and you’re branded as a “Spaghetti Hack” who “codes like it’s 1999″. I’ve stared, open-mouthed, at these words in the SubSonic forums as people have questioned my preference for inline scripting. I’ve been meaning to write this post for a while, and this weekend I’ve finally had the chance since the inlaws are in town .

I like what Atwood has to say about it:

After religiously adhering to the new, improved code-behind model of ASP.NET for so long, I have to admit it’s sort of refreshing to rediscover inline code ASPX pages again. Deploying single web pages to a server without recompiling the entire solution? Making localized edits to single pages that take effect in real time? A single file that contains both code and markup in one convenient self-contained package? Revolutionary!

but then he finishes with this:

Unfortunately, Inline ASPX pages also remind me of some things I didn’t miss from the bad old days of ASP programming: spaghetti code, extremely limited intellisense, and crappy debugging

That post was written in 2005. Today, however, with Visual Studio and ASP 2.0, we now have great debugger support in the designer and intellisense so that mitigates a lot of concerns that people have. In terms of Spaghetti Code…

Spaghetti Code
It’s not easy to write spaghetti code using .NET, but there are many who manage to do it. From Wikipedia:

Spaghetti code is a pejorative term for source code which has a complex and tangled control structure, especially one using many GOTOs, exceptions, threads, or other “unstructured” branching constructs. It is named such because program flow tends to look like a bowl of spaghetti, i.e. twisted and tangled

So Spaghetti code makes it hard to understand what an app is doing during execution. I think this is more a function of what ASP’s CodeBehind model allows you to do, versus the concept of “scripting the UI”. Spaghetti is as Spaghetti does…

In purest terms, scripting the UI should literally be a visual expression of logic, NOT the logic itself. To that end, simple, VERY SIMPLE routines in the UI are acceptable (and needed) when scripting. This is an important aspect of this discussion: Logic does not belong anywhere near the UI!

Rails has some neat guidelines to follow when working up their views:

• If you declare a variable in your View, you’re doing something wrong. This suggests logic and you should use a helper or your controller.
• Data Access is the UI is verboten.
• If your eRB (the Ruby code in the page) is more lines than the HTML, you’re doing something wrong

To dive into this further, let’s use the ubiquitous GridView example. For fun, let’s see what it takes to do something simple, like link to an editor page from a grid. I’m using Northwind, SubSonic, and ASP 2.0 Web Site for this example.

GridView with ObjectDataSource, bound to Products.Fetchall() – a BLL method

The designer makes this trivial- I just hook up the ODS to ProductController.FetchAll() (using SubSonic) and I’m well on my way! Not one to be fooled by a designer’s simplicity, let’s take a look at the markup:

Let’s hook up the select events. Here’s the code:

Now let’s do the same thing using inline-scripting (the Controller in this example is my BLL):

So consider:

• There’s about 1/3 of the total code with the inline solution
• You can read and grok what that page is doing in one glance
• Complete control over the HTML
• No ViewState
• No recursive control tree loads/parses, making the page faster…
• Easy to debug (since ASP 2.0 allows you to debug in the designer)
• Yes, you DO have intellisence

I need to keep my HTML and Code Separate
Why is that anyway? Designers use Photoshop, and think in terms of PSDs. Designers don’t use Visual Studio (I think it’s a rule in SOMA that you have to turn in your Mac if you ever look at the Visual Studio’s Medusa Glare [the white screen of pain when it stalls]).

You might be one of the lucky people on the planet who’s workplace hires an HTML gunslinger (I’ve worked on 3 projects like this). These guys are usually the mock turtleneck-wearing guys who hang out by your desk trying to learn to code . These guys know Visual Studio, but also know “runat=server” and “<%” means “don’t touch”.

Inline Scripting Is Slower
Not at all. From Jeffrey Palermo:

My colleague insisted that script block incur and extra performance hit because the ASP.NET engine must check for changes in every page hit.  After lunch, I whipped up a test and created to ASP.NET pages:  one with code-behind, and the other with the code in a script block.  I ran each for 1 minute in WAST.  Then I ran each 8 more times.  My results:  It doesn’t make a hill of beans difference.  Each test was less than 1% difference

Inline Scripting Is Ugly
If you ask me, XML is ugly. Code is wonderful. I can read code easily and I (usually) can grok what was intended, Declarative markup (which is XML-based) just sits there, telling me nothing. This is subjective anyway and you can always toggle script blocks shut.

Only Hacks Use Inline Scripting.
Could be true, but if you take a second to look over the walls of the MS Schoolyard you’ll see the kids playing with all kinds of code-based markup. Rails, PHP, Django – all use this style of programming. It’s effective, and actually breeds LESS code (see below). The most popular platforms in the world… I’m hoping you’re at least considering this by now…

Here’s a virtual beer . We’ll make it through the rest of the post together…

Inline Scripting Breeds Crufty Pages That Are Hard To Read
It absolutely can, but often the issue is not with scripting as a practice, it’s with the developer’s coding style. Spaghetti is as Spaghetti does. If you drive yourself to rip out any logic from your UI, scripting becomes enlightening and fun.

If you’re a Server Control Junky (use Image Controls, Hyperlink Controls, etc) I would ask you to consider whether the use of these controls (when not using skinning or required eventing) is warranted. Consider the Page Life Cycle:

1. Start: Request and Response are loaded. IsPostBack is determined
2. Init: The ViewState is decrypted, the control tree is created and parsed. Themes are applied (if present)
3. Load: All settings are applied using the ViewState settings (if IsPostBack)
4. Validation: Any and all validators go off
5. Eventing: If you’ve called an event, it’s fired
6. Rendering: ViewState is recreated, walking the control tree (all setting are encrypted and dumped into a hidden input). In addition, each control’s “Render()” method is called, and the HTML is created from the control stack.
7. Unload: GC and cleanup

Generally, this stuff is pretty quick and you don’t need to worry about it’s execution. But if you don’t need it to run at all, why do it? I’m not saying server controls are evil – I’m saying you should carefully consider whether they’re needed.

With code behind, you get a big rug that you can sweep your code under. It can lead to bad habits (like too much code) and also cause slow downs that just aren’t needed. 

CodeBehind 2.0
I think it’s time to lean harder on the notion of UI scripting as just that: visually representing logic. CodeBehind is (most of the time) overkill for this . When .NET was introduced this seemed like the way to go (cause they told us it was). Now that it’s 5 years later, it’s time to revisit this notion – especially in light of the new MVC framework that’s right around the corner.

Do you really need two pages, when one will do just fine?