, PopeDai wrote

On the contrary, it is Silverlight that sucks:.the web is meant to be an open platform, accessible to all, regardless of device, platform or browser. Plugins are dead. XSS is a server-side issue, not an issue with HTML itself. HTML5 <video> works fine for streaming: YouTube uses it, as does Apple, to great effect. I'm personally opposed to DRM, especially on video (because cryptographically DRM doesn't work because Bob and Charles are the same person), but HTML5's working group is looking to make HTML5 support DRM video without actually providing it. And object orientation has what to do with HTML exactly?

This is the true straw-man argument. Let me take it apart bit by bit.

1. Silverlight and "openness" / "standards" are not opposites.

All of the APIs for Silverlight were public, and Moonlight (Mono's implementation of Silverlight) was a clear demonstration that the core framework of Silverlight could - and was - implemented in an open "standards" way.

Indeed - Silverlight benefits from the same key feature that .NET does -- it is unambiguous, meaning that when presented with a Silverlight "document" a browser will present an exact representation of what the developer wanted. There's no quirks mode, there's no ambiguities in the grammar and there's transparent backwards compatibility, and this leads to a better web, because it means that instead of every developer needing to test their application against every browser (which is hard), and browser vendors needing to test their browser against every website (which is even harder) - the browser vendors only need to test that they correctly implement the Silverlight API.

For website developers - it's even easier. If it works on my machine - it'll work on yours - a benefit not shared before or since on the Internet cutting days off development and testing of new web applications.

2. Silverlight is actually more accessible than HTML

A common misconception about Silverlight versus HTML is that HTML is somehow "accessible" in a way that Silverlight isn't. This is simply not true. In fact, unlike HTML, Silverlight exposes all of the accessibility options that are available in Windows in a way that allows scriptable and extensible accessibility for partially sighted end-users.

For most applications (since most applications never supported accessibility), Silverlight just used sensible defaults - which actually are exactly the same as in HTML. That's why you could tab your way through different controls on the form, and why Silverlight apps could be "read" by screen readers.

In fact, Silverlight being XAML based meant that the entire website was transparently zoomable without breaking all of the elements and padding as you zoom. You didn't need a different website for customers on 800x600 versus 1024x768. You just scale the whole website, and Silverlight managed the scaling.

3. XSS is a document issue - not a server side issue

It is a lie to suggest that XSS is somehow a "server side" issue. XSS is a document generation issue. XSS occurs anywhere where documents are generated from text.

My view is that XSS and SQL injection are design flaws in the language itself. C++ doesn't have C++ injection vulnerabilities. It's been a while since I saw a C# code injection vulnerability. It's rare to see someone screw up with MongoDB. So why are XSS and SQLi everywhere on the Internet?

The answer is because they are so often dynamically generated from strings, instead of requiring templating with parameters (indeed, this is how you solve SQLi in the general case).

Silverlight solved XSS in the same way that parameterized SQL fixed SQL injections. It said the document is a prepared object, and you fill in the gaps with elements - you never generate your Silverlight on the server by gluing attacker controled strings together.

In HTML, your document is whatever HTML is spat out the end of your PHP or ASP console program living on the server. If you forget to escape your input, *boom* - XSS.

In Silverlight, attacker controlled data never stopped being data. You took the data, and you put it in the data slot (like .Text) of an element. You never needed to escape it. You never needed to think about it - because gluing attacker controlled strings together, dumping them directly into your application and having them execute as code in the context of your application was never an option.

4. HTML5 video sucks fine for streaming video compared with Silverlight

Unless you need DRM. Or adaptive streaming. Or live streaming. So BBC iPlayer and Netflix and Lovefilm and Hulu-plus and ESPN and, let's face it, pretty much everyone who use video on the web except YouTube are automatically excluded from HTML5 web.

So how does Netflix use to stream your high-quality, adaptive-streaming DRMed video direct to your browser?

Silverlight.

How do you stream the Superbowl to tens of millions of browsers live with adaptive streaming?

Silverlight.

You might object to DRM on principle (sure, whatever, loads of people do), but that doesn't stop the fact that if you want to stream movies legally, you have to put up with DRM. It's not optional. Disney would rather nobody stream their latest and greatest movie than allow it to stream sans-DRM.

To that end, I put forward the (admittedly controversial) opinion that I frankly don't care about DRM, but I do rather care about being able to stream from Netflix and Hulu Plus. And if HTML5 doesn't support Hulu Plus and Netflix - then it's doing something wrong.

5. What has HTML got to do with object orientation?

Nothing, sadly. But the answer should be everything.

Programming is advanced when we can move beyond the bottom rung of the stack and abstract our way out of the swamp. I don't want to deal with divs and spans, thank you very much, I'd like to deal with docking panels and code-editor controls and rate-adaptive video streaming boxes.

HTML encourages bad applications, because it discourages code-reuse.

 

 

This is the story of how Silverlight fixed the web, and Sinofsky killed it.

Silverlight was a shining gem - a architectural palace from which serious coders could write code that stood above the rest of the web.

It was a place where streaming media was powerful, encrypted and adaptive. A place where graphics were smooth and hardware accelerated by default. Where shifts between pages were transitions, not "page loading" pauses - and where security came without thinking, rather than requiring repeated and expensive pentests to get right.

It was a place where people coded components that could be used on lots of sites. Where element widths were pixel perfect, and the same on all browsers, and where code was debuggable to developers - even if the crash occurred on a client machine - without revealing the source code to all and sundry on the Internet who might want a peek at your company's IPR.

Sinofsky bulldozed that palace. so we're back to where we were. Every page starts at the bottom - a pile of divs and spans spat out by a PHP or ASP.Net console program, trying desperately to reach it's head out of the mire of browser incompatibility long enough for the user to not notice the glaring security omissions and cobbled together unzoomable sh1ttiness that is the web today.

If HTML5 does well, it might one day be a shadow of what Silverlight was three years ago.

In the meantime, I hope they put Sinofsky's badge on a spike, as a reminder to others who commit crimes against common sense.