While there’s no question that HTML, CSS, and JavaScript form the foundation of modern web development, achieving fluency hasn’t been easy for everyone. In particular, the transition from stateful development with pixel-precise layout – such as VB6 offered – has proven to be especially difficult. HTTP’s stateless nature and HTML’s relatively imprecise layout present a new, different set of challenges.

WebForms aspired to insulate us from those inconveniences. Promising rapid, drag ‘n drop layout and event-driven programming, WebForms was an attractive choice for anyone struggling with web development closer to the metal. Unfortunately, it has become apparent over the years that the WebForms abstraction, while convenient, can easily cause more problems than it solves.

More recently, Silverlight’s WYSIWYG layout and choice of familiar CLR languages have made it a similarly enticing alternative to HTML, CSS, and JavaScript among some .NET developers, but is history repeating itself? Are we leveraging Silverlight to move the platform forward or is it being used as another crutch?

Specifically, I want you to consider three areas that are negatively impacted by overzealous use of Silverlight: Usability, accessibility, and maintainability.

Usability

The Microsoft Thrive for Developers site (which has some great content) is what originally motivated this post. I’ve been percolating these concerns for some time, but my initial experience there served as a lightening rod for them.

After landing on the page, I was greeted by this progress indicator and watched it load for several seconds:

Expecting something worthy of using Silverlight, I was content to wait on the Silverlight to load. Unfortunately, the entire thing turned out to be nothing more than a simple horizontal accordion:

Even forgiving the excessive load time, these Flash/Silverlight-based horizontal accordions are a plague on usability. If you put something in my browser that looks like links and images, it should behave like links and images!

A partial list of the various usability problems that arise include:

Context Menus – When I right click a button intent on opening a link in a new tab or window, seeing a context menu with a single “Silverlight” option is not a good experience. Eliminating the standard context menu defeats several features that you may not use, but some of your users do.

Similarly, when your site thwarts the gesture plugin I use, you’re only hurting yourself. When I can’t drag a site’s links into background tabs without interrupting what I’m doing, I’m far less likely to view as many pages as I normally would.

Browser History – Just as with WebForms before, fully Silverlight based sites break the browser’s expected history, navigation, and bookmarking features by default. There are workarounds, but it’s uncommon to see them actually used.

Text Field Interop – Because Silverlight TextBox controls are not HTML input elements, they sacrifice a wide range of functionality, from password managers to the ability to drag ‘n drop selected text to and from these fields.

Using these islands of Silverlight reminds me of the usability of WebForms Buttons and LinkButtons used for navigation, which have the same problems. It wasn’t a good idea to break the browser’s basic functionality then and it still isn’t now.

Accessibility

It’s no secret that plugin-based technologies like Silverlight obscure their content in an inaccessible manner. Tempting as it sometimes is to turn a blind eye to this problem, accessibility is something that everyone should care about.

Though Microsoft is taking great steps to mitigate Silverlight’s accessibility issues, by embracing the W3C’s ARIA initiative, ARIA is no panacea. It is a compromise to improve the situation, but not a solution to the fundamental problem. In fact, the W3C’s first recommendation when building an ARIA compliant application is:

Use native markup when possible.

 

Use the semantic elements that are defined in the host markup language. For example, with HTML or XHTML, it is better to use the native checkbox than to use a div element with role checkbox as these should already be accessible through your browser.

Even if every one of your site’s users are without physical impairment, accessibly designed sites yield a variety of other benefits as byproducts. For example, what do you think a search engine spider will glean from this markup?

<object data="data:application/x-silverlight-2," 
        type="application/x-silverlight-2" 
        style="width: 775px; height: 273px;">
    <param name="source" value="xap/ThriveSilverlight.xap"/>        
    <param name="background" value="transparent" />    
    <param name="windowless" value="true" />
    <param name="minRuntimeVersion" value="2.0.31005.0" />
    <param name="autoUpgrade" value="true" />
</object>

Probably not much. At least it might rank well for application/x-silverlight-2.

Now, compare that to the semantic HTML markup that might be used to implement the same functionality with a bit of CSS and JavaScript:

