Hacker News new | ask | show | jobs
by TweedHeads 6231 days ago
Canvas and SVG would kill silverlight instantly and that's why M$ will never implement any of them.

As simple as that.

2 comments

Silverlight's killer feature is adaptive video streaming. The current HTML 5 draft states:

" It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies. This is an ongoing issue and this section will be updated once more information is available. "

Netflix, MLB, NBC (Olympics), etc choose Silverlight to enable high quality video streaming while simultaneously supporting lower end connections without requiring manual quality selection. As far as I know, Flash can't do that and I don't expect the HTML 5 video element to be able to do it cross-browser and platform.

Canvas and SVG are nice, but they are hardly enough to kill either of the popular rich internet application browser plugins. Add in video and ignore a large pile of existing skill sets; you might have a case against Flash.

Silverlight isn't doing so great because, in true Microsoft fashion, there is too much complexity. XAML/WPF is a classic inheritance vs composition design disaster and the learning curve is simply outside of the scope of the average developer. Blend, however, is an amazing tool and may be able breath some life into the ecosystem. Silverlight will be the death of Silverlight, not Canvas or SVG.

I really don't see how XAML is that much more complex than SVG, but I'm not really an expert.
The basics of both are quite simple and very similar. Once you get into animation, events, etc, things start getting hairy fast.

XAML was developed for WPF, but in reality, it is completely WPF-agnostic. It is a serialization format for declaratively constructing .NET object trees. It also supports several domain specific languages for various shorthands, such as data binding expressions. This is not unlike the style DSL in SVG, but these DSLs instantly break toolability unless you manually handle each one.

However, at the developer level, data binding (aka templating) is where the real complexity explosion is.

You know how there are dozens and dozens of various HTML template engines out there? It's something that initially seems simple, but everyone has a different opinion of how it works. The XML-based templating solutions, such as XSLT, are often considered verbose and cumbersome. Well, all those templating solutions are only tackling a static, one-way transformation!

XAML's data binding is an DSL-ish XML-based template language which supports two-way transformations, animation, event handling, runtime modification, and lots, lots more. It also deeply confuses the structure, and style of the documents in a way that a few extra divs or spans for the sake of your CSS doesn't even come close to.

I Disagree. I just got back from the Microsoft offices at Boston, and my personal hunch is that Silverlight is being primed for slick one-web device integration. While that may be possible to achieve with numerous languages, the people who seem to be really leading the way are in fact Microsoft:which makes me wonder: was the idea of having "a computer in every home" more a vision of the computer on the Star Ship Enterprise than the idea that everyone would have their own terminal? Judging by Bill Gate's abode, I would think the latter.

I'm not ruling out the possibility of Flash and Silverlight dying to HTML5, I'm just saying that it is unlikely to happen in the near future (even in HTML5) a) because of the people behind them and modern projects they are rolling out and b) because it takes a long time to change from one standard to another unless there is some kind of unforeseen tear in the fabric of hyper-space.

When all is said and done, it always seems come to down to the preference of the developer, which will always remain a diversity.