簡介:css
在 github 2018 調查報告的中,JavaScript 連續多年穩居第一,成爲最受歡迎的開發語言。從 Stack Overflow 的調查報告中,咱們能夠看到更詳細的數據,任意兩個開發者中至少有一個會 JavaScript,而且這個比例還在持續增加,從 2016年的 55.4%,到 2017年的 62.2% ,到 2018 年的 69.8%。在 npm 的調查報告中,JavaScript 生態圈也是很是繁榮,module 的數量繼續保持高速增加,將其餘語言遠遠的甩在了後面。前端
圖一: npm 2018 調研報告 - Module Countsvue
從使用範圍上看,JavaScript 能夠寫前端、服務端、移動端,甚至還能夠寫物聯網應用。在 npm 2018 的調研報告中,大多數 JavaScript 開發者*寫 web 前端應用(93%)和 node.js 服務端應用(70%)。在 stateofjs 2018 的調研報告中,還有至關數量的 JavaScript 開發者*寫移動或桌面應用,例如 Electron(19.6%)、React Native(18.7%)、Native Apps(10.6%), Flutter 、Weex、PWA 都在 1% 之內。node
備註:npm 和 stateofjs 的調研用戶羣體特徵相似,統一歸類爲 JavaScript 開發者。react
圖二: npm 2018 調研報告 - The JavaScript I write runs on...git
值得注意的是,TypeScript 在 2018 年獲得更多開發者的青睞。在 github 語言排行版中,TypeScript 上升了 3 名,排到了第 7 的位置。在 stateofjs 2018 的調研報告中, JavaScript 開發者有 86.3% 願意繼續使用 ES6,有 46.7% 願意繼續使用 TypeScript。排在第3、四的是 Facebook 的 Flow 和 Reason 語言,可是佔比都不高。github
圖三:stateofjs 2018 調研報告- JavaScript Flavorsweb
從互聯網的發展歷史的角度看,2010 年 3G (國內)開始普及,2014 年 4G 全面鋪開,拉開移動互聯網的序幕。互聯網從傳統的內容提供者,轉變成了服務提供者。前端應用也發生的本質的轉變,從傳統互聯網時代的內容展現,轉變成了擁有複雜交互的邏輯的服務提供窗口。隨着前端應用變得愈來愈複雜,和 JavaScript 應用的領域愈來愈普遍,傳統 JavaScript(ES5) 已經適應複雜的開發需求,所以功能更增強大的 ES6 孕育而出。數據庫
在 JavaScript 應用複雜度不斷增長的背景下,預計 2019 年,靜態類型語言 TypeScript 會繼續獲得更多開發者的青睞。TypeScript 屬於 ES6 的超集,一方面它能夠很好的兼容 ES6 語法,另外一方面它又提供了可選的靜態類型檢查和接口(interface)的功能。在開發複雜度高、須要大規模合做的 JavaScript 應用時,TypeScript 相對 ES6 不妨是一種更好的選擇。npm
在 stateofjs 2018 的調研報告中, JavaScript 開發者有 64.8% 願意繼續 React,有 28.8% 願意繼續 Vue。但根據我的觀察,在國內 Vue 開發者會比 React 多一些,這多是由於 Vue 上手簡單而且有完善的中文文檔。Angular 方面,有超過一半使用 Angular 框架的開發者表示,不肯意繼續使用 Angular 進行開發了。而其餘開發框架 Preact、Ember、Polymer、JQuery 的使用量都不多。如今,React 和 Vue 已經成爲前端開發框架的雙雄,不會 React 或 Vue 可能連工做都很差找。
圖四:stateofjs 2018 調研報告 - Front-end Frameworks
組件是 React 和 Vue 最強大的功能之一。在 Vue 中一個 .vue
文件就是一個組件,包含 Template、JS、CSS 三個部分,其中 CSS 部分是可選的,開發者也能夠將 CSS 獨立出去。在 React 中一個 .jsx
文件就是一個組件,可是 JSX 只能包含 Template、JS 兩個部分,組件的 CSS 部分必須 import from 'xxx.css'
進來。
不管是 React 仍是 Vue,都改變不了 CSS 全局做用域的問題。開發者能夠在一個組件中,經過 Selector,如 .class
.id
,取到本該屬於其餘組件的 CSS 樣式。組件本應是一個獨立的做用域,可是它的 CSS 居然是全局的!在應用複雜度低、單人開發的狀況下 CSS 全局做用域不算大問題。可是在多人合做開發的場景下,可能會所以致使樣式衝突。好比,由於引入了 B 開發者的組件,A 開發者的組件樣式錯亂了,這就致使了較高的聯調成本。
圖五:CSS document level V.S. component level
解決的思路就是,使用 CSS in JS 的工具,使得 CSS 只對它歸屬的組件生效。CSS in JS 的方案有不少,主流的有:styled-components、emotion、css-modules、aphrodite、glamor、glamorous、radium、react-jss。styled-components 方案使用人數最多,emotion 方案排第二而且增加勢頭兇猛,而 css-modules 方案在兩年前已經中止維護了,再也不推薦。styled-components 的寫法太反直覺,我的更喜歡 emotion。從下載量的增加勢頭來看 emotion 比 styled-components 更快。所以,若是有 CSS in JS 需求的項目,更加推薦 emotion。相信在 2019 年,CSS in JS 方案會更加成熟,咱們不妨期待吧。
圖六: npmtrends.com CSS in JS 方案下載量對比
在移動互聯網時代來臨以前,傳統意義上的前端只有瀏覽器的 PC 端。移動互聯網興起後,出現了瀏覽器的 H5 端、iOS 端、Android 端。再後來一些平臺級 App ,好比微信、QQ,推出了本身的 JS-SDK,Hybird 也成爲了新的端。近兩年,微信、支付寶、百度、頭條也推出了本身的小程序平臺,小程序也成爲了新的端。
每一個端都有自個兒的個性,不存在一種大統一的方案,能夠適配全部的端。這致使了同一個業務,須要在 6 個端,開發 6 次、聯調 6 次。
咱們假設有一個這樣的 API,它包含了該業務在各個端上全部的數據,這不就解決了屢次聯調的問題了嘛。雖然仍是須要開發 6 次,可是如今由於只有 1 個 API,因此聯調次數變成了 1 次。可是該方案的背後的代價是,加載慢、維護成本高。任意 1 個端,都要獲取其餘 5 個端的上差別化的數據,加載能不慢嘛。若是 API 有改動,可能會影響到 6 個端的代碼,維護起來也費勁。
稍做改變,如今咱們假設,前端能夠經過一種標準的 API 查詢語法,精確地獲取任意自定義的數據,在服務端經過解析前端查詢語句,返回其自定義的查詢數據。雖然仍是 6 個端,1 個 API,可是每一個端能夠只獲取本身的數據,不就解決了加載慢的問題了嘛。若是某個端須要增改獲取的數據,只須要修改這個端的查詢語句便可,這不就解決了維護成本高的問題了嗎。經過定義一種標準的 API 查詢語法,可使得前端獲取 API 數據,就像從數據庫獲取數據同樣方便和靈活。
GraphQL 就定義一套標準的 API 查詢語法,在保持靈活性和可維護性的前提下,極大的下降了聯調成本。
備註:GraphQL 官方使用的例子是,一個業務要請求多個 REST 規範的 API 。可是,國內一般使用的不是準守標準的 REST API ,他們的痛點在國內不那麼痛,因此改用多端多 API 聯調成本高來舉例。
圖七:@helferjs 從REST到GraphQL
由於使用 API 查詢語言 GraphQL 獲取的方法太簡單了,因此連數據管理的事省了。也就是說,使用 GraphQL 能夠把 Redux、Mobx 乾的活給省了。咱們能夠看到,在 stateofjs 2018 調研報告中, 把 GraphQL 和 Redux、Mobx 都歸類爲一類 —— 數據層(Data Layer)。報告中指出,有 47.2% 的 JavaScript 開發者表示會繼續使用 Redux,20.4% 會繼續使用 GraphQL, 5.6% 會繼續使用 Mobx。須要留意的是,有 62.5% 表示對 GraphQL 感興趣,所以 GraphQL 得到 stateofjs 的最感興趣獎(Highest Interest)。
圖八:stateofjs 2018 調研報告 - Data Layer
預計 2019 年,GraphQL 會繼續保持高速增加,被更多的開發者使用。在 npm 2018 調研報告中,特地指出了 GraphQL 的客戶端庫 Apollo 的下載量保持着高速的增加。
圖九:npm 2018 調研報告-GraphQL continues hyper-growth