I’ve left the Silverlight team

I recently left the Silverlight team.  Silverlight is a great team to work for and I have tremendous confidence in the continued success of the product.  However at this point in my career platform development doesn’t appeal to me very much. I’d rather be much higher up in the stack working on user-facing technology.  To that end I’ve joined a research team that’s developing semantic web technology for Bing (among other things).

Unfortunately this will mean that I won’t be able to blog as much about what I’m doing because most of my work will be under NDA.  I can say that it is very exciting though!  If there’s one thing Microsoft does better than anyone it’s funding and productizing research (although there’s still room for improvement).

Working for the Silverlight team has been a real thrill.  It was great to be able to fight for and contribute features to the platform that I cared about. I’m proud to have been a part of Silverlight 4 and I can’t wait to use it on my new team.

A Modest Proposal: Pretty XSL

I’ve got a question for the authors of the popular MVC frameworks: What’s with all the custom view languages?  ASP.NET MVC uses ASPX files for their views.  Rails uses Ruby of course.  MonoRail has its own NVelocityViewEngine which has a python-like syntax.  Of course these frameworks allow you swap out these view engines.  However in my experience developers tend to default to using the one that ships with the framework.

Why not use XSL? 

The technical benefits of using XSL are compelling:

1. Use Less Bandwidth

Every major browser is capable of XSL transformations on the client.  After the XSL and CSS files have been cached by the browser an application server becomes responsible only for sending data and managing any application state.  This translates to massive bandwidth savings.

2. Enforce Model/View Separation

When it comes to view languages smarter is not better.  The more powerful a view language, the easier it is to inadvertently blend concerns.  XSL is a dumb language that is pure by design.  It’s like a technical straightjacket, sending a clear message to current and future developers about exactly what type of tasks are allowed to be performed.

3. W3C Standard

‘Nuff said.

4. Great tooling.

Some .NET developers may be unaware that it’s possible to step through XSL transformations in Visual Studio.  The experience is roughly on par with stepping through C# code in an ASPX.

Syntax Matters

Given all these benefits why do so many developers choose a different view language?  Here’s my theory: XSLT is ugly.  Anyone who has used XSL knows that its signal-to-noise ratio is abysmal.  Therefore propose a solution: The W3C should create PXSL (“Pretty Extensible Stylesheet Language”).  PXSL is a hypothetical non-XML language that compiles into XSL.  A stripped down version of Windsor’s NVelocityEngine or something similar could easily be compiled into XSL.

#foreach($person in $people)
#beforeall
       <table>
               <tr>
               <th>Name</th>
               <th>Age</th>
               </tr>
#before
                  <tr
#odd
                       Style='color:gray'>
#even
                       Style='color:white'>

#each
                       <td>$person.Name</td>
                       <td>$person.Age</td>

#after
                  </tr>

#between
                  <tr><td colspan='2'>$person.bio</td></tr>
#afterall
       </table>
#nodata
       Sorry No Person Found
#end

Some might think such an endeavor trivial or misguided.  I disagree.  There’s a relevant precedent to consider here.  Turtle (Terse RDF Triple Language) is a non-XML language for describing XML RDF graphs that has been submitted to the W3C.  Although it hasn’t yet been accepted as a standard it enjoys great tooling support and is widely used.  Although it is no more or less expressive than RDF it’s practical syntax is so compelling that it has found a foothold in the industry.

Use XML Where it Makes Sense

Whenever a new technology is introduced we hear a lot about its supposed benefits.  Some of these benefits pan out and some don’t.  One of the touted benefits of XML was that it was supposed to be human-readable.   While definitely an improvement on binary, many XML formats (ex. SOAP) are so complex that sifting through them in a text editor is very difficult in practice.  To increase productivity we are increasingly hiding XML from developers with designers, code generators, and configuration utilities. XML is a very mature data interchange language but there’s no reason to force developers to work with it directly.  A little syntax goes a long way.