Microsoft wrestles with HTML5 vs Silverlight futures | Hacker News Reader

Microsoft wrestles with HTML5 vs Silverlight futures

itwriting.com

13 pointsronnier25 comments

HTML 5 looks more and more like the Win32 API to me (or x86 assembly). At first everyone will use it directly. But people will quickly see that its a bear to be productive with it. Then you'll quickly see new frameworks built over it.

I wouldn't be surprised if Silverlight eventually simply targeted HTML 5. You wrote your code in Silverlight and out comes an HTML 5 page.

I'm not really sure what WPFs future is. It's great technology, but the desktop is increasingly niche.

> I wouldn't be surprised if Silverlight eventually simply targeted HTML 5.

No, that's not possible, as HTML5 is pretty incompatible with Silverlight's selling points.

Besides, the article is flamebait ... Silverlight will be the native API people are going to use for building native-clients on Windows desktops / Windows mobile phones. Add to that list portability Symbian, MeeGo and probably Android.

Silverlight also has a more efficient VM than Flash or the various mobile-browsers, so if they play this card right, it could actually be efficient when running on mobile phones ... windows mobile 7 is actually using Silverlight for its UI ... and from early reports, the interface is snappy.

Why is it not possible to target HTML5 from Silverlight? You may have to tweak Silverlight some, but it seems doable?

You map the styles to CSS. The Xaml to HTML (I'd love to have Silverlight layout in HTML). Although the Xaml also includes stuff that you need to map to Javascript as well. The C# code gets mapped to Javascript.

You'd have to map all of the things like databinding, DeepZoom, and animation specially crafted Javascript. Audio, video, WCF, may have to be scaled back for targeting HTML5. But then you can have two versions "Silverlight HTML5" and "FullPower Silverlight".

I'm sure there is tons I missed. But what do you think in particular can't be mapped from Silverlight to HTML?

Microsoft Live Labs is kind of doing this with Volta.

Volta is dead.

Maybe? Well I don't know politics, but they did some solid work that ended up with a paper. Since Volta was not a product but an experiment I would suggest it doesn't make it unlikely, that research could be used to create similar product in the future. It seems potentially like a good fit.

I never picked up development on Silverlight because the Linux client (Moonlight) is unusable, but its advantages are ... an efficient VM (dotNet's CLR) with real multithreading capable of running any .NET language on top, video DRM and adaptive streaming and ... this is important ... consistency between (supported) browsers and OSes.

I know normal people don't care about the first point ... but because the VM is efficient, it might just be that Silverlight is actually efficient on mobile phones (versus Flash) ... a Symbian version is already available, a MeeGo is in the works, if they add Android to that list + Windows mobile 7 ... then you've got a winner (if only they don't fuck up the implementation as Adobe did with Flash).

From Microsoft's point of view Silverlight also has another advantage ... they can add to it whatever they want. Few people complained when they added COM interoperability. They can't do that to web standards without bad publicity (though this didn't bother them in the past).

"I'm not really sure what WPFs future is. It's great technology, but the desktop is increasingly niche."

This scares me as someone who likes the idea of WPF, considering alternatives are javafx (not open either, but not being actively updated), and for, only recently adobe flex.

What do one use when they want to make a desktop app with decent ux that needs to talk to hardware? Go back to using java/swing? Native client (hah!)? Flex only started to support native processes a few months ago.

Ideally I'd love to see the ideas behind WPF open up a bit if support diminishes.

http://www.itwriting.com/blog/3131-more-on-microsofts-diffic...

Expanded analysis with explanations for those who don't know what this is about.

Properly written semantic HTML5 is a progressive enhancement from HTML4. With Silverlight (or Flash) the documents would just about have to be implemented twice, and few authors have the diligence to actually do that.

Pretty damning, but it's true that both WPF and its cousin Silverlight have failed to gain traction both on the web and on the desktop. WPF is dead, but Silverlight will be with us for at least a while thanks to WP7.

Well, since VS2010's interface is written in WPF, it'll have to stick around as long as that is true. Plus, Microsoft never kills a technology, they just don't improve it.

How are they gonna replace WPF with HTML5? I don't get it.

It mentions it in the article, extend HTML5 with a Windows API.

They did it before with HTML, was it HTAs? You could make controls that did crazy stuff. I can't remember the name now, my old work had a few from the days when there was no browser but IE.

At the end HTML wins. Flash and silverlight lose.

A victory we all celebrate.

No not really - I would be much happier if browsers used Silverlight (or rather the tech behind), since it is much better than the cooked together mess that is HTML. The only thing necessary would be an open-source renderer that worked equally well on all platforms.

But given that that is not going to happen, I am rooting for HTML5.

Silverlight is a neat technology but ultimately they limited it to just a box on a page, and in that realm it becomes just another flash substitute.

Or canvas substitute. SVG/VML is the technology that actually augments HTML documents. Canvas is just super-slow Flash/Silverlight-like pixel renderer, a “box on a page”, as you said.

There is a barrier between a Flash/Silverlight app and the remainder of the page, that's not true for the JS code driving a canvas element, it's the same code that drives all of the interactivity on the page. This makes a difference.

Why, you can interact with Flash/Silverlight embedded object as well. (A perfect example is using Flash to fake Websockets) And both support Javascript. There's really not much difference.

Yes, I concede, you are right. That's how everybody uses Flash and Silverlight, by driving it externally using javascript.

Are you being serious or just a troll? There are holes in the wall between Flash/Silverlight and web pages, but there is very much a wall.

Oh come on.

Silverlight let you do things like take a code fragment from HTML page, interpret it and let it execute commands against browser's DOM. (See: http://www.silverlight.net/learn/dynamic-languages/).

DojoX GFX (similar to Rapchaël) emulates even SVG drawing using Silverlight object.

And Flash let's you call any Javascript function from ActionScript and an ActionScript function from Javascript.

You must be dreaming up those walls. Or is it just FUD spreading?

This is why there's so terribly many flash/silverlight apps driven by external javascript? And why, on average, there's so very much cohesion between flash/silverlight objects and the pages they live with in?

In practice, the wall clearly exists. The average flash/silverlight app is an alien box sitting amidst its host page, with very few and generally comparatively minor exceptions.

You claim that less than expected (by you?) people use available technology in such and such way and thus that imply that there's something wrong with technology?

I would suggest there's really not so much use cases for Flash/Silverlight—HTML in-page communication. Or maybe some people just don't know their tools very much? None of these would be solved by creating another similar technology.

EDIT: Just look at the new HN top story for an example of JS-Flash interaction: http://feross.net/instant/ :)

They should be kidding. They understand nothing about web and open standards. That is why they loose.

Reply on news.ycombinator.com