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

時間 2019-11-11

標籤值得一瞥 javascript 相關技術趨勢欄目 JavaScript 简体版

原文原文鏈接

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

本文中說起的這些趨勢可能離大部分開發者還很遠，或者說離真正的大規模工程化應用還很遠，不過不妨礙咱們提早兩三年瞭解下。本文僅表明原做者我的見解，不喜留言輕噴，譯者也很好奇你們對這個列表的見解。前端

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

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

WebAssembly

去年筆者就表示過了對於WebAssembly的期待，WebAssembly就是面向Web平臺的底層代碼。其初衷是但願可以使全部語言都可以編譯運行到Web平臺，這一點對於不少函數式編程、響應式編程的粉絲充滿吸引力。特別是隨着這幾年JavaScript社區的日新月異，不少開發者並不能跟得上這門語言衍化的速度，所以他們也很是但願可以直接用本身習慣的語言而不是要去重頭學一門從入門到直接放棄的語言。不過JavaScript目前還處於明顯的上升勢頭，暫時還沒人唱衰它。而且WebAssembly仍處於襁褓中，才進入到預覽階段，離真正的發佈還有很長的距離。總結而言，筆者建議咱們都應該對WebAssembly保持必定的關注，畢竟它會對將來的JavaScript形成極大的影響。若是你對於WebAssembly有興趣，那麼推薦閱讀Eric Elliott的相關博客。web

Elm

筆者我的不太意願使用Elm，不過其特性仍是頗有借鑑價值npm

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

並不會存在運行時錯誤，沒有null，沒有undefined is not a funtion。api
很是友好的錯誤提示信息可以輔助你開發。瀏覽器
比較嚴格的代碼規範與項目架構，保證了你的應用在快速迭代中依然保持着最佳實踐。babel
自動爲全部的Elm包添加語義版本描述。

總而言之，Elm爲咱們提供了優秀的工具來保證編寫乾淨、簡單與碎片化的代碼，而且由於Elm是能夠編譯到JavaScript，所以不少JavaScript開發者均可以保持下關注或者嘗試下。

babili(babel-minify)

Babili最先於2016年8月份發佈，它是基於Babel工具鏈上的支持原生ES6語法的壓縮工具。Henry Zhu在這篇文章中稱述了爲何咱們須要另外一個壓縮工具，關鍵點以下：
目前大部分壓縮工具只能

夠處理ES5代碼，所以在壓縮以前須要先進性編譯，而Babili可以支持直接輸入ES2015+。隨着瀏覽器性能的提高，愈來愈多的瀏覽器支持直接運行ES2015的代碼，所以咱們不須要再進行轉換編譯。另外Babili也能夠做爲Babel preset引入到現有的Babel配置中，也能夠做爲直接使用的命令行工具。

這裏舉個簡單的例子，咱們編寫了以下的ES6類:

class Mangler {     constructor(program) {       this.program = program;     }   }   // need this since otherwise Mangler isn't used   new Mangler();

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

// ES2015 code -> Babel -> Uglify/Babili -> Minified ES5 Code   var a=function a(b){_classCallCheck(this,a),this.program=b};a();

而Babili的效果以下:

// ES2015 code -> Babili -> Minified ES2015 Code   class a{constructor(b){this.program=b}}new a;

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實現簡單的服務端：

let port = 3000   let hostname = "127.0.0.1"   let create_server http =     let server = http##createServer begin fun [@bs] req resp ->         resp##statusCode #= 200;         resp##setHeader "Content-Type" "text/plain";         resp##_end "Hello world\n"       end     in     server##listen port hostname begin fun [@bs] () ->       Js.log ("Server running at http://"^ hostname ^ ":" ^ Pervasives.string_of_int port ^ "/")     end   let () = create_server Http_types.http

編譯輸出爲:

'use strict';   var Pervasives = require("bs-platform/lib/js/pervasives");   var Http       = require("http");   var hostname = "127.0.0.1";   function create_server(http) {     var server = http.createServer(function (_, resp) {       resp.statusCode = 200;       resp.setHeader("Content-Type", "text/plain");       return resp.end("Hello world\n");     });     return server.listen(3000, hostname, function () {       console.log("Server running at http://" + (hostname + (":" + (Pervasives.string_of_int(3000) + "/"))));       return /* () */0;     });   }   create_server(Http);

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

module IntMap = Map.Make(struct     type t = int     let compare (x : int) y = compare x y   end)   let test () =     let m = ref IntMap.empty in     let count = 1000000 in     for i = 0 to count do       m := IntMap.add i i !m     done;     for i = 0 to count do       ignore (IntMap.find i !m)     done   let () = test()

而若是要用Facebook Immutable實現的代碼爲:

'use strict';   var Immutable = require('immutable');   var Map = Immutable.Map;   var m = new Map();   function test() {     var count = 1000000;     for(var i = 0; i < count; ++i) {       m = m.set(i, i);     }     for(var j = 0; j < count; ++j) {       m.get(j);     }   }   test();

性能評測下，兩者的執行時間對比爲：

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的定位就是在相對底層，所以將配置以編程塊的方式實現會更加完備。

const { createConfig, defineConstants, env, entryPoint, setOutput, sourceMaps } = require('@webpack-blocks/webpack2')           const babel = require('@webpack-blocks/babel6')           const devServer = require('@webpack-blocks/dev-server2')           const postcss = require('@webpack-blocks/postcss')           const autoprefixer = require('autoprefixer')           module.exports = createConfig([             entryPoint('./src/main.js'),             setOutput('./build/bundle.js'),             babel(),             postcss([               autoprefixer({ browsers: ['last 2 versions'] })             ]),             defineConstants({               'process.env.NODE_ENV': process.env.NODE_ENV             }),             env('development', [               devServer(),               devServer.proxy({                 '/api': { target: 'http://localhost:3000' }               }),               sourceMaps()             ])           ]);

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的解釋。