2019年4月12号补充:
回头看这篇写于七年前的文章 , 觉得挺感慨的.
一方面, 我觉得我当时的整体判断没有什么大的问题, 另一方面, 当时这篇文章中有些地方写得比较模糊, 对于边界界定得不清楚, 所以还是有一些误导.
首先, 关于浏览器与插件, 我当时认为在至少十年内, 看不到浏览器能完全取代插件的迹象. 如今七年过去了, 我觉得基本上跟我预感得差不多, 现在关于视频, 游戏, 支付等比较复杂的场合, 仍然是以插件来实现, 大方向没有问题.
第二, 我认为当时win8的metro是死路一条, win7的桌面模式才是王道, 现在win10的设计已经基本上证明了这一点.
第三, 我没有想到的是, .net 竟然会这么快地走向没落. 这不仅是SL的失败, 而是整个.net的失败. 由于.net的逐渐萎缩, 导致SL与Flash相比, 根本没有一点点竞争力了. SL曾经试图作为Flash的挑战者, 而它很快就死得透透的, 浏览器插件仍然是Flash一家的舞台.
我整篇文章的脉络逻辑是这样的:
1) H5+JS无法取代插件. 插件在可见的很长时间里都将存在.
2) 在PC端, 是不会像手机端那样快速淘汰插件的. Win8 metro那种是瞎搞, PC端就得有PC端的样子.
3) 主要的浏览器插件是Flash, 但是在微软的技术生态中, 受制于这个生态圈, 做插件应该是用SL, 而不是换种技术用Flash.
(如果要用flash, 应该全盘放弃微软的技术, 选择别的技术生态)
我在原文中有这样的描述:
"Flash是非常优秀而强大的web插件, 但是在微软的生态圈中, 它却并不理想, 所以用Flash代替SilverLight, 实际上很不现实, 要么全盘放弃微软的技术, 要么就只有SilverLight."
"因此, 对于生活在微软天空下的web开发人员来说, 选择SilverLight可以更加快速, 更加优雅地实现更加强大的功能, 为何不选择SilverLight"
作为曾经的微软生态圈从业者, 我觉得在当时的背景下, 这个判断没有什么问题.
当然, 事实上没多久我就离开了微软生态, 加入了Java生态, 并且在插件的选择上, 也只剩flash一个选择.
单纯就结论来说, 选择SL之所以是个错误, 是因为选择了微软生态圈. 如果没有在微软生态圈, 插件肯定是选flash.
关于JS:
JS的缺点在当时是非常显然的, 这个没什么好讨论的.
但是后来前端出现了React, AngularJS这样的框架, 并且在这种框架基础上长出了很多很多的附属框架之后, JS的缺陷很大程度上已经解决了.
但是我必须强调, 在没有这样的MVC框架之前, 用JS去构建一个复杂的大型项目是不对的. 我当初的观点要结合当时的背景来看, 并没有问题.
不过我还是要修正一个观点: 我当初说我认为浏览器不太可能把JS解释得像flash一样快和安全, 我现在改变了这个观点. 我现在开始觉得, 浏览器是能够做到把js解释得飞快的, 未来有一天用js来做复杂的大型网页游戏是可能的, 我不知道这一天需要多久, 但是的确存在flash这样的插件彻底退出历史舞台的可能性. 尽管在今天看来, 这一天仍然是遥遥无期.
以下是写于2012年的原文:
----------------------------------
从2010年底开始, 就已经有很多关于SilverLight即将死去的声音传出, 随后越来越多的事实表明, 微软确实在逐渐放弃SilverLight, 其根本原因大约在于感受到了HTML5的压力, 而直接的原因是在于与Flash的竞争中没有取得多少胜利.
因为iPhone的流行, 乔布斯信心满满地宣布所有的浏览器插件都是”邪恶”的, 所以iOS的浏览器拒绝任何插件, 包括Flash, 当然, 肯定更包括SilverLight, 然后, 当win8中的metro-ie真的像乔布斯所设计的一样, 不支持任何插件时, 我还是不敢相信地眼镜碎了一地. 微软怎么变得这么没有信心和主见了?
1. HTML5为什么不能取代SilverLight(或Flash)
任何一项产品都是一个工具,我不是SilverLight的设计者,对它没有任何特殊的感情,如果有一项更好的技术可以代替它,那很好,我会第一个站出来支持新产品,可是问题是,HTML5真的能代替SilverLight吗?
SilverLight是用C#(或vb.net)语言开发的胖客户端,这种血统先天地决定了它的开发过程,程序结构必然和windows应用程序如出一辙,事实上更进一步,SilverLight从WPF继承来的血统使得MVVM工作得非常理想,这一整套的产品构成了以.net framework为基础,以MVVM为组织模式,以高级语言为开发语言的强大生态链,SilverLight统一了客户端与服务器端的开发技术, 填平了不同浏览器之间的沟壑.
还不止如此. 在SOA工作模型中, SilverLight尤其有用. 它与WCF的深度整合使得开发一个强大的,面向服务的web程序变得简单而优雅.
反观HTML5呢?它增强了图形处理能力,并且增加了流媒体处理功能,此外还增加了其它一些实用的功能. 然而, 这对于RIA来说, 还是差得太远了. 对于软件工程, 性能, 以及开发效率来说, 更是一无是处.
首先从语言以及结构来说, 高级语言,强类型,面向对象的优点,无需任何多余的解释,几十年来的软件历史已经是铁的证据, 而优秀的设计模式对软件的可读性,可维护性,安全性和弹性来说,更是至关重要. 关于此,基本上也不需要多余的”证明”,每一个学过编程的人都应该知道设计模式的意义和作用.
HTML5并不是”HTML自己”,事实上还有一个几乎被人们刻意忽略的主角名字叫做JavaScript, 在所有大谈HTML5的美妙前景和跨平台特性的地方, 几乎看不见有任何一个人提起javaScript的名字, 然而事实上HTML中的各种动态功能和行为要全靠js来实现, html5作为web应用解决方案, 事实上应该叫做”HTML5 and JavaScript” 解决方案.
事实上如果进一步仔细想一想, 会发现一直被人们刻意藏在幕后的JavaScript才是真正的第一主角, HTML5, 实际上只是配角而已.
不算太久以前, 微软展示了一个号称用HTML5实现的游戏”切绳子”, 该游戏确实很令人吃惊, 然而任何一个做web开发的人都应该立即认识到, 这个游戏的实现中, HTML5占了多少比重, javaScript占了多少比重? 其所有功能性的代码是用哪种语言完成的? 答案是如此简单明了, 与其说这个游戏是用于展示html5的, 我觉得不如说是展示javascript的.
谈到游戏, 大家应该对近几年来国内相当火爆的网页版网游不会陌生, 那种强大的功能完全依靠js来实现? 想想就头皮发麻. 姑且不论到底有没有可能做到, 就算真的能做到, 难道大家真的不觉得这是编程的历史大倒退吗? ----经过了这么多年的发展, 高级语言反而被脚本语言所取代?
事实上, 游戏只是一个例子. 随便web应用的越来越深入人心, 人们需要更加强大, 更加细腻, 更加高性能和更加复杂的客户端应用, 这些都意味着更大的编程规模, 对”html5 解决方案”来说, 事实上这意味着用户所有的期望都要通过javascript来实现, 而对大型应用来说, 这也许意味着数百万行的代码量. ---- 在这种规模的编程中, js与强大的C#有可比性吗?
事情还不止这样.
像我公司的项目来说, web application着眼于局域网, 并不考虑因特网的限制, ----这其实也是很多web应用的使用场景, 在局域网中, 像SilverLight这样的客户端插件可以实现非常高性能的通讯(二进制数据流)和数据处理, 这是基于纯文本解释的html5血统上的障碍, 它的性能永远不可能比插件更高.
除通讯性能以外, 还有动态效果性能. SilverLight可以直接使用硬件加速, 而HTML5则由于其依赖于浏览器, 所以与通讯性能一样, 只会比SilverLight低, 而绝无更高的可能.
还有开发效率(时间成本)呢? 基于.Net的SilverLight可以完全借助Visual studio的强大功能, 开发人员很多时候根本感觉不到这跟开发一个windows程序到底有什么区别, .net framework封装了海量的现成功能, 丰富的控件, 熟悉的编程体验, 以及强大的调试支持.
js的开发我们也很熟悉了, 虽然vs这些年来不断加强对js的支持, 但是与庞大的.net framework相比, 与成熟的.net 运行时和调试器相比, 它还只是个脚本语言而已, 再肥的老鼠也不会比大象更重, 这是基本常识.
2. HTML5到底在哪里
抛开以上这些现实的问题都不论, HTML5到底在哪里?
首先, HTML需要浏览器的支持. HTML5本身只是一个标准, 它的实现依赖于浏览器. 而因为各种各样的原因, 每款浏览器总会有一些自己的”个性”. HTML4并非没有标准, 然而眼前的事实已经充分说明了浏览器的厂商会怎样对待这份标准, 没有任何理由能够证明HTML5的时代就能完全解决这一问题.
其次, 现在已经使用了支持HTML5浏览器的, 仍然只是少数. 要淘汰所有旧浏览器, 仍是遥遥无期. 并且可以预见的, 无论是五年后, 还是十年后, 市面上一定充斥着各种各样版本的浏览器, 并且每款浏览器多多少少总会有些差异. 别的且不论, 微软的IE9才推出多久? 就已经出了IE10, 而IE10跟IE9 虽然都是支持HTML5的浏览器, 但是就有不少的能看得见的差别. 现在还活着的浏览器中, 光是微软一家, 就从ie6直到ie10整整5个不同的产品.
第三,构建强大的web应用不仅需要基础技术成熟, 还需要大量的类库, 而HTML5本身还不够成熟, 基于HTML5(JS)构建复杂的web应用更是缺乏足够的说服力和类库支持. 如果, 未来的浏览器真的可以将js解释得像silverLight或flash那样, 那也是一个非常漫长的过程, 何况我个人认为那是不可能的.
相对于HTML5的不成熟, SilverLight却是一个摆在眼前的成品, 为十年二十年之后的事情担心, 那是吃饱了撑得没事干.
3. Win8以及未来
好吧, 我承认, 为十年二十年后的事情担心, 并不一定是吃饱了撑得没事干. 那我们就来看看未来.
win8实际相当于win7+metro, 也就是说, 抛开向下兼容win7的桌面模式, metro模式才是真正的win8.
然而metro到底是什么东西? metro模式抛弃了窗口, 抛弃了WPF, 甚至抛弃了.net, 用这么大的代价, 实际上是就是翻版了手机操作系统, 不仅在外观上毫无新意, windows应用商店更是直白地表达了对苹果的爱慕之意, 再考虑到metro-ie变态的设计… 我一度怀疑win8是否在乔布斯的指导下开发的.
虽然metro模式看起来确实让人有点耳目一新的感觉, 但是个人电脑也并不是一台游戏机, 更多的人要用电脑去办公, 或者做一些类似于办公的事情, 用得越多, 就越发现没有窗口的metro模式是多么地令人蛋疼, 人们需要同时使用两个及以上应用程序的场景实在是太普遍了, 而且由于显示器的尺寸不断加大, 显示器实际上每年都在具备显示更多信息的能力, 可是metro却告诉用户: 不, 你全部的屏幕只能用来显示一个应用. 你想一边聊qq, 一边看电影? 亲, 那是不允许的……
电脑不是手机, 这么简单的道理, win8的设计师就没搞明白. win8的metro不能说绝无用处, 但确实用处极为有限.
所以, 未来的windows发展方向, 绝对不会是呆板的metro, 而只能是经典的窗口模式.
弄明白了这一点, 就可以相信, 未来的ie不会禁用插件, 即使metro在win9中仍然像个畸形的怪胎一样寄生在操作系统中, 它也掀不起任何的风浪. 基于桌面的win7模式才是王道, 而只要浏览器不禁用插件, SilverLight或Flash的可用性就不用怀疑. 虽然也许微软不会再推出SilverLight6了, 那又如何? 至少十年内SilverLight仍然会工作得很好, 至于十年后的事情…事实上绝大部分的代码都活不了这么久.
4. 电脑技术的本质
中国有句老话叫做”数典忘祖”,对web应用来说, 我觉得现在的技术大佬们就正在数典忘祖, 他们一味地幻想着跨平台, 却忘了电脑技术是用来干什么的?
电脑是一种工具, 它的全部发展历史只是为了服务于用户, 一种技术只有为用户带来了更好的体验, 才是有价值的, 才能击败旧有的技术. 而把web的未来寄希望于低级的, 无类型的, 难控制的, 低性能的JavaScript( HTML基本上是用来呈现静态内容的, web应用着眼于动态而不是静态) , 是毫无道理的愚蠢想法. 当乔布斯骄傲地宣称所有插件都是”邪恶”的时, 我认可他的理念(“典”) 是有道理的, 但是在他数这个典的时候, 他忘了他的”祖”. (应用要服务于用户)
一项技术不能因为它能节省人力, 就打压用户的需求, 就必须无谓地消耗更多的用户计算机资源, 相反, 如果能够提升性能, 节省资源, 达到更好的效果, 提升用户的体验, 不管多费多少劲, 也必须去做.
实际上, 还有很多功能插件的功能是JS+HTML根本不可能实现的, 再加上JS+HTML的安全性极差, (网上购物的安全谁来保证?) 禁用插件根本不可能, 不只是眼前不可能, 十年后也一样不可能. 只要稍微想一想用户需要更强大, 更安全的web环境, 就知道插件只能限制, 而不可能禁绝. (有些乱七八糟的插件确实讨厌, 但是难道因为鱼有刺就禁止吃鱼? 因噎废食永远是愚蠢的)
Flash是非常优秀而强大的web插件, 但是在微软的生态圈中, 它却并不理想, 所以用Flash代替SilverLight, 实际上很不现实, 要么全盘放弃微软的技术, 要么就只有SilverLight.
实际上, 我个人觉得web的未来应该是基于多种客户端的SOA模式. 功能由Service实现, UI由不同的平台分别用最合适的技术来实现, 一味地追求跨平台毫无道理, 手机的屏幕决定了它的显示和操作模式一定是跟电脑有区别的.
5. XAML, 数组绑定以及MVVM
这个话题已经讲得有点烂了, 但是我仍然不得不提一提. Win8 metro app全新的开发方法, 事实上几乎可以称为SilverLight6, 它仍然使用XAML, 它像SilverLight一样使用类似于”受限的.net framework” 作为编程框架, 某些silverLight程序甚至可以一行不改, 直接编译成为win8 app.
我并不看好win8以及它的metrol app, 但是XAML以及MVVM我相信一定会长存下去, WPF不会死, SilverLight所使用技术就不会死.
从某种意义上, 即使真的SilverLight5是最后一个版本, 也可以认为SilverLight只是换了个名字, 它已经在新的技术中重生了.
6. 微软的态度
微软把SilverLight的开发停下了, 但是微软从未明确宣布SilverLight项目将被放弃. 这是一个很有意思的现象, 微软内部现在的规定是”不得提起”, 如果微软真的决心就此放弃, 何必弄一个”不得提起”来装鸵鸟?
我觉得微软也在观望. 他们在观望浏览器插件会不会真的没有前景, 如果未来证明包括flash在内的其它插件都慢慢死去, 那么微软也就顺理成章地放弃silverLight, 相反, 如果事实证明浏览器插件活得很滋润, 没有任何死去的迹象, 他们随时可以重启SilverLight项目, 推出SilverLight6.
所以, 我觉得即使不考虑SilverLight的转世重生, 就算SilverLight这个产品本身(以及这个名字), 也很有可能在未来复活.
因此, 对于生活在微软天空下的web开发人员来说, 选择SilverLight可以更加快速, 更加优雅地实现更加强大的功能, 为何不选择SilverLight?