Can I Replace My JavaScript Code With a Silverlight App?

Monday, November 26, 2007
Silverlight

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#:

HtmlDocument document = HtmlPage.Document;
HtmlElement select = document.GetElementByID("mySelect");

for (int i = 0; i < 10; i++)
{
    
HtmlElement option = document.CreateElement("option");
    option.SetAttribute(
"value", "foo" + i.ToString());
    option.SetAttribute(
"innerHTML", "foo" + i.ToString());
    select.AppendChild(option);
}

... 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 = "http://www.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.


Comments
Dave Tuesday, November 27, 2007
I agree! JavaScript's ability to run everywhere will definitely keep it from going out of style anytime soon. But if Silverlight ever gets to that point, I probably won't mind switching over simply from a support tools aspect. Although I don't see that happening anytime soon either.
Rick Strahl Thursday, November 29, 2007
I've been thinking about this for some time myself. I don't like JavaScript, but after having worked on a few apps recently that required a lot of client scripting in library code I've come to appreciate it a lot more and find myself quite productive with it. Won't argue with the point though that getting there is a long and painful road.

I think there's potential value in using SilverLight to do DOM programming, but in order for that to happen you need to build ontop of what's there today with HtmlElement. You can certainly build a library that has specific elements (like divElement, inputElement, textBox, etc.) that can handle more complex tasks, but it's something that has to be built first. The big advantage you'd gain from library in this is better debuggability and better typing/Intellisense support for most functionality. The big downside is that a lot of this code would end up in Reflection code in the 'framework'...

Worth it? Probably not unless penetration of Silverlight goes truly EVERYWHERE...
zproxy Saturday, December 1, 2007
Or you can let a compiler to translate c# to javascript.

Visit http://jsc.sf.net
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!