Tony Lombardo

When talking about Silverlight, it is only natural to compare it to standard web based applications (ASP.NET, PHP, JSF, etc.).  Silverlight has some clear advantages when dealing with large quantities of data, or speed and performance in say grid operations, but there’s another aspect of Silverlight that may be hard to notice at first.  It’s the ‘little’ things.  I call them little, because alone, each of these features isn’t something that will shock or amaze you.  But combined, these features create a User Experience that is specific to Silverlight.  Let’s take a look at a few examples.

Above is the Infragistics XamWebGrid in GroupBy mode.  The part to notice is the small x that shows up when you mouse over the Group indicator.  It makes it easy for a user to figure out how to ungroup the data, and that’s just the start.  Notice the shape of the Group indicator?  When you group by multiple columns, these fit together like puzzle pieces.  Again, indicating to the user exactly what’s happening as shown below.

The differences are very subtle, like a glow animation when you mouse over a button; the same type of differences you see between Windows Forms and WPF.  But these subtle differences can create a totally different experience for a user.  The application feels more alive, and when these features are put to good use, like in the example above, the UX of the application can be improved.  And here I thought storyboards and animations were only used for 3D rotating textboxes with movies playing in the background..

I’m not sure there’s ever been quite as much activity in the world of Web development as in the past couple of years.  The browser ‘wars’ have been re-ignited, and technology is advancing at a frantic pace.  It’s almost too much to keep up with.  Right now as a web developer you have Silverlight 2 at your disposal, and a beta of Silverlight 3, with talks of Silverlight 4 already taking place.  Then there’s the CSS 3 specs, HTML 5 specs.. it’s almost too much to comprehend.  I guess we’re lucky in a way, that there are currently significant barriers keeping us from these technologies.

Let’s take a look at Silverlight first.  With clear advantages in performance and usability over standard HTML/JavaScript, Silverlight looked like a definite winner for many web applications.  But Silverlight suffers from one big disadvantage – the plugin that needs to be installed.  That simple plugin which only takes a minute to install, is preventing widespread adoption of Silverlight across corporate America.  As with any new software, IT must first test Silverlight on their systems, and then come up with a rollout plan which as many of you know, is not something that happens overnight.  So even with 3 versions of Silverlight in 1 year, many developers are just now getting the nod from corporate to start discussing the option of using Silverlight. 

CSS3 and HTML5 promise to change web development (in a good way), but are both being held back by standards committees and browser support (or lack there of).  In all likelihood browsers will implement the features of these specs before the specs are actually complete.  But even the implementation will likely happen at different rates for each browser.  The reason most of us write web applications in the first place is so that one page can be viewed in any browser on any computer by any user.  Which brings us back to IT, the guys who will inevitably be forced to hold back the latest versions of these browsers from being installed, so that they can be properly tested and a deployment strategy can be planned. 

While all of these new technologies promise to revolutionize web development, it’s unlikely the revolution will happen as quickly as any of us would like to see.  IE6 is still the corporate standard browser in many organizations.  The good news for developers is that it gives you extra time to learn the new technologies.  And if there’s one thing I know, it’s that you can accelerate rollouts if you prove a valid business case.  Show the IT director a prototype of the app you just put together using Silverlight 3 that took you half the time to write and solved the UX and Performance problems of the current html based application, and a Silverlight rollout is likely to be around the corner. 

Developers are often cast into a group and stereotyped as "visual design challenged”.  The fact is, a true Visual Designer picks colors and creates designs for applications that make my attempts look like grade school arts and crafts project.  But that doesn’t mean developer’s don’t care about design.  Actually, I think most developers put a tremendous effort into trying to make their applications look good.  It’s just that the results aren’t always award winning..

I used to get insulted when people would mention that developers weren’t good at styling applications.  From the first day I started coding, I was the only one working on my applications.  The application was my creation, and I was responsible for every aspect of it, including the design.  By hearing generalized statements about how developers are bad at visual design, it was like telling me that I don’t have the entire skills I need to build a successful application. 

Luckily, I’ve grown up a little since then.  While I still don’t like hearing I’m not good at something, I can certainly respect that there are professionals in the visual design world who can do a much better job of making my applications look good.  I can spend 2 years writing the most beautiful code, but at the end of the day, the user only sees the User Interface.  UX is perhaps the most important aspect of an application, because it encompasses all aspects of the application.  If the code was buggy, the UX will be poor.  But more importantly, if the code was perfect and the UI design was not, the UX will be sub-par.  Want proof of just how important the UI/UX is?  Take a look at Facebook vs. MySpace. 

MySpace was the clear favorite two years ago, so what happened?  The MySpace page was ugly by default, and users could do anything they wanted to make it even uglier.  Sure, customizing your page sounds like a good idea, until you realize that you’re not that good at it.  Facebook took a different approach – a fixed  UI that looked good out of the box.  Facebook users didn’t need to spend time making their page look good, and more importantly, you didn’t have to look at hundreds of other bad looking sites.  Take another example, the iPhone.  Apple cares about it’s image so much, that all iPhone applications need to follow design guidelines, and must be approved before they can be made available to iPhone customers.  Still not sold on the importance of UI?  Remember geocities?  How could you not.  An entire domain of horrendous designs.  The negative experience associated with those bad designs is something that sticks with you.  I don’t remember if I ever found anything functional on geocities, I’m sure I did.  But that’s not what I remember.  I remember the horrible color choices, images with choppy edges (that of course weren’t transparent), and JavaScript errors. 

