一個治癒 JavaScript 疲勞的學習計劃

轉自：https://www.w3ctech.com/topic/1908

網絡埋伏紀事

像其餘人同樣，我最近偶然看到 Jose Aguinaga 的文章《在 2016 年學 JavaScript 是一種什麼樣的體驗》」。

譯者注：中文翻譯在此。

很顯然，這篇文章觸到了不少人的痛點：我看到它兩次榮登 Hacker News 的榜首。它也是 /r/javascript 上最熱門的文章，而且截至目前它在 Medium 上有超過 10K 個喜歡 - 可能比我本身全部文章加在一塊兒還要多。可是誰在意呢？

不過這不足爲奇：我早就知道 JavaScript 生態圈會讓人困惑。實際上，我作 JavaScript 2016年的概況調查的最大緣由就是想找到哪些庫是真正流行的，最後從紛雜中挑選出來。

可是今天，我想更進一步。只是抱怨事物的狀態並無什麼卵用，我打算給你一個征服 JavaScript 生態圈的實實在在的、一步一步的學習計劃。

目標人羣

若是你是以下之一，那麼本學習計劃就是爲你定製的：

• 你已經熟悉了基礎編程概念，好比變量和函數。

• 你可能已經用諸如 PHP 和 Python 之類的語言作事後臺的工做，而且可能爲一些簡單技巧用過諸如 jQuery 這種前端庫。

• 你如今想從事一些更正規的前端開發，可是在開始以前就被框架和庫淹沒。

咱們將講解的事情

• 一個現代 JavaScript Web 應用看起來像什麼樣子

• 爲何你不能只用 jQuery

• 爲何 React 是最安全的選擇

• 爲何你也許不須要先「正確地學習 JavaScript「

• 如何學習 ES6 語法

• 爲何要以及如何學習 Redux

• GraphQL 是什麼以及爲何它是一個大事

• 下一步要去哪裏

這裏提到的資源

聲明：本文將包含一些對 Wes Bos 所作課程的附屬連接，可是我推薦他的素材是由於我真心認爲不錯，而不只僅是由於附屬方案。

若是你寧肯找其它資源，那麼能夠看看 Mark Erikson 維護的一份 React、ES6 和 Redux 的長長連接列表。

JavaScript 對 JavaScript

在開始以前，咱們須要確保咱們談論的是同一件事情。若是你搜索 "學習 JavaScript" 或者 "JavaScript 學習計劃"，會找到大量教你如何學習 JavaScript 語言 的資源。

可是這其實是 簡單的 部分。你確定能夠深刻挖掘和學習這門語言複雜的部分，而後事實是大多數 web 應用只用了相對簡單的代碼。換句話說，爲編寫 web 應用，你所需的 80% 知識一般只涉及標準 JavaScript 書的前幾章。

最難搞定的是掌握 JavaScript 生態圈，這個生態圈有不可勝數的競爭性的框架和庫。好消息是，這恰好是本學習計劃關注的問題。

JavaScript 應用的構建單元

要理解爲何現代 JavaScript 應用好像如此複雜，你首先得理解它們的工做機制。

對於初學者，咱們來看看大約在 2008 年的「傳統」 web 應用：

1. 數據庫發送數據給你的後臺（好比你的 PHP 或者 Rails 應用）。

2. 後臺讀取該數據，並輸出 HTML。

3. HTML 被髮送給瀏覽器，瀏覽器將其顯示爲 DOM（即，網頁）

如今不少這種應用也會在客戶端塞進一些 JavaScript 代碼來添加交互性，好比標籤和模態窗口。可是從本質上講，瀏覽器依然是接收 HTML 而且從這裏開始。

如今把它與「現代" 2016年的 Web 應用（也稱爲"單頁應用「）比較：

注意到區別沒有？服務器如今是發送數據，而不是發送 HTML，而且「數據到HTML"轉換步驟發生在客戶端 (這也是爲何你要把數據與代碼一塊兒發送，告訴客戶端如何執行所說的轉換）。

這有不少含義。首先，好的部分是：

• 對於給定內容塊，只發送數據比發送整個 HTML 頁面更快。

• 客戶端能夠當即切換內容，而不須要像之前那樣刷新瀏覽器窗口（這也是術語「單頁應用」的由來）。

壞的部分是：

• 首次加載更長，由於"數據到 HTML」代碼庫會變得很大。

