, PopeDai wrote

Silverlight may be open, but it's "open" the same way that Win32 or PDF are open: the specification is still controlled by a single corporate entity, it isn't truly open the way HTML and the web is. Even if Microsoft gave ECMA even the trademark rights to Silverlight the future direction of the platform will be dictated by Microsoft and not the community as a whole.

The exact same thing is true with HTML.

Firstly, the community doesn't decide what goes into HTML - the HTML standards body does. And Microsoft is part of that body. So if I'm Netflix, my opinions still don't hold as much weight as to the future of HTML as Microsoft's.

Secondly, if Microsoft were to control the language and the specification - that doesn't mean that they do so in a vacuum. C# has clearly shown that Microsoft is able and capable of making a mature, popular language that is backwards compatible, unambiguous, openly discussed, community driven, focused and unfragmented with a clear vision for devleopers who make use of the platform across a number of different implementations such as Mono and the .NET framework.

In contrast, HTML5 has failed on each and every one of those grounds. It's decision making process was partisan, politically driven, remains ambiguous, is not normative, and as you yourself admit, websites work differently in Webkit to Trident to Firefox to whatever.

By "accessible" I mean the same content works on a finger-input smartphone with a tiny screen, to a mouse-driven 30" 2560x1440 behemoth desktop. DPI-independent scaling is only part of the solution, a Silverlight application is still going to have tiny checkboxes, fixed-size textboxes, and scrollbars and the runtime is not in a position to re-flow or reformat a document for a different device the way it can for HTML/CSS. This is why the web wasn't built on PDF or HyperStack, even though both support hypertext. (of course, HTML is inherently accessible, but I won't argue this point because you can easily make inaccessible websites).

HTML websites don't scale from a finger-input smartphone with a tiny screen to a mouse-drive 30" 2560x1440 behemoth desktop without being carefully designed and scripted to do so. Silverlight applications give you DPI scaling for free, but if you want, your application can rescale or relayout depending on resolution, number of input fields or whatever.

Silverlight applications absolutely could (and did) reflow content depending on the size of the container, so I won't even give you that. The comparison to PDF is completely void, since Silverlight wasn't (and wasn't trying to be) a document description language. It was trying to be an application.

In fact - in that regard, HTML is much closer to PDF. It was designed to be a document description language (like PDF), and was never designed to be an application description language (like Silverlight).

And finally - Silverlight was multitouch in 2010, a couple of months before Firefox became multitouch.

As for video: the other sites are pragmatists: not everyone has a HTML5-video capable browser, and only WebKit browsers are really capable of live streaming of adaptive video (which you can actually do without any third-party components or plugins, but only WebKit can do it right now).

 

If only Webkit can do it, how can we be claiming to be talking about the open web? The fact that WebKit runs your application differently to other browsers is part of the problem

The functionality and style of my application on the desktop and in Silverlight is limited only by my imagination and my ability to code. In HTML it is constantly hampered by the inability of browsers to decide which features of HTML5 they would like to implement today. Does your browser have a JSON.parse? What does alert("") do? Is margin part of the width of a property? Make me a div that is 100% of the size of the container, minus 100 pixels without using javascript or tables.

In Silverlight, if it works on my machine, it works on all machines. Because Silverlight is unambiguous. If it hadn't come with adaptive streaming out of the box, you could just implement it if you're smart enough.

In HTML they've wasted time introducing tags that have no meaning (<output>, <section>), adding tags that we're not interested in (<progress>) and failing to implement tags we need (<video> with DRM, templating, a binary encoded javascript for efficient transfer and JITting optimised to be spat out of the backend of a compiler, better exception handling / reporting, the ability to disable grammar ambiguities for broken HTML etc).

I think that eventually, 3-5 years from now, Flash for Video will be dead when HTML5 <video> DRM support takes off.

Silverlight had DRM video in 2008. If HTML5 has DRM video natively in 3-5 years, that puts it a full decade behind Silverlight in terms of a basic and non-negotiable feature from several of the most popular and most important sites on the Internet.

.

I'll add that another barrier to Silverlight's web dominance is tooling: Silverlight files are essentially binary, you need special tools to make something. You cannot quickly make something like a "hello world" with simple tools like only a text editor in under 30 seconds. Instead you really need Blend or Visual Studio or one of Mono's tools - this is hardly something your 12 yearold tinkerer can experiment with (this is also why I think F12 tools should be more prominent in every web browser).

See - I think the exact opposite. Silverlight's biggest feature was it's tooling. Sure, you can't write a Silverlight application in notepad, but who in their right mind thinks that notepad is a serious development tool?

Silverlight is a powerful application for serious coders, and as such it had the full support of the enormously powerful Visual Studio - and for those that didn't want to pay, Visual Studio Express was free.

By having powerful tools, Silverlight application developers got intellisense, strong typing support, integrated help, one-key testing, a hugely powerful integrated debugger, compile-time optimisations of their code, the full power of static analysis, and syntax highlighting.

Sure, it's not notepad. But we don't write C++ in notepad, and that hasn't stopped it being the biggest, most popular, and most powerful native programming language in use by application designers on the desktop. Why should we expect web-application developers to make do with a basic text-editor with no features to churn out quality websites?

Similar arguments to the ones you're making could be applied to Java <applets> from the late-1990s, and look what happened to Java in the end.

No. Nobody ever said Java was good. Unlike Silverlight, the GUI was inconsistent across OSes and browsers, it was slow to load, and wasn't built to be secure from the ground up. It died a death because Flash killed it. Flash wasn't great, but it solved lots of the problems that Java did. And Silverlight would very likely have killed Flash if Microsoft had played their cards more sensibly.

(I also find it a bit ironic that myself, as an MS FTE is opposed to Silverlight, and you're the outside who thinks it's the best thing ever)

Maybe. I just find it disappointing that I spend so much time going to conferences, speaking with clever people and securing applications knowing that so many of the problems with the web are problems we solved five years ago, and killed six months ago.

It's yet another great example of Microsoft making an awesome product, and then getting confused with the strategy of what to do with it, failing to market it properly, and then killing it prematurely.

Microsoft executives need to get a grip. Microsoft is not short of clever employees or great products. But they really suck at making good use of them.

Silverlight wasn't perfect, but it fixed lots of the problems on the web and it turned it from an amateur-hour bunch of crappy scripts into a hosting platform for powerful, serious applications previously only found on the desktop.