那个我们爱的Silverlight

写这东西多少有点跟风的意思，不过最近的事还有大家的话多少让我回忆起一点对SL的旧感情。

 

离开微软的时候我巴巴地主动把手里写的SL控件（Menu/MenuItem）邮件给SL组的人，其实那时候都已经决定要走了，然后还给他们留了私人邮箱，说以后有问题还可以找我，虽然到现在也没看他们用上。所以说说实话我从内心深处是希望SL好的。

 

做为一个纯粹的技术人员，我看到的SL1.0是一个简单但是充满希望的产品，到了SL2我看到的就是一个曲意攀附.net的商业化妥协产物。

好吧，技术人员还是谈技术吧。不知道大家记不记得SL1.0里面的这个用法：

item["ItemControl.source"]=//...

意思是ItemControl为其中的item附加了一个属性，当然因为JS的特性，ItemControl.source必须写成字符串的形式。提起这个是为了说，其实SL当年的志向并非一个UI framework或者浏览器插件那么简单，它是想做一个类似CLI的运行时。

 

Silverlight运行时最初设计的基础就是Dependency Object和Dependency Property（简称DO和DP），估计接触过Silverlight的弟兄们多少对这两个东西的存在应该是存疑的，估计也很少有人愿意去理解它们背后存在的道理。

其实相比JS用属性字符串名去访问属性，DO/DP是一个更加高效的动态语言运行时实现，你可以根据属性名去查找属性值，也直接根据DP对象去查找一个属性值，这比属性名快速的多。这个体系允许你在任何对象上添加任何属性，这是比较接近动态语言特性的。——是的，这两个概念根本就不应该让程序员去知道和理解，这是语言运行时的实现方式。

 

到了光芒万丈的Silverlight2，这个清晰的技术发展路线被扭曲了，微软的老板们只关心一个结果：开发者可以用C#开发Silverlight。当然也这也是无数程序员愿意看到。但是从来不曾有人追究到底如何去实现这件事。

 

如果SL希望继续走它的"运行时"伟大梦想，它要做的事情就是在DO/DP体系上实现.net CLR，大家都知道在一个更加"动态"的运行时上实现一个更加不动态的运行时是可行的。另一条路，则是在CLR上实现DO/DP，这样做的直接后果是C#仍然跑在.net CLR上,但是必须用奇怪的语法去访问SL对象：

Control.getDependencyProperty(new DependencyProperty("width"))

但是我想是个人都知道前后两种方法哪个工作量更大。

而且那些奇怪的语法并非无法修补——只要你愿意为每个属性写一个getter/setter

 

看过SL源码的人一定都知道SL团队最终做了怎样的选择，对于只有几十个控件SL而言，写几个getter/setter不过是一个程序员几天的工作量而已。我不曾参加SL团队，所以我不知道什么内幕消息，但是结果大家有目共睹——SL团队最终选择了饮鸩止渴的做法。

 

于是SL团队当然地以极高的速度完成了引入C#支持的任务，这对SL团队而言，我想也是极其重要的Achievement。坏处？坏处就是，当初那个做"运行时"的构想终结于此，还有就是以后每一个控件的每一个属性，都必须有一个DependencyProperty和一组getter/setter，这还没完，微软还必须维护SL中的这个精简版CLR——事实上，此后很长一段时间里MVP和微软的人都在解释这个被阉割过的CLR跟.net CLR之间的关系。

 

SL在UI编程模式的设计和抽象方面做的过于优秀，即使如今的HTML5，我也觉得远远不及，UI模型不是靠一两个Sample就能说清楚的，HTML5再好，也不过是多了几个标签——说实话早该加了，只是W3C不够给力而已。

 

看到IE9声明支持HTML5大家一副心慌的样子我笑了，IE什么时候支持过Silverlight了？如果不是同样打着MS的标志，恐怕大家根本就看不出SL这东西其实跟IE是一个公司的吧？就算微软的IE不去支持HTML5,估计结果也是IE9团队解散或者一帮人没事混日子，绝不可能出现IE支持Silverlight这一出戏。

所以说，搞死Silverlight的绝对不可能是HTML5,只能是Silverlight自己。