• 你如今也須要一個地方來存儲和管理客戶端上的數據，以防你想緩存它或者檢查它。

而噁心的部分是：

• 恭喜 - 你如今不得不處理客戶端技術棧，這會變得跟服務器端技術棧同樣複雜。

客戶端-服務器光譜

那麼既然有這麼多缺點，爲何要經受這種麻煩呢？爲何不就沿襲過去 PHP 應用的老套路呢？

好吧，假設你正在寫一個計算器。若是用戶想知道 2 + 2 是多少，那麼當瀏覽器徹底有能力作這種事情的時候，回到服務器執行這種操做就沒什麼意義了。

另外一方面，若是你是建立一個純靜態網站，好比博客，那麼在服務器上生成最終的 HTML，而後萬事大吉，就很是好了。

事實是，大多數 web 應用介於光譜的中間地帶。問題是要知道在哪裏。

可是關鍵的事情是 這個光譜是不連續的 ：你不能從一個純服務器端應用開始，慢慢走向一個純客戶端應用。在某個點（分水線 divide），你會被強制停下來，重構全部東西，不然會以一大堆不可維護的意大利麪條式的代碼而了結。

這就是爲何你不該該無論作什麼都只用 jQuery。你能夠把 jQuery 看成是牛皮膠布。用它對付家裏的小修小補仍是很方便，可是若是你處處貼就很難看了。

另外一方面，現代 JavaScript 框架更像 3D 打印的一個替換零件：要花更長時間，可是結果是更乾淨更堅固。

也就是說，掌握現代 JavaScript 技術棧是個賭注，無論從哪裏開始，大多數 web 應用 可能 早晚都會出如今分水線的右邊。因此，是的，要乾的活更多了，可是有備無患更好。

第 0 周: JavaScript 基礎

除非你是一名純後臺開發者，不然你可能會了解點 JavaScript。固然，即便你不瞭解，若是你是一名 PHP 或者 Java 開發者，JavaScript 的類 C 語法也會看起來有點熟悉。

可是若是 JavaScript 對你來講是徹底摸不着頭腦，也不要灰心。有不少免費資源在那，能夠快速讓你瞭解最新狀況。好比，一個不錯的出發點是 Codecademy 的 JavaScript 課。

第 1 周: 從 React 開始

如今知道了基礎 JavaScript 語法，並且你理解了爲何 Javascript 應用顯得那麼複雜，下面咱們詳談。到底要從哪裏開始呢？

我相信答案是 React。

React 是一個由 Facebook 建立和開源的 UI 庫。也就是說，它負責「數據到HTML"這一步（視圖層）。

如今不要誤會我：我不是告訴你由於 React 是 最好 的庫，因此要選它（由於這太主觀了），而是由於它是 至關不錯 。

• React 也許不是最流行的庫，可是它是至關流行的。

• React 也許不是最輕量級的庫，可是它是至關輕量級的。

• React 也許不是最容易學的，可是它是至關容易學的。

• React 也許不是最優雅的庫，可是它是至關優雅的。

也就是說，React 也許並不是是全部狀況的 最佳 選擇，可是我相信它是最 安全 的。相信我，"就在你剛開始的時候"並非承擔技術選擇風險的最佳時間。

React 也會給你介紹一些有用的概念，好比組件、應用程序狀態、無狀態函數。無論在你職業生涯期間最終使用哪一個框架或者庫，這些概念都會被證實是有用的。

最後，React 有一個很大的生態圈，這個生態圈還包括其它能夠與 React 配合得很好的包和庫。而且它的徹底普及意味着你能夠在 Stackoverflow 這類網站上找到不少幫助。

我我的推薦 We Bos 的 React初學者課程。我本身就是看這個課程學的，並且它剛剛用最新的 React 最佳實踐完全修訂過。

你應該首先「正確地學習 JavaScript」 嗎？

若是你是一個頗有條理的學習者，你可能想在作其它事情以前很好地掌握 JavaScript 的基本原理。

可是對於其它人來講，這就好像是學游泳的時候學習人體解剖學和流體動力學同樣。確實，這兩者都在游泳中起了很大的做用，可是跳到游泳池裏會更好玩！

這裏沒有正確或者錯誤的答案，一切都取決於你的學習方式。事實是，反正最基礎的 React 教程可能會只用到 JavaScript 很小的一個子集，因此只關於你如今須要的，剩下的之後再說，這樣會更好。

