JavaScript會是Web開發(fā)的未來嗎？
1
事情要從JavaScript說起，這個曾經(jīng)的屌絲經(jīng)過多年的奮戰(zhàn)，成功逆襲，成為前端之王。
這奮斗的路上，Applet, Flash, Sliverlight 等無數(shù)火熱的技術(shù)成為冤魂。
Java經(jīng)常扼腕嘆息：“真是可惜了我的Applet，要不然前后端編程都用Java，程序員就不用那么辛苦了。”
JavaScript對這種說法嗤之以鼻：“技術(shù)被廠商鎖定，內(nèi)容無法被搜索引擎搜索，程序員用你才叫見鬼。”
話雖這么說，JavaScript對自己的認識也很深刻， 優(yōu)勢就是看起來簡單，寫點兒簡單程序就很容易上手，可是一旦深入開發(fā)， 兩大硬傷就暴露出來。
一個是語法設(shè)計，詭異的作用域，混亂的類型轉(zhuǎn)換， 蹩腳的‘面向?qū)ο?rsquo;，引起了很多語言的鄙視。還有一個是性能，在瀏覽器端的解釋執(zhí)行，能快到哪里去?
2
針對第一個問題，JavaScript想了很多辦法，不斷地改進，不過新版本得考慮向后兼容，兼容之前那混亂的設(shè)計，這不能不說是一個巨大的包袱。
人類想到，既然這么難改，能不能開辟一條新路，把它當成一種“低級”語言呢?
JavaScript雖然不情愿，但還是有人這么干了， 微軟搞了一個TypeScript，Jeremy Ashkenas發(fā)明了CoffeeScript，它們或者支持靜態(tài)類型，或者語法更加優(yōu)雅漂亮， 運行的時候，把它們轉(zhuǎn)化成JavaScript就OK了，啥都不耽誤。
JavaScript發(fā)現(xiàn)自己成為了瀏覽器中的“匯編語言”!
可是JavaScript作為前端之王，積累了海量的類庫和工具鏈，想用新語言去完全重寫是很難的， 程序員的慣性也很大，沒有強烈的理由，沒人愿意學習新的語言，JavaScript湊合著也能用，ECMAScript 不是在不斷發(fā)展嗎?
更重要的是， **Script，最終還是要以JavaScript來運行，速度還是上不去。
3
Node.js的橫空出世，幫助JavaScript入侵了后端開發(fā)的領(lǐng)地，讓Java十分頭疼，不是說JavaScript性能不行嗎?!
秘密在于Google的V8 引擎，其中有一項JIT技術(shù)，可以在運行時把一些熱點JS代碼翻譯成本地的機器碼來執(zhí)行，性能可不就蹭蹭上去了?
可是這種技術(shù)也不是萬能的，由于JavaScript的動態(tài)性，即使是強如V8引擎也會遇到麻煩。
人們經(jīng)常會舉這么一個例子：
- function add(x,y){
- return x + y;
- }
如果用add(1,2) 來調(diào)用， V8的JIT知道這個參數(shù)是int類型，會把這個函數(shù)編譯成本地的代碼， 參數(shù)是int型的。
由于變成了機器碼，執(zhí)行起來飛快。
然后人們又用 add("hello","world")來調(diào)用， V8發(fā)現(xiàn)，之前編譯好的int類型的本地代碼就無法使用了，還得重新編譯成字符串參數(shù)的， 這速度一下子就降下來了。
JavaScript有點納悶：這性能真的那么重要嗎? 我現(xiàn)在的速度應(yīng)對前端編程不是綽綽有余?大不了我不往服務(wù)器端發(fā)展就是了!
人類的欲望是無止境的，在瀏覽器中不僅僅要做簡單的計算，他們還想用大型設(shè)計軟件，用虛擬現(xiàn)實，玩游戲...... 這計算量JS是應(yīng)付不過來的。
4
JavaScript性能的壓榨已經(jīng)到了極致，路已經(jīng)走到了盡頭。
前面是一座高山，想要翻過去必須發(fā)明發(fā)明新的工具。
微軟，Google, Apple這些大佬他們舉行了一次多方會談，各方就關(guān)注的問題深入地交換了意見，對各方多年來的努力表示欣賞和贊許。
大家一致表示：早就看JavaScript這小子不順眼了，一定想辦法把它“干掉”。為了取得最大的共識，會談并沒有定義一套新的運行在瀏覽器中的高級語言，相反，大佬們定義了一套Web時代的匯編語言。
其他語言，不管你是C++, C, Rust, Java, 只要能編譯成這個Web匯編，都可以在瀏覽器中執(zhí)行。
(注：Web匯編其實就是 WebAssembly這門技術(shù))
這個Web匯編的思路很有意思，它本質(zhì)上是一套需要虛擬機來執(zhí)行的字節(jié)碼，當然是靜態(tài)類型的。
例如：這個求階乘的函數(shù)，經(jīng)過編譯以后，字節(jié)碼會是這樣：
(點擊看大圖，來源：https://www.slideshare.net/jayphelps/webassembly-demystified)
Java 一看到這個方案，立刻哭暈在廁所!這和自己的Java字節(jié)碼多像啊!
看看這i32.sub, i32.mul ，一個做減法，一個做乘法，但是沒有操作數(shù)跟在后邊，操作數(shù)肯定保存在棧上， 所以這肯定是一套基于棧的虛擬機!
早知如此，何必當初，用我的Java ByteCode, 用我的JVM， 用我的Applet多好!
繞了一圈，又回到了原點 ! 這IT大佬的政治斗爭真TNND坑死人啊。
JavaScript看到這個方案也是吃了一驚，后端的老家伙們亡我之心不死，釜底抽薪，想對我實施一次珍珠港偷襲!
要不我也編譯成這"Web匯編"，和他們平起平坐，同臺競技?但是我是動態(tài)語言，類型需要在運行時確定，沒法事先編譯啊。
不過，用C/C++這種“低級”語言寫前端代碼，操作DOM, CSS，還不是又臭又長，這不是搞笑嗎?!
確實是這樣，這Web匯編并不能干掉JavaScript，語言之間需要協(xié)作。
Web匯編主要解決性能問題， C/C++可以寫出高性能的“Web匯編”，來實現(xiàn)圖片/視頻編輯， 游戲，流媒體，虛擬現(xiàn)實，CAD軟件，可視化，仿真等代碼庫，然后讓JavaScript調(diào)用就行了， 各取所需。
JavaScript還是前端之王，不可替代。
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號coderising獲取授權(quán)】
