摘要：組件成為前端最基本的物料，融合在組件中的方案日趨成熟。組件成為最基本的前端物料，讓組件化更徹底在的調(diào)研報(bào)告中，開(kāi)發(fā)者有愿意繼續(xù)，有愿意繼續(xù)。需要留意的是，有表示對(duì)感興趣，因此獲得的最感興趣獎(jiǎng)。

簡(jiǎn)介：

JavaScript 應(yīng)用范圍廣泛，靜態(tài)類(lèi)型語(yǔ)言 TypeScript 會(huì)繼續(xù)得到更多開(kāi)發(fā)者的青睞。

組件成為前端最基本的物料，CSS 融合在組件中(CSS in JS)的方案日趨成熟。

前端的“端”越來(lái)越多， API 查詢語(yǔ)言 GraphQL 會(huì)繼續(xù)保持高速增長(zhǎng) 。

在 github 2018 調(diào)查報(bào)告的中，JavaScript 連續(xù)多年穩(wěn)居第一，成為最受歡迎的開(kāi)發(fā)語(yǔ)言。從 Stack Overflow 的調(diào)查報(bào)告中，我們可以看到更詳細(xì)的數(shù)據(jù)，任意兩個(gè)開(kāi)發(fā)者中至少有一個(gè)會(huì) JavaScript，并且這個(gè)比例還在持續(xù)增長(zhǎng)，從 2016年的 55.4%，到 2017年的 62.2% ，到 2018 年的 69.8%。在 npm 的調(diào)查報(bào)告中，JavaScript 生態(tài)圈也是非常繁榮，module 的數(shù)量繼續(xù)保持高速增長(zhǎng)，將其他語(yǔ)言遠(yuǎn)遠(yuǎn)的甩在了后面。

圖一： npm 2018 調(diào)研報(bào)告 - Module Counts

從使用范圍上看，JavaScript 可以寫(xiě)前端、服務(wù)端、移動(dòng)端，甚至還可以寫(xiě)物聯(lián)網(wǎng)應(yīng)用。在 npm 2018 的調(diào)研報(bào)告中，大多數(shù) JavaScript 開(kāi)發(fā)者*寫(xiě) web 前端應(yīng)用(93%)和 node.js 服務(wù)端應(yīng)用(70%)。在 stateofjs 2018 的調(diào)研報(bào)告中，還有相當(dāng)數(shù)量的 JavaScript 開(kāi)發(fā)者*寫(xiě)移動(dòng)或桌面應(yīng)用，例如 Electron(19.6%)、React Native(18.7%)、Native Apps(10.6%)， Flutter 、Weex、PWA 都在 1% 以內(nèi)。

備注：npm 和 stateofjs 的調(diào)研用戶群體特征類(lèi)似，統(tǒng)一歸類(lèi)為 JavaScript 開(kāi)發(fā)者。

圖二： npm 2018 調(diào)研報(bào)告 - The JavaScript I write runs on...

值得注意的是，TypeScript 在 2018 年得到更多開(kāi)發(fā)者的青睞。在 github 語(yǔ)言排行版中，TypeScript 上升了 3 名，排到了第 7 的位置。在 stateofjs 2018 的調(diào)研報(bào)告中， JavaScript 開(kāi)發(fā)者有 86.3% 愿意繼續(xù)使用 ES6，有 46.7% 愿意繼續(xù)使用 TypeScript。排在第三、四的是 Facebook 的 Flow 和 Reason 語(yǔ)言，但是占比都不高。

圖三：stateofjs 2018 調(diào)研報(bào)告- JavaScript Flavors

從互聯(lián)網(wǎng)的發(fā)展歷史的角度看，2010 年 3G (國(guó)內(nèi))開(kāi)始普及，2014 年 4G 全面鋪開(kāi)，拉開(kāi)移動(dòng)互聯(lián)網(wǎng)的序幕?；ヂ?lián)網(wǎng)從傳統(tǒng)的內(nèi)容提供者，轉(zhuǎn)變成了服務(wù)提供者。前端應(yīng)用也發(fā)生的本質(zhì)的轉(zhuǎn)變，從傳統(tǒng)互聯(lián)網(wǎng)時(shí)代的內(nèi)容展示，轉(zhuǎn)變成了擁有復(fù)雜交互的邏輯的服務(wù)提供窗口。隨著前端應(yīng)用變得越來(lái)越復(fù)雜，和 JavaScript 應(yīng)用的領(lǐng)域越來(lái)越廣泛，傳統(tǒng) JavaScript(ES5) 已經(jīng)適應(yīng)復(fù)雜的開(kāi)發(fā)需求，因此功能更加強(qiáng)大的 ES6 孕育而出。

