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

dj0379發表於2016-11-26
JavaScript

網路埋伏紀事 · 2016-11-12翻譯 5706閱讀 原文連結 

像其他人一樣，我最近偶然看到 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 的哪一塊？請在這裡，或者在我的推特 上留下評論，讓我知道。

如果你想知道下一次我要發表什麼文章，也可以註冊 the State Of JavaScript 郵件列表。

相關文章