這也適用於整個 JavaScript 生態圈。如今先不要對理解像 Webpack 或者 Babel 這些東西的前因後果操太多心。實際上 React 最近推出了它本身的小命令行工具，用這個工具你徹底不須要構建任何配置，就能夠建立應用。

第 2 周: 你的第一個 React 項目

下面咱們假設你剛完成了一個 React 課程。若是你跟我同樣，那麼兩件事情多是真的：

• 你已經忘掉你剛學的一半。
• 你火燒眉毛要把你記得的一半用於實踐。

我相信學習一個框架或者一門語言的最好方式是立刻就用它。而我的項目是嘗試新技術的完美時機。

我的項目能夠是任何東西，小到一個簡單頁面，大到一個複雜的 Web 應用，可是我認爲從新設計你的我的網站多是一個好的中間立場。而且，我知道你可能已經把你的我的網站擱置多年了！

我前面確實說過，對於靜態內容使用單頁應用是有點矯枉過正了，可是 React 實際上有一個祕密武器：Gatsby。這是一個 React 靜態網站生成器，可讓你「做弊」，得到全部 React 的好處，而沒有任何缺點。

以下是爲何 Gatsby 是開始使用 React 的好方法的緣由：

• 預先配置好的 Webpack，意味着你能夠好不費勁獲得全部好處。

• 基於目錄結構的自動化路由。

• 全部 HTML 內容也是由服務器端生成的，全部你獲得了一箭雙鵰的結果。

• 靜態內容意味着不須要服務器，能夠超級簡單地存放在 GitHub Pages上。

我就是用 Gatsby 搞定 State Of JavaScript 網站，徹底不須要操心路由、構建工具的配置，以及服務器端渲染節省了我大把時間。

第 3 周: 掌握 ES6

在我本身學習 React 的探索中，我很快就達到經過複製粘貼代碼示例就能懂的地步，可是仍是有不少東西我理解不了。

特別是，我對 ES6 引入的一些新功能不太熟悉，好比：

• 箭頭函數

• 對象解構

• 類

• 展開運算符

若是你處境相同，那麼可能到了要花幾天學習一下 ES6 的時候了。若是你喜歡 React 初學者課程，你可能想掏錢看看 Wes 的優秀視頻 ES6 for Everybody。

或者若是你喜歡免費資源的話，那就看看 Nicolas Bevacqua 的書《Practical ES6》。

掌握 ES6 的一個好練習是翻一下較早的代碼庫（好比你在第一週建立的！），儘量將代碼轉換爲 ES6 的更短、更簡潔的語法。

第 4 周: 承擔狀態管理

到了這裏，你應該有能力建立一個支持靜態內容的簡單 React 前端了。

可是真正的 Web 應用不會是靜態的：它們須要從某個地方獲取數據，一般是某種類型的數據庫。

如今你只能向一個組件發送數據，可是這很快會變得很糟糕。好比，若是兩個組件須要顯示同一塊數據該怎麼辦？或者兩者兩個組件須要相互對話該怎麼辦？

這就是狀態管理起做用的地方。你能夠把狀態（換句話說，就是數據）存儲到一個全局的倉庫中，而後將其分發到你的 React 組件中，而不是一點一點存儲在每一個組件中：

在 React 領域，最熱門的狀態管理庫是 Redux。Redux 不只能夠幫助集中管理數據，還能夠強制一些操做該數據的嚴格協議。

能夠地把 Redux 看成是一個銀行：你不能到本地的分行，手動修改你的帳戶總額（「嘿，就讓我多加幾個零吧！」）。而是填寫一個存款單，而後把它交給受權執行該操做的銀行出納員。

一樣，Redux 也不會讓你直接修改全局狀態。而是將 action 傳遞給 reducer。reducer 是一個特殊的函數，它執行修改狀態的操做，返回新的更新了的狀態爲結果。

全部這些額外工做帶來的是整個應用中高度標準化和可維護的數據流，而且數據流能夠經過訪問 Redux Devtools 這類工具來可視化：

你能夠再次與咱們的朋友 Wes 在一塊兒，用他的 Redux 課程來學習 Redux，這套課程是徹底免費的。

或者，你能夠用 Redux 的發明人 Dan Abramov 在 egghead.io 上的視頻課程來學習。這套課程也是免費的。