<ul>
  <li id="Advance">
    <h2>Advance Your Career</h2>
 
    <p>Take control of your career path. We've got industry 
    experts and developer community leaders to give you a hand.</p>
 
    <a href="Advance/CareerResources">
      <img src="GetCareerResources.png"
           alt="Get Career Resources" />
    </a>
 
    <a href="Advance/TrainingCert">
      <img src="GetTrainingResources.png"
           alt="Get Training Resources" />
    </a>
  </li>
  <li id="Enhance">
    <!-- More content here -->
  </li>
  <li id="Connect">
    <!-- And again -->
  </li>
</ul>

The difference speaks for itself.

In the same vein, an application that exposes its content accessibly is one that is resilient to change. The ability to easily screen-scrape HTML sites has led to some of the most interesting and useful applications online.

Where an accessible app out often matures into something of a loosely coupled data source toward its end of life, walled gardens of Java, ActiveX, Flash, and/or Silverlight are too opaque to offer that lasting benefit after they’ve become dated.

(un)Bonus: Mobility

Speaking of accessibility, take a look at this same site on an iPhone, which has arguably the best default mobile browser currently available:

HTML 5, CSS3, and JavaScript are probably the future for several classes of mobile applications. In fact, mobile support can be as easy as dropping in a new view for each device. Something like the (awesome) Chipotle iPhone app could just as easily be a mobile view using jQTouch.

With the growing ubiquity of devices like the iPhone, Palm Pre, and Android-based handsets, catering to mobile browsers is becoming an important consideration. Even if it’s still a minority use case (for now), users gravitate to sites that do work well with their mobile devices in that occasional pinch.

Maintainability

Long-term maintenance is a critical consideration when using plugin-based tools.

Think about all of the decade-old web applications that your business or clients are still keeping alive today. How many of them encapsulate important functionality within ActiveX controls? Probably almost none, and there’s a good reason for that.

These monolithic rectangles rot at a frightening rate. Maintaining plugin-based functionality entails more friction and a less widely available skill set than updating HTML markup, tweaking a CSS stylesheet, or changing a JavaScript include. More often than not, these opaque rectangles simply fall by the wayside over time, and might as well be chunks of the website written in COBOL.

If segregating functionality into plugin-based walled gardens was a good idea, we’d still be using Java applets for rollovers in navigation menus.

Silverlight and WebForms aren’t the problem

To be perfectly clear, I think Silverlight is great.

Given the choice between Flash or Silverlight video, I’ll choose Silverlight every time. The video playback is smoother and Microsoft’s great development tooling tends to encourage feature-rich player applications. Even with HTML 5’s <video> element, browser-native video can’t currently compete with Silverlight.

Given the choice between developing an internal dashboard in Flash or Silverlight, I’ll choose Silverlight every time. The charting controls already available even after Silverlight’s short time on the market are awesome, and only getting better. HTML 5’s <canvas> may eventually become the best solution for this, but it’s going to be years before that’s a feasible reality.

There are plenty of scenarios where I think Silverlight is perfectly valid. Though it might be easy to take it that way, this is not an anti-Silverlight (or Microsoft) post.

In fact, I think WebForms is fine too.

Used responsibly, WebForms is still a useful and productive abstraction – especially with the great improvements coming in ASP.NET 4.0. There are plenty of times when something like Dynamic Data to scaffold an administration interface is a smart choice.

Conclusion

Bottom line? You should use idiomatic HTML, CSS, and JavaScript if they are at all able to accomplish what you’re trying to do. Embrace the platform.

More specifically, not wanting learn JavaScript is not a valid excuse for pretending it isn’t the Lingua Franca of the web. Many even find, to their surprise, that they enjoy JavaScript once it’s paired with a library like jQuery to abstract away the DOM. Using the tools currently available, it’s easier than ever to learn too.

Having keenly watched the ebb and flow of web technologies over the past fifteen years, I’m comfortable predicting that an investment in learning the underlying basics is crucial if you’re serious about developing for the web. Anything used to avoid this fundamental understanding is a crutch, not a tool.