在 JavaScript 應(yīng)用復(fù)雜度不斷增加的背景下，預(yù)計(jì) 2019 年，靜態(tài)類(lèi)型語(yǔ)言 TypeScript 會(huì)繼續(xù)得到更多開(kāi)發(fā)者的青睞。TypeScript 屬于 ES6 的超集，一方面它可以很好的兼容 ES6 語(yǔ)法，另一方面它又提供了可選的靜態(tài)類(lèi)型檢查和接口(interface)的功能。在開(kāi)發(fā)復(fù)雜度高、需要大規(guī)模合作的 JavaScript 應(yīng)用時(shí)，TypeScript 相對(duì) ES6 不妨是一種更好的選擇。

在 stateofjs 2018 的調(diào)研報(bào)告中， JavaScript 開(kāi)發(fā)者有 64.8% 愿意繼續(xù) React，有 28.8% 愿意繼續(xù) Vue。但根據(jù)個(gè)人觀察，在國(guó)內(nèi) Vue 開(kāi)發(fā)者會(huì)比 React 多一些，這可能是因?yàn)?Vue 上手簡(jiǎn)單并且有完善的中文文檔。Angular 方面，有超過(guò)一半使用 Angular 框架的開(kāi)發(fā)者表示，不愿意繼續(xù)使用 Angular 進(jìn)行開(kāi)發(fā)了。而其他開(kāi)發(fā)框架 Preact、Ember、Polymer、JQuery 的使用量都很少?，F(xiàn)在，React 和 Vue 已經(jīng)成為前端開(kāi)發(fā)框架的雙雄，不會(huì) React 或 Vue 可能連工作都不好找。

圖四：stateofjs 2018 調(diào)研報(bào)告 - Front-end Frameworks

組件是 React 和 Vue 最強(qiáng)大的功能之一。在 Vue 中一個(gè) .vue 文件就是一個(gè)組件，包含 Template、JS、CSS 三個(gè)部分，其中 CSS 部分是可選的，開(kāi)發(fā)者也可以將 CSS 獨(dú)立出去。在 React 中一個(gè) .jsx 文件就是一個(gè)組件，但是 JSX 只能包含 Template、JS 兩個(gè)部分，組件的 CSS 部分必須 import from "xxx.css" 進(jìn)來(lái)。

無(wú)論是 React 還是 Vue，都改變不了 CSS 全局作用域的問(wèn)題。開(kāi)發(fā)者可以在一個(gè)組件中，通過(guò) Selector，如 .class .id ，取到本該屬于其他組件的 CSS 樣式。組件本應(yīng)是一個(gè)獨(dú)立的作用域，但是它的 CSS 竟然是全局的！在應(yīng)用復(fù)雜度低、單人開(kāi)發(fā)的情況下 CSS 全局作用域不算大問(wèn)題。但是在多人合作開(kāi)發(fā)的場(chǎng)景下，可能會(huì)因此導(dǎo)致樣式?jīng)_突。比如，因?yàn)橐肓?B 開(kāi)發(fā)者的組件，A 開(kāi)發(fā)者的組件樣式錯(cuò)亂了，這就導(dǎo)致了較高的聯(lián)調(diào)成本。

圖五：CSS document level V.S. component level

解決的思路就是，使用 CSS in JS 的工具，使得 CSS 只對(duì)它歸屬的組件生效。CSS in JS 的方案有很多，主流的有：styled-components、emotion、css-modules、aphrodite、glamor、glamorous、radium、react-jss。styled-components 方案使用人數(shù)最多，emotion 方案排第二并且增長(zhǎng)勢(shì)頭兇猛，而 css-modules 方案在兩年前已經(jīng)停止維護(hù)了，不再推薦。styled-components 的寫(xiě)法太反直覺(jué)，個(gè)人更喜歡 emotion。從下載量的增長(zhǎng)勢(shì)頭來(lái)看 emotion 比 styled-components 更快。因此，如果有 CSS in JS 需求的項(xiàng)目，更加推薦 emotion。相信在 2019 年，CSS in JS 方案會(huì)更加成熟，我們不妨期待吧。

圖六： npmtrends.com CSS in JS 方案下載量對(duì)比

在移動(dòng)互聯(lián)網(wǎng)時(shí)代來(lái)臨之前，傳統(tǒng)意義上的前端只有瀏覽器的 PC 端。移動(dòng)互聯(lián)網(wǎng)興起后，出現(xiàn)了瀏覽器的 H5 端、iOS 端、Android 端。再后來(lái)一些平臺(tái)級(jí) App ，比如微信、QQ，推出了自己的 JS-SDK，Hybird 也成為了新的端。近兩年，微信、支付寶、百度、頭條也推出了自己的小程序平臺(tái)，小程序也成為了新的端。

