Can I Replace My JavaScript Code With a Silverlight App?

Some say DOM scripting will end in fire,
Some say in Silverlight.
Still others say with much desire,
That either will suffice.

(apologies to Robert Frost).

The arguments I hear go like this: if a developer can build on a cross-platform CLR with a diverse selection of languages and still interop with the browser, than why would the developer stoop into the primordial ooze of HTML and script against a document object model that has more eccentricities than the city of San Francisco?

In other words, if I can write the following in C#:

... then why bother doing dynamic HTML using JavaScript? The tools built for C# code are far, far superior to anything written for JavaScript. Even when running a bare Visual Studio with no plugins - I have better refactoring tools, a better debugging experience, and (even in 2008) – better Intellisense when using C#. There are class diagrams, code snippets, and code browsers. Not to mention the support of a base class library that includes many features you won't find all in one place with JavaScript – real meat and potatoes stuff like string formatting and collection classes.

Certainly paints a bleak picture for JavaScript, doesn't it?

Well, one reason Silverlight doesn't replace JavaScript is that Silverlight doesn't run everywhere. If you want to reach the widest possible audience, including cell phones with a script interpreter - you'll still be giving JavaScript some love.

Let's take the best Silverlight scenario, however:

You are a hard core C# / VB.NET developer. You don't like JavaScript and you never want to work inside a paired set of <script> tags. You are writing an application that you will deliver to users who have the Silverlight 1.1 plugin installed, and all the boilerplate JavaScript code needed to bootstrap the plugin is encapsulated in a control (like the ASP.NET Futures Xaml control).

Do you ever need to touch JavaScript?

My answer is ... maybe (I'm hedging my bets because I don't know where Silverlight will be one year from now in terms of features).

There are some actions you can only perform in JavaScript (throwing up an alert box is one example that comes to mind). Reviewing the earlier code -  is the code isolated from cross-browser quirks? No. Is the API pretty? No - at least not when (in my eyes) compared to JavaScript and not even if we take away all the hard coded strings.

The real question is: are we gaining anything by writing this code in C# instead of browser's native JavaScript? I have to wonder. Funneling everything through a single type like HtmlElement feels awkward.

There are two things that could happen to Silverlight that would make me say - "certainly yes".

1. Silverlight gets a full-fidelity, cross-browser DOM API. Something along the lines of:

   document.getElementByID<HtmlImage>("id").src = "https://odetocode.com/odetocode.png";

   I doubt this is actually in the game plan for Silverlight, as in a way doesn't serve to further the main purpose of Silverlight, and it's already been done by many other libraries (that are mostly written in JavaScript!).
   

2. I get the ability to effortlessly unit-test the browser integration code.

#2 would be a great feature – (and by unit test I mean tools that are easy to run and integrate with a build engine like NUnit and MbUnit, and not tools that require a browser and some amount of integration pain, like Selenium or JsUnit). The former tools are still important as Silverlight does not yet offer an automation API so the runtime testability story is still weak. For unit-testing I know Jamie has already written a "Test With Silverlight" option to TD.NET, but its still only adhoc testing as I can see. If Microsoft makes it easy to host the runtime outside the brower, and provides some built-in fakes for the DOM objects, we could be off to the races.