There’s a point in here somewhere.  Oh yeah – designers are a developers best friend.  Designers make developers look better.  After I spent 2 years on a project, of course I want people to think it’s the coolest thing they ever saw.  But my late nights of coding are essentially going to be judged on how good the application looks, not how well I wrote the code.  I remember the days of getting beta feedback like, “It’s not colorful enough, can you add some color to it?”  I would go back to my desk, bummed that no one shared the same excitement as I did that the project was complete.  But in actuality, it wasn’t complete.  It was functional, but that doesn’t make an application “done”.   So, I’d go back to my desk and throw a few different colors around the application (usually different shades of blue) and try again.   I spent weeks just experimenting with different colors to see if I could produce something a *slightly* more visually appealing.  Weeks that I could have spent on my next project.  I certainly don’t miss those days.  Today, visual designers take the code that I wrote, and bring it to life, and they do it in far less time than I ever could have, with far better results.  They might hand me back a wireframe or a mock-up that I need to convert to code, or if I’m lucky, they’re just modifying the XAML or CSS directly for me.  And when I hear comments about how cool an application is, I know that without my code, that would have been nothing more than a static image.  I bring designs to life, designers bring my code to life.  It’s amazing that I ever did both the design and development.  And it’s even more amazing that I resisted change at first. 

Working with WebControls and WebForms for the past 8 years has taught me a lot about web development.  The one thing that I learned above everything is that the onus is on the developer to write good code.  Now that may not sound like something revolutionary, but the fact is that ASP.NET WebForms makes building web applications easy by abstracting away some of the difficulties of a stateless protocol.  And it also makes it easy to forget about what’s actually happening behind the scenes to make everything possible.  Does that mean WebForms is flawed?  No.

MVC offers a fix for some of the problems that WebForms has been plagued with.  Problems like bloated ViewState, and that ‘pesky postback model.’  On the surface, this looks like an attractive solution for every web developer out there.  A promise to get rid of ViewState – a web application’s mortal enemy?  It has to be good. That is until the application your building needs some sort of state mechanism, and you begin re-inventing the wheel.  I think it would have been much easier just to go back to you WebForms application and disable ViewState. 

The problem right now is that there is so much focus over why MVC is better than WebForms, that everyone is forgetting a basic rule of software development: use the right tool for the job.  I’ve said it dozens of times, MVC has a set of scenarios that it first very nicely, as does WebForms.  One platform does not need to be declared a winner – they’re two equals that should be placed into your metaphorical toolbox.  So who is actually losing right now?  The developer community that is caught in the middle of this faux war.  Developers who think that they have to move to MVC out of pride or fear that WebForms will be replaced by MVC.  Developers who are only hearing one side of the story right now at local community events and tradeshows because let’s face it.. WebForms isn’t sexy anymore at 8 years old.  Ironically, this same issue of “sexy talks” was discussed last week at NDC with Scott Hanselman behind the camera.

Conferences aren’t picking talks about “the old stuff”, because they’d rather focus on what’s new.  New is sexier, and conferences are all about attendance numbers.  But here’s what these conferences don’t seem to understand – every day there’s a new developer joining the community who needs to start from zero.  Developers gauge what’s important by what’s being talked about, it’s why we have trends and tag clouds.  It’s human nature.  If I hear 100 people talking about a subject, it must be important.  Right now I hear 100 people talking about MVC, and no one talking about WebForms, so I guess MVC is more important, right?  That’s the type of thinking happening right now, and it’s nothing new.

“MVC brings web development back into ASP.NET”, is one of the most common arguments I hear for its use.  Yet the whole reason for WebForms existence was to free you of the dirty details of building a web application, and let you focus on your business logic.  To give you a set of functionality to be able to build on top of, the same focus for every library and framework out there.  It’s why you don’t have to write browser specific JavaScript when using jQuery or ASP.NET AJAX, and it’s the reason we don’t still program in machine language.  Can I write a tighter loop in assembly than I can in JavaScript?  Sure.  But for the applications I’m writing that’s not going to be an issue.  Maybe I’m writing an application where performance is the top and only concern.  Now writing the application in assembly doesn’t sound like a crazy idea.  If my requirements were to build a spreadsheet like application that offers filtering, copy and paste and exporting to excel, I’m going to jump to WebForms.  That’s the whole point behind using the right tools for the job. 

I read a blog post today that talked about how you should dump WebForms and go with MVC as soon as possible, so you can get back to web development roots.  The argument just didn’t make sense to me.  It’s like asking me to stop coding in C# and move to C++ because C# developers just don’t understand pointers and memory allocation. 

