- 原文地址：Why is Front-End Development So Unstable?
- 原文作者：Jimmy Breck-McKye
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：Colafornia
- 校對者：geniusq1981 sunhaokk
我們都知道這樣一個笑話：在你學會一項前端技術的時候，另外三項新技術已經發布了。不僅如此，你剛學會的那個也已經被棄用了。
我們卻不常看到有解釋為什麼會這樣。
典型的解釋（來源於 reddit 的 r/programming 頻道）這似乎與前端開發者天生不耐煩，追逐流行與能力有限相關，這種解釋構成了一個更普遍的謬論：假設你所不理解的行為是由整個群體的愚蠢，糟糕或貪婪造成的 (而你自己的不明智行為完全是由你無法控制的因素造成的)。
無論它是不是謬論，我們確實有這個問題，對嗎？
量化問題
在跑偏之前，我們有必要確定這個問題是否真的有現實依據。前端技術真的變化很快嗎？
從主流受關注（也可能不是）的技術來看，細想一下這個 Github 上“高星” JavaScript 前端技術排行：
+------------------------------------------------------------+
| 庫 | Star 數 | 釋出時間 | 年齡 |
|------------------------------------------------------------+
| React | 96986 | 2015 年 3 月 | 3 年 |
| Vue | 95727 | 2015 年 10 月 | 2.5 年 |
| Angular (1) | 58531 | 2010 年 10 月 | 7.5 年 |
| jQuery | 49061 | 2006 年 8 月 | 11 年 |
| Angular (2+) | 36665 | 2015 年 12 月 | 2.5 年 |
| Backbone | 27194 | 2010 年 10 月 | 7.5 年 |
| Polymer | 19668 | 2015 年 5 月 | 3 年 |
| Ember | 19003 | 2011 年 12 月 | 6.5 年 |
| Aurelia | 10506 | 2016 年 6 月 | 2 年 |
| Knockout | 8894 | 2010 年 7 月 | 8 年 |
+------------------------------------------------------------+
複製程式碼最年輕的專案已經兩歲半了，雖然並不是那麼老，例如，它都不到你的桌面作業系統維護週期的一半長，但是也不是像那個笑話說的那樣。所以是什麼導致人們對前端有了這種更迭快速、甚至不可持續變化的感覺呢？
React 與它的朋友們
可能是 React 造成的。作為一個強力工具，它需要一系列的輔助模組和支援庫來支撐，這就是問題所在。React 生態中我稱之為“微型庫（microlib）架構”的內容非常龐大，其應用是由無數離散的，單一用途的 JavaScript 庫組成，以對 Unix 哲學 致敬。
這一架構的優點是，當新的實踐出現，你可以快速適應，這在像幾年前那種快速革新階段非常有用。缺點在於它使你需要經常進行大型迭代，同時也要求你在眾多（往往太多）所謂的微型庫（microlib）中審查挑選。
這也是我論點的主旨：問題不在於 JavaScript 語言本身 [1]，Web 或是任何特定的技術，而是糟糕的“做選擇式架構”使得開發者不得不追逐流行趨勢。
NPM 問題
NPM 是現代 JavaScript 的最大資產，也是最大負債。它提供了豐富的模組，幾乎可以滿足任意特定需求，但很難對於這些模組進行過濾和管理。哪些模組是真正得到支援的？哪些模組真的有正確的功能？哪些模組不只是惡意軟體的載體？JavaScript 開發者真正使用的選擇方法是受歡迎程度——下載次數與 Github 上的 Star 數量，這無疑加劇了追逐流行的風氣。
當然還有其它方法去甄別一個庫：你可以瀏覽這個庫的 Github issue 列表，在 StackOverflow 上搜尋問題。你也可以做一些測試甚至自己檢查原始碼（在大多數情況下）。但這些方法都耗費時間，在選擇類似日期解析模組這種小玩意兒時，沒有必要做這些耗費時間的事。
我承認這是 JavaScript 開發者的一個文化缺陷。作為面試官，我經常問面試者是如何進行技術選型的，答案令人沮喪，受歡迎程度總是他們唯一知道的指標。軟體工程至少在一定程度上是一項研究工作，我們需要培訓初級工程師這些研究技能，但是即使我們做了培訓，工程師們也未必能做出正確的選擇。
想象自己是一名初級工程師
站在初級、中級 JavaScript 開發人員的角度，第一次編寫新的應用程式。
起初你很天真。你的專案非常乾淨並希望讓事情一直簡單，你是一個虔誠的 Agilist（敏捷開發倡導者）而且 YAGNI（You aren't gonna need it，意為 “你不需要它”）是你的口號。因此你從一個“簡單的框架”入手。這感覺挺好，對吧？（即使感覺並不好，這也經常是你唯一的選擇）。
作為一個基本框架它能做的事很少，因此擔子落在你的肩上，需要選擇一些輔助庫。如果你負責前端工作，可能是 Redux 的用於表單和 API 請求的輔助庫。如果是後端，則可能是 Express 中介軟體[2]。
如果你用 Google 搜尋一下，會發現一個強烈推薦 X.js 的 Medium 文章。後來發現這篇文章就是 X.js 的作者寫的，儘管她從未宣告過利益衝突（但是她提供了一個 GitTip 的 jar 包）。並不是說所有的 Medium 文章看起來都一樣，因此你不能依賴某個“品牌”來識別有信譽的資料。
你錯過了一些指出 X.js 致命缺陷的評論，因為 Medium 有意壓下了這些評論，然後你去繼續尋找一個 Y。
這次你在 Twitter 上找到了一個有一百多個紅心的連結！你猜這是個好訊號，因為 Twitter 是一個比你懂得更多的社群“策劃”的。你在感激之情中也點了紅心（像之前那一百多個人一樣）然後按照連結到了 Github。
事情進展的沒那麼快。那個連結過時了——這個庫已經被廢棄了。你會發現這一點是因為頁面上到處都是 DEPRECATED 這個單詞，，就像史努比主題公園裡的 CONDEMNED 標誌（譯者注：史努比系列電影中的一個主題）。
你發現 Y.js 是“物件導向”的。你模糊記起計算機專業大一時學到的物件導向程式設計語言和通訊的內容，覺得這是一個好東西。但顯然這很糟糕。
Medium 上的另一篇文章試圖解釋為什麼，然而他的論證不僅含糊不清，還有一堆密密麻麻你不認識的術語。後來你發現這些術語就是文章作者自己發明的，正如他所引用的看似中立的外部部落格文章一樣，他引用了自己的論點。
情況變得更糟了。文章聲稱在 JavaScript 面試中提到 OOP（物件導向）也會導致你拿不到 offer！你現在已經完全懵逼了。謝天謝地，手頭就有解決方案——文章作者的售價 50 刀的 JavaScript 開發課程。你記下了課程連結，感覺三生有幸才能找到這個課程，為了表示感激又給了一個 clap（此文章的第一萬九千零一個 clap）（譯者注：clap 是 Medium 上類似於點讚的一個東西）。
於是你繼續找到了 Github 上的高星專案 Z.js，雖然它的文件看起來沒什麼用。文件只是列出了一堆方法，實際該怎麼使用 Z.js 呢？至少看到 Z.js 使用了叫 “Standard JS” 的東西，你覺得這與 ECMA 標準委員會有關，精神一振。然而它們之間並沒有什麼關係。
作為一名初級工程師，怎麼才能做得更好呢？誰可以引導你？高階工程師也同樣在邊學邊做。我們也困在其中，只能疲於跟上潮流，維持工作。
所以你放棄抵抗：選擇了 Gihub 上 Star 數最多，投票最多的專案。這就是為什麼 JavaScript 是由潮流和炒作驅動的。
應該做些什麼？
和那些天生愛抱怨的人一樣，我更擅長抱怨問題，而不是解決問題。但我有一些想法：
謹慎對待 Medium
Medium 鼓勵了一些標題黨，使得我們很難辨別權威內容。傳統部落格允許優秀作者建立獨特的部落格主題，有助於讀者識別之前有過幫助的內容源。
謹慎對待 “自我提升”
過去幾年裡看到了 JavaScript 領域中更積極的自我推銷，這可能與線上付費內容的增加與作為 Github “網紅” 進行就業/諮詢的優勢有關。對於那些為優秀內容付費並感到滿意的人來說這沒有任何問題，但是越來越多的人遇到了虛假策略：自我引證，發明專有術語（所以搜尋引擎會將你帶回作者的文章）以及名稱冒用（如 “Standard.js”）。
考慮無微型庫（non-microlib）架構
嘗試用提供豐富功能特性並且無需其它外掛來提升效率的框架來啟動專案，這將立即減少模組變動和意想不到的變更。這也是我對 Vue.js 感興趣的原因之一。你也可以像 Next 一樣使用 React 作為初學者工具箱或更大型框架的一部分。
不要過分焦慮就業問題
唯一需要在報到當天就全盤瞭解公司內外技術棧的是外包人員，他們可以在公司外完成專案，獲得可觀的薪酬。除此之外，大多數老闆並不在意你不瞭解最新 React 輔助庫的來龍去脈。因此，不必理會那些需要學習一切內容的呼籲，其中大多數都是噪音。
註釋
[1] 這一想法有很多很多錯誤。
[2] 你敢信 Express 需要一箇中介軟體才能解析 JSON 格式的 POST 請求？抱歉，Express 就是這麼為所欲為。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。