每個(gè)端都有自個(gè)兒的個(gè)性，不存在一種大統(tǒng)一的方案，可以適配所有的端。這導(dǎo)致了同一個(gè)業(yè)務(wù)，需要在 6 個(gè)端，開(kāi)發(fā) 6 次、聯(lián)調(diào) 6 次。

我們假設(shè)有一個(gè)這樣的 API，它包含了該業(yè)務(wù)在各個(gè)端上所有的數(shù)據(jù)，這不就解決了多次聯(lián)調(diào)的問(wèn)題了嘛。雖然還是需要開(kāi)發(fā) 6 次，但是現(xiàn)在因?yàn)橹挥?1 個(gè) API，所以聯(lián)調(diào)次數(shù)變成了 1 次。但是該方案的背后的代價(jià)是，加載慢、維護(hù)成本高。任意 1 個(gè)端，都要獲取其他 5 個(gè)端的上差異化的數(shù)據(jù)，加載能不慢嘛。如果 API 有改動(dòng)，可能會(huì)影響到 6 個(gè)端的代碼，維護(hù)起來(lái)也費(fèi)勁。

稍作改變，現(xiàn)在我們假設(shè)，前端可以通過(guò)一種標(biāo)準(zhǔn)的 API 查詢語(yǔ)法，精確地獲取任意自定義的數(shù)據(jù)，在服務(wù)端通過(guò)解析前端查詢語(yǔ)句，返回其自定義的查詢數(shù)據(jù)。雖然還是 6 個(gè)端，1 個(gè) API，但是每個(gè)端可以只獲取自己的數(shù)據(jù)，不就解決了加載慢的問(wèn)題了嘛。如果某個(gè)端需要增改獲取的數(shù)據(jù)，只需要修改這個(gè)端的查詢語(yǔ)句即可，這不就解決了維護(hù)成本高的問(wèn)題了嗎。通過(guò)定義一種標(biāo)準(zhǔn)的 API 查詢語(yǔ)法，可以使得前端獲取 API 數(shù)據(jù)，就像從數(shù)據(jù)庫(kù)獲取數(shù)據(jù)一樣方便和靈活。

GraphQL 就定義一套標(biāo)準(zhǔn)的 API 查詢語(yǔ)法，在保持靈活性和可維護(hù)性的前提下，極大的降低了聯(lián)調(diào)成本。

備注：GraphQL 官方使用的例子是，一個(gè)業(yè)務(wù)要請(qǐng)求多個(gè) REST 規(guī)范的 API 。但是，國(guó)內(nèi)通常使用的不是準(zhǔn)守標(biāo)準(zhǔn)的 REST API ，他們的痛點(diǎn)在國(guó)內(nèi)不那么痛，所以改用多端多 API 聯(lián)調(diào)成本高來(lái)舉例。

圖七：@helferjs 從REST到GraphQL

因?yàn)槭褂?API 查詢語(yǔ)言 GraphQL 獲取的方法太簡(jiǎn)單了，所以連數(shù)據(jù)管理的事省了。也就是說(shuō)，使用 GraphQL 可以把 Redux、Mobx 干的活給省了。我們可以看到，在 stateofjs 2018 調(diào)研報(bào)告中， 把 GraphQL 和 Redux、Mobx 都?xì)w類(lèi)為一類(lèi) —— 數(shù)據(jù)層(Data Layer)。報(bào)告中指出，有 47.2% 的 JavaScript 開(kāi)發(fā)者表示會(huì)繼續(xù)使用 Redux，20.4% 會(huì)繼續(xù)使用 GraphQL， 5.6% 會(huì)繼續(xù)使用 Mobx。需要留意的是，有 62.5% 表示對(duì) GraphQL 感興趣，因此 GraphQL 獲得 stateofjs 的最感興趣獎(jiǎng)(Highest Interest)。

圖八：stateofjs 2018 調(diào)研報(bào)告 - Data Layer

預(yù)計(jì) 2019 年，GraphQL 會(huì)繼續(xù)保持高速增長(zhǎng)，被更多的開(kāi)發(fā)者使用。在 npm 2018 調(diào)研報(bào)告中，特意指出了 GraphQL 的客戶端庫(kù) Apollo 的下載量保持著高速的增長(zhǎng)。

圖九：npm 2018 調(diào)研報(bào)告-GraphQL continues hyper-growth