第 5 周: 用 GraphQL 建立 API

迄今爲止，咱們差很少只談及了客戶端，這只是等式的一半。而且即便沒有進入整個 Node 生態圈，解決全部 Web 應用的關鍵環節之一：數據是如何從服務器到客戶端的，也是很重要的。

絕不奇怪，這個環節也是快速變化的。此時，Facebook 的另外一個開源項目 GraphQL 應運而生，成爲傳統 REST API 的一個重要替代物。

REST API 暴露多個 REST 路由，每一個路由讓你能夠訪問一個預約義的數據集（好比，/api/post、/api/comments 等等）。而 GraphQL 只暴露一個端點，讓客戶端能夠經過這一個端點查詢它所需的數據。

就好像你要買不少東西，REST API 就是屢次來回肉店、麪包店、小賣部，而 GraphQL 就是給某人一個購物清單，而後把他送到這三個地方。

當你須要查詢多個數據源的時候，這種新策略就變得特別有意義了。就像購物清單示例同樣，如今你能夠用一個請求，從全部這些數據源獲取數據。

GraphQL 在過去一年左右的時間已經日益受歡迎，不少項目（好比咱們第二週所用的 Gatsby）都在計劃採用它。

GraphQL 自己只是一個協議，可是目前它的最佳實現多是 Apollo 庫。這個庫能與 Redux 很好地配合。有關 GraphSQL 和 Apollo 的教學材料依然不多，可是但願 Apollo 文檔 能幫你開始。

除了 React 及其生態圈外

我推薦你從 React 生態圈開始，是由於它是安全的選擇。可是，它絕非是惟一有效的前端技術棧。若是你想繼續探索的話，這裏還有兩個推薦：

Vue

Vue 是一個相對比較新的庫，可是它正以創記錄的速度增加，並且已經被大公司採納。特別在中國，它正被像百度和阿里巴巴（被認爲是中國的谷歌和中國的亞馬遜）這樣的公司採用。而且它仍是 PHP 框架 Laravel 的官方前端層。

與 React 相比，它的一些關鍵賣點是：

• 官方維護的路由和狀態管理庫。

• 關注於性能。

• 較低的學習曲線（因爲使用的是基於 HTML 的模板）。

• 較少的樣板代碼。

按照如今的狀況，依然讓 React 比 Vue 佔優點的兩個主要因素是 React 生態圈的大小，以及 React Native (稍後會詳細介紹）。可是我會好不吃驚地看到 Vue 會很快遇上！

Elm

若是說 Vue 是更平易近人的選項，那麼 Elm 就是更前沿的選項。Elm 不只是一個框架，仍是一個編譯到 JavaScript 的全新語言。

這帶來很多優勢，好比性能提高、強制語義版本控制以及無運行時異常。

我本人尚未試過 Elm，可是個人朋友們都給我熱烈推薦它。而且 Elm 用戶一般看起來對它很滿意（JavaScript 2016的概況調查中展現 Elm 有 84% 的滿意度）。

下一步

到這裏你應該已經很好地掌握了整個 React 前端技術棧，而且有但願用它帶來至關的產出。

可是這並不意味着這就完事了！這只是 JavaScript 生態圈旅程的開端。你會逐漸遇到一些其它主題，包括：

• 服務器端的 JavaScript (Node、Express…)

• JavaScript 測試 (Jest、Enzyme…)

• 構建工具 (Webpack…)

• 類型系統 (TypeScript、Flow…)

• 處理 JavaScript 應用中的 CSS (CSS 模塊、樣式化的組件Styled Components…)

• JavaScript 移動應用開發 (React Native…)

• JavaScript 桌面應用開發 (Electron…)

我不可能在這裏就涵蓋全部這些內容，可是不要灰心！第一步老是最艱難的，你猜怎麼着：你已經經過閱讀本學習計劃，跨出了第一步。

如今你理解了如何把生態圈中不一樣部分組合在一塊兒，這不過就是將你下一步想學習的內容排隊，而且每月搞定一個新技術。

保持聯繫

這個學習計劃對你有幫助嗎？你但願我下一次寫 JavaScript 的哪一塊？請在這裏，或者在 個人推特 上留下評論，讓我知道。

若是你想知道下一次我要發表什麼文章，也能夠註冊 the State Of JavaScript 郵件列表。