Tell me what smells in WebForms as a view engine

24 Comments

• 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.
  

• 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
  

• You're kidding, right? :)
  

• 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).
  
  

• 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.
  

• ok, since you didn't publish my last comment, here's one:
  master-detail grids
  

• 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.
  

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

• WebForms views are untestable. No way to access the content during a test due to the dependency on HttpContext.
  
  ViewData Dictionary magic strings.
  

• 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.
  

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

• Adding and Removing Controls after a page has loaded can cause viewstate errors.
  
  Runat="server"
  
  MVC still requires Session variables which requires a session state server for web farms.
  
  Problems with intellisense for not working inside some tag attributes.
  
  

• 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
  
  

• 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.
  

• +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.
  

• ViewState, period!
  

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

• 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.
  

• 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.
  

• 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.
  

• Maybe not related to your (vague) question, but why can't I write this?
  
  <asp:TextBox runat="server" Text="" />
  
  I have to actually write this:
  
  <asp:TextBox runat="server" Text='' />
  
  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='' />
  
  So I'm stuck on alternating quotes... Why in the world can't the parser just say "whatever is between 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.
  

• 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...
  

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

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