從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?