2017值得一瞥的JavaScript相關技術趨勢

來自：某熊的全棧之路

2017值得一瞥的JavaScript相關技術趨勢從屬於筆者的Web 前端入門與工程實踐，推薦閱讀2016-我的前端之路:工具化與工程化獲得更多關於2016年前端總結。本文主要內容翻譯自，筆者對於每個條目進行了些許完善。

本文中提及的這些趨勢可能離大部分開發者還很遠，或者說離真正的大規模工程化應用還很遠，不過不妨礙我們提前兩三年了解下。本文僅代表原作者個人看法，不喜留言輕噴，譯者也很好奇大家對這個列表的看法。

跨年前兩天，Dan Abramov在Twitter上提了一個問題：

JS社區毫不猶豫的拋出了它們對於新技術的預期與期待，本文內容也是總結自Twitter的回復，按照流行度降序排列。有一個尚未確定的小點是既然函數式編程已不再是少數派，是否要把它踢出紅毯呢？

WebAssembly

去年筆者就表示過了對於WebAssembly的期待，WebAssembly就是面向Web平台的底層代碼。其初衷是希望能夠使所有語言都能夠編譯運行到Web平台，這一點對於很多函數式編程、響應式編程的粉絲充滿吸引力。特別是隨著這幾年JavaScript社區的突飛猛進，很多開發者並不能跟得上這門語言衍化的速度，因此他們也非常希望能夠直接用自己習慣的語言而不是要去重頭學一門從入門到直接放棄的語言。不過JavaScript目前還處於明顯的上升勢頭，暫時還沒人唱衰它。並且WebAssembly仍處於襁褓中，才進入到預覽階段，離真正的發布還有很長的距離。總結而言，筆者建議我們都應該對WebAssembly保持一定的關注，畢竟它會對未來的JavaScript造成極大的影響。如果你對於WebAssembly有興趣，那麼推薦閱讀Eric Elliott的相關博客。

Elm

筆者個人不太意願使用Elm，不過其特性還是很有借鑒價值

2016年不少的開發者參與到Elm的開發中，Elm不僅僅是JavaScript的擴展庫，而是一門可以編譯到JavaScript的編程語言，對於很多熱衷於函數式編程的開發者是個不錯的選擇。參考Elm 入門介紹，Elm提供了如下特性：

並不會存在運行時錯誤，沒有null，沒有undefined is not a funtion。

非常友好的錯誤提示信息能夠輔助你開發。

比較嚴格的代碼規範與項目架構，保證了你的應用在快速迭代中依然保持著最佳實踐。

自動為所有的Elm包添加語義版本描述。

總而言之，Elm為我們提供了優秀的工具來保證編寫乾淨、簡單與碎片化的代碼，並且因為Elm是可以編譯到JavaScript，因此很多JavaScript開發者都可以保持下關注或者嘗試下。

babili(babel-minify)

Babili最早於2016年8月份發布，它是基於Babel工具鏈上的支持原生ES6語法的壓縮工具。Henry Zhu在這篇文章中稱述了為什麼我們需要另一個壓縮工具，關鍵點如下：

目前大部分壓縮工具只能

夠處理ES5代碼，因此在壓縮之前需要先進性編譯，而Babili能夠支持直接輸入ES2015+。隨著瀏覽器性能的提升，越來越多的瀏覽器支持直接運行ES2015的代碼，因此我們不需要再進行轉換編譯。另外Babili也可以作為Babel preset引入到現有的Babel配置中，也可以作為直接使用的命令行工具。

這裡舉個簡單的例子，我們編寫了如下的ES6類:

之前，利用傳統的Babel進行編譯與壓縮，會得到如下代碼:

而Babili的效果如下:

OCaml

OCaml本身和JS沒啥關係，不過列表接下來的兩項都是基於OCaml，因此還是要先介紹下。如果你關注了近兩年來的函數式編程崛起之路，你或許聽過Haskell。而得益於OCaml能夠編譯到就S，其以後來居上的姿態凌駕於Haskell。Facebook的不少開發者都是OCaml的粉絲，他們的Hack、Flow以及Infer都是基於OCaml構建的。

