Tales from the Evil Empire

Bertrand Le Roy's blog


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff


Tell me what smells in WebForms as a view engine

Fisherman's Friend Don’t read too much into this, but I’d love to read your feedback on this. I’m compiling a list of stuff that smells in WebForms when used as a view engine in MVC.

Along the lines of:

  • Noisy page directives that are useless for MVC
  • runat=server
  • Page lifecycle

For once, you can let the inside troll take over :)


Scott Galloway said:

Really it's using a Pile Driver to crack a peanut.WebForms is designed to enable completely different scenarios and isn't suited to MVC IMHO.

# July 13, 2009 2:17 PM

Simone said:

All the webforms method that popup in the intellisense, the webform code snippets, the fact that you have to encode all the output manually (with spark all response.write are automatically encoded), but obviously the 3 biggest ones are the ones you wrote: page lifecycle and runat=server for the mvc controls

# July 13, 2009 2:24 PM

Adam D. said:

You're kidding, right? :)

# July 13, 2009 2:38 PM

Scott Allen said:

In addition to your list:

Server controls in Intellisense.

Having a default of AutoEventWireup="true" baked in the framework (a micro-optimization, perhaps, but you could save everyone a lot of cycles if it was off for views).

# July 13, 2009 2:49 PM

Eric Hoff said:

Personally, I use them all the time.  Most of the complaints I've seen on Twitter revolver around the fact that User Controls and Pages don't render as strings (though I'm sure you can hack around that).

For most things in the page you use <%= ... %> but with Partials and BeginForm you use <% %> blocks.

# July 13, 2009 2:50 PM

Adam D. said:

ok, since you didn't publish my last comment, here's one:

master-detail grids

# July 13, 2009 2:52 PM

Joe said:

It's not NHaml.  :)

You've caught the big ones.  You've got a situation where all you really want to do is render data to the client but you've got a monster of an engine trying to do it.  It's like rolling out a quint to water my lawn (A quint is a piece of firefighting equipment that's both a fire truck (carries ladders and equipment) and a fire engine (carries water, has massive pumps).  Yeah, it'll get water on my lawn but I'll never need those laders or the gallons-per-minute that a quint allows.

# July 13, 2009 2:56 PM

Matt Kellogg said:

At least in C#, my biggest complaint is the bracket mess.

# July 13, 2009 2:58 PM

Scott said:

WebForms views are untestable. No way to access the content during a test due to the dependency on HttpContext.

ViewData Dictionary magic strings.

# July 13, 2009 3:02 PM

Chris W said:

Some of these may not be strictly from webforms, but here you go...

Viewstate, Random 'Invalid viewstate' errors, random validation of viewstate MAC errors, Postbacks, freaky control id names in html, too many events in control life cycle, having to remember the control life cycle...  

ASP.NET is pretty cool, when you avoid the above list and add in jQuery.

# July 13, 2009 3:30 PM

Mark S. said:

Similar to someone elses view, but MVC is the screw (a small machine screw), and WebForms is the 30lb sledge hammer.

# July 13, 2009 3:35 PM

Marcus McConnell said:

Adding and Removing Controls after a page has loaded can cause viewstate errors.


MVC still requires Session variables which requires a session state server for web farms.

Problems with intellisense for <%=MyVar %> not working inside some tag attributes.

# July 13, 2009 5:23 PM

Steven Berkovitz said:

Not being able to add controls to the page header if you have a <%= %> block in it

Repetitive code writing in properties that access viewstate (if null, return something, else, cast and return)

Validators and all the markup (both html and javascript) that gets emitted when working with a scriptmanager

# July 13, 2009 7:42 PM

Adam said:

The biggest issue i can see is the <% %> breakout and then breakin, then breakout, then breakin etc. Its difficult to see the html structure. Its the main reason why we rendered everything in strings using response writes to avoid the tag soup.

This is where something like spark gets it right. The intellisense is great though, but needs to be improved within attributes.

# July 14, 2009 7:40 AM

Pure Krome said:

+1 Scott Allen with AutoEventWireup="true". Gawd that upsets me :) I have to turn everything off and remove unless modules in the .config file.

every cycle counts for the pathetic lowtech code I produce.

# July 14, 2009 8:03 AM

John Goode said:

ViewState, period!

# July 14, 2009 11:13 AM

Andy said:

Would like to use WebForms ViewEngine for email view templating, but WebForms writing directly to Response stream cuts this out.

# July 14, 2009 12:38 PM

Steve said:

Difficult to implement dependency injection.  

Most of the time, the biggest complaint I have is that developers use the code behind as a place to put a ton of code.

Too much viewstate.  Sending all that data with heavy controls with viewstate.  Complex scenarios with postbacks.  Outside of demos, pages get complex in a hurry.

Difficulty using javascript.  ie. id mangling.  With mvc using something like jquery or ms ajax is a breeze in comparision.

# July 14, 2009 7:54 PM

Steve Sheldon said:

I don't think your question is clear... People are responding regarding WebForms as a framework, and not just the view engine.

Personally I guess I'm at a point where I don't really care.  Perhaps I should look at these other view engines to see why they might be better.

# July 15, 2009 11:40 AM

Rick Strahl said:

The Web Form View Engine for MVC is pretty decent IMHO but then I'm biased towards Web Forms in the first place :-}. Personally I *like* the fact that the engine has a lot of power to do at least conditional logic and some basic logic for accessing existing components via code if necessary for rendering content which is missing from some of the other view engines.

One thing that I think should be fixed is Intellisense for <%= %> tags inside of quotes/attributes which doesn't work and for me ends up being the 80% use case for expression tags.

I guess it depends on philosophy. Purists will hate it, but if you're trying to reuse existing functionality ability to access it with minimal logic is a big plus in my book.

# July 23, 2009 3:50 PM

Peter said:

Maybe not related to your (vague) question, but why can't I write this?

<asp:TextBox runat="server" Text="<%# "abc" + someint %>" />

I have to actually write this:

<asp:TextBox runat="server" Text='<%# "abc" + someint %>' />

Notice the single quotes for Text. But what if I need to use a single quote inside the <%# %> block? I can't write this:

<asp:TextBox runat="server" Text='<%# "abc" + someint + 'x' %>' />

So I'm stuck on alternating quotes... Why in the world can't the parser just say "whatever is between <%# and %> should be a "unit" and don't look inside for the ending quotes that wrap the thing... Ohh, and there's zero Intellisense when you have an expression for a property, but that's a VS issue.

# July 31, 2009 12:22 AM

Peter said:

No being able to compile the view or at least VS to tell me there's something wrong with it before I test it out in the browser. It's like you have this nice static, compiler-checked code (c#, vb, etc) and then you have this dynamic, flaky code in the view that may or may not work...

# July 31, 2009 12:27 AM

Bertrand Le Roy said:

@Peter: you can omit the quotes around the <%# %> block, they will get added for you in the rendered markup.

# July 31, 2009 12:53 AM

chanva said:

Maybe we should make "for" and "if" as built-in tags.

# August 14, 2009 11:45 AM