So here’s my call to action.  Rather than talking about why one framework or platform is better than the other, start discussing when one is better than the other.  What scenarios is MVC geared for?  When would you use WebForms (MVP) instead? 

The best advice I’ve seen so far is that WebForms is the platform of choice for building web applications, where MVC is more suited to building web sites.  This is still a bit abstract since there’s no clear definition of web applications, but I think it’s safe to say that if you’re building a web version of a win client application, you’re building a web application.  If you have a ‘grid’ in your page for purposes above that of just layout, you’re building a web application. 

I hear a lot of overused and overloaded terms these days like “leaky abstraction” when talking about WebForms.  As people repeat these items like robot drones, I wonder if they truly understand what it means, and more importantly how it affects a developers ability to build software.  But whether it’s a group of robot drones, or an increasing number of well educated software engineers, we’ll leave for the subject of another debate.  Back to the matter at hand.  Of all of the WebForms complaints, it usually boils down to a few key issues – ViewState, ID generation and HTML Markup & Postbacks; each of which is undergoing changes in ASP.NET 4.0.

ViewState

To understand the first issue of ViewState, you have to understand the ViewState model.  It works recursively in nature, with each control responsible for initiating the loading and saving of ViewState from it’s child controls.  The problem comes when you turn off ViewState at a root level.  Since the parent control is no longer storing ViewState, it’s child controls get ignored.  Basically, you can turn ViewState off selectively for children, but you can’t turn it on selectively if it’s disabled for the parent control.   The solution?  ASP.NET 4.0 introduces the ViewStateMode pattern which is separate from the EnableViewState property.  ViewStateMode has 3 values, Enabled, Disabled and Inherit (the default).  When ViewStateMode is set to disabled, any child control that is set to Disabled or Inherit will have it’s ViewState turned off.  If a parent control has ViewStateMode=Disabled, and the child control has ViewStateMode=Enabled (the important new scenario), the child control will still have it’s ViewState saved.  This in essence, is what the feature is all about.  The net gain for a Web developer is a lighter weight page, because you now have the ability to turn off ViewState in places that you didn’t really need it on in the first place.  

ID generation

Have you ever taken a look at the html markup produced by an ASP.NET WebForms application?  I have.  Actually, I spend a good portion of my time examining html markup and discerning how a page can be made lighter or faster based on what I see.  One of the big offenders happens to be ID strings.  If you want to address an element, you need to give it an ID.  If you want to address it uniquely, you need to come up with a mechanism to make that ID unique.  In ASP.NET WebForms this was done by pre-pending the parent control’s id to the ID string of a control.  The problem is that as applications became more complex, so did the control hierarchies, which then caused UniqueID and ClientID strings to become unmanageable.  Looking at an application today, it’s not out of the question to see something like “contentPlaceHolder1:ctl0:ctl0:UpdatePanel1:Panel1:GridView1” Now if you use that string a few times to address id’s or create css class names, you’re bloating your HTML.  Even worse, you’re creating a recipe for cascading failures if you ever change the containership or the ID of one of the parent controls.  Suddenly, your element’s ClientID has changed, and you need to go through and update your code. 

In ASP.NET 4.0, you’ll have the ability to set the ClientIdMode to “Static” which solves most of these problems.  With a Static ClientIdMode, the ID string you set for the control, is the same string that will be used for the ClientID.  This has the benefit of being less fragile, and gives you the ability to clean up your markup by shortening ID’s considerably.  The drawback to using ClientIdMode=Static is that ID’s will not be ensured to be Unique by the framework, making this a manual task for the developer.  Not sure about you, but if that’s the biggest challenge of my day, I’ll be smiling.

HTML Markup & Postbacks

Postbacks were the bread and butter of ASP.NET 1.0.  Luckily ASP.NET has come a long way since then, and developers today understand that creating a good User Experience means limiting postbacks.  The amount of HTML rendered to the client also has a direct correlation on User Experience.  The more HTML/Markup, the longer a page will take to load.  ASP.NET 4.0 improves this key scenario by adding Client-Side DataBinding and templating.  Think of client-side templates as a repeater that get’s populated by JavaScript.  Why populate the repeater on the client-side rather than the server-side?  It’s a matter of multiplication.  Take the same 4 lines of HTML in a repeater template and multiply it by the number of items in your datasource.  Now push all of that HTML down over the wire to the client.  Make matters even more interesting, use the same datasource to populate a grid.  In a typical scenario, you’re pushing the same data down two times, once for the repeater, once for the grid.  If you had that data available as a client-side DataSource, you only send the data down once, and re-use it on multiple controls.  At the price of a little extra processing power to create the dom elements through JavaScript, you get the benefit of possibly drastically reduced HTML markup, and free yourself from relying on Postbacks in order to populate a list. 

The three features listed above are just a short list taken from the ASP.NET 4.0 features whitepaper.  Even in this short list, it’s easy to see that ASP.NET 4.0 is changing the face of WebForms.  Many of the concerns that developers have expressed and many of the advantages that MVC touts over WebForms are being addressed.  The point is, WebForms isn’t dead, it’s quite the opposite.