BuckleScript

BuckleScript是基於OCaml實現的服務端框架，由著名的Bloomberg團隊創造而來。Duane Johnson對他們的解釋如下：

BuckleScript或者bsc，是個基於OCaml編譯器的相對較新的JavaScript服務端框架。換言之，你可以使用優秀的函數式、自帶類型的OCaml語言，同時也能繼續背靠基於npm包管理器的Web生態系統。

我們來簡要的看下BuckleScript代碼風格，譬如用BuckleScript實現簡單的服務端：

編譯輸出為:

OCaml最大的特性就是其函數式語言特性，我們再看下其對於不可變類型的支持，我們使用OCaml stdlib實現的不可變類型如下:

而如果要用Facebook Immutable實現的代碼為:

性能評測下，二者的執行時間對比為：

BuckleScript: 1186ms

JavaScript: 3415ms

編譯後的體積為：

BuckleScript (production): 899 Bytes

JavaScript: 55.3K Bytes

ReasonML

ReasonML與React師出同門，是基於OCamel設計的語法友好、編輯器支持程度高，並且有強大的編譯工具支持的語言。建議閱讀Sean Grove對ReasonML的介紹。本文簡單介紹幾個JavaScript與Reason的語法對比：

Purescript

另一個強類型、高性能的能夠編譯到JavaScript的編程語言，其定位與Elm類似，主要特性為：

沒有運行時錯誤

嚴格的，類似於JavaScript的計算

支持JavaScript 對象語法

提供相較於Hashkell更強大方便的類型系統

更方便地JavaScript庫集成

Webpack-blocks

Dan Abramov說過，Webpack的定位就是在相對底層，因此將配置以編程塊的方式實現會更加完備。

GraphQL

GraphQL是個不錯的REST替代查詢語言，特別是對於那些擁有大量數據的公司。這個案例分析很好地闡述了從REST到GraphQL的轉變之路。我能夠想像2017年GraphQL會繼續處於上升勢頭，不過要談到真的大規模實施，還要到2018年吧。

React Storybook

相信大家對於React Storybook並不陌生了，你能夠獨立於應用而互動式的開發你的組件，就如下圖所示：

[jQuery 3.0]()

爺爺輩的jQuery仍然處於不斷的迭代更新中，可能很多開發者忽略了2016年6月份發布的jQuery 3.0版本，可以參考這裡獲取更多信息。

Pixi.js

如果你打算在瀏覽器中實現精彩的2D效果，特別是對於使用WebGL的遊戲開發者，Pixi.js是個值得一看的庫，可以參考這裡獲取更多的Demo。

Preact與[inferno]()

非常優秀的React的替代庫。

Rust

Rust可以編譯到JavaScript啦（通過emscripten）。

Custom Elements

Custom Elements（包括Shadow DOM）一直不被主流的開發者接受，不過看似2017這一點將會發生些許變化。變化的關鍵因素在於瀏覽器支持比例的改善。個人還是蠻期待Custom Elements的，可以關注SmashingMag或者Google』s關於Custom Elements的解釋。

WebRTC

很難相信WebRTC已經五歲了，Facebook、Slack、Snapchat以及WhatsApp都在他們的服務中集成了WebRTC。可以預見WebRTC會在2017年被更多的公司採用，蒸蒸日上。

Next.js

Next.js是個基於React、Webpack與Babel構建的，支持服務端渲染的小框架，其來源於ZEIT團隊，在React社區獲得了不小的關注度。

本文編號2311，以後想閱讀這篇文章直接輸入2311即可。

輸入m可以獲取到文章目錄

本文內容的相關公眾號推薦

前端開發

Web開發

更多推薦《15個技術類公眾微信》

涵蓋：程序人生、演算法與數據結構、黑客技術與網路安全、大數據技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！