开微软的时候我巴巴地主动把手里写的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自己。
开微软的时候我巴巴地主动把手里写的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自己。
