那个我们爱的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自己。

 

 

posted @ 2010-10-31 23:43  winter-cn  阅读(...)  评论(... 编辑 收藏