[譯] 爲什麼前端開發如此不穩定

時間 2019-11-16

標籤爲什麼前端開發如此不穩定简体版

原文原文鏈接

原文地址：Why is Front-End Development So Unstable?

原文做者：Jimmy Breck-McKye

譯文出自：掘金翻譯計劃

本文永久連接：github.com/xitu/gold-m…

譯者：Colafornia

校對者：geniusq1981 sunhaokk

咱們都知道這樣一個笑話：在你學會一項前端技術的時候，另外三項新技術已經發布了。不只如此，你剛學會的那個也已經被棄用了。javascript

咱們卻不常看到有解釋爲何會這樣。html

典型的解釋（來源於 reddit 的 r/programming 頻道）這彷佛與前端開發者天生不耐煩，追逐流行與能力有限相關，這種解釋構成了一個更廣泛的謬論：假設你所不理解的行爲是由整個羣體的愚蠢，糟糕或貪婪形成的 (而你本身的不明智行爲徹底是由你沒法控制的因素形成的)。前端

不管它是否是謬論，咱們確實有這個問題，對嗎？vue

量化問題

在跑偏以前，咱們有必要肯定這個問題是否真的有現實依據。前端技術真的變化很快嗎？java

從主流受關注（也可能不是）的技術來看，細想一下這個 Github 上「高星」 JavaScript 前端技術排行：android

+------------------------------------------------------------+
| 庫               | 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 年      |
+------------------------------------------------------------+
複製代碼

最年輕的項目已經兩歲半了，雖然並非那麼老，例如，它都不到你的桌面操做系統維護週期的一半長，可是也不是像那個笑話說的那樣。因此是什麼致使人們對前端有了這種更迭快速、甚至不可持續變化的感受呢？ios

React 與它的朋友們

多是 React 形成的。做爲一個強力工具，它須要一系列的輔助模塊和支持庫來支撐，這就是問題所在。React 生態中我稱之爲「微型庫（microlib）架構」的內容很是龐大，其應用是由無數離散的，單一用途的 JavaScript 庫組成，以對 Unix 哲學致敬。git

這一架構的優勢是，當新的實踐出現，你能夠快速適應，這在像幾年前那種快速革新階段很是有用。缺點在於它使你須要常常進行大型迭代，同時也要求你在衆多（每每太多）所謂的微型庫（microlib）中審查挑選。github

這也是我論點的主旨：問題不在於 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」）。