從後端到前端的轉變：如何選擇框架？

從後端到前端的轉變：如何選擇框架？

做者｜Mike Taylor
譯者｜薛命燈
單頁面應用程序（SPA）的異步 JavaScript 爲改善 Web 應用程序的用戶體驗提供了絕佳的機會。CSS 框架（如 Bootstrap）使得開發人員可以在處理結構和行爲時快速提供樣式。
惋惜的是，SPA 和 CSS 框架提供的解決方案都相對複雜，傳統上分離的關注點（如 HTML 結構、CSS 風格和 JS 行爲）被理所固然地混合在一塊兒，這與前幾代人吸收的教訓背道而馳。
這種關注點的混合可能會阻礙入門級開發人員和有價值的專家（例如視覺設計、可訪問性、搜索引擎優化和國際化）對項目作出有意義的貢獻。
除了讓少數可以處理全部這些問題的開發人員的成本不斷增長以外，它還可能給其餘現實世界的業務帶來影響，例如訴訟、零增加、沒法轉向、錯失機會、招聘和人員配置問題。
當可維護性問題浮出水面時，一個看似謹慎的技術決策也可能會致使長期的成本。
出現這種趨勢的潛在緣由是傳統後端開發人員向前端轉型與 Web 應用程序從服務器端到客戶端轉變相吻合。爲了彌補本身的不足，這些新進入者引入知足自身需求的工具和實踐，但沒有考慮到整個組織。
若是你只須要 CSS 框架提供的前期價值，建議你不要直接將它們加入到應用程序中。相反，能夠將它們做爲爲特定業務語言而設計的內部 CSS 框架的裝飾器。
在 SPA 框架方面，建議採用強制分離關注點的編碼實踐。這個目標能夠經過 React 來實現，但 Vue.js 提供了一種更好的方法，能夠與傳統的前端開發人員進行更好的協做。

序幕

2014 年，我進入了不列顛哥倫比亞理工學院（BCIT）的網頁設計專業。完成學業後，我被學校找去給他們的在線學習課程幫忙。當他們告訴我可使用 Twitter 的 CSS 框架 Bootstrap 時，我很是興奮......
但這種興奮感很快就消失了。在用了它以後，我不由懷疑爲何咱們必定要用它。隱含的 class 名稱和<div>標籤的自由使用彷佛將全部邏輯都塞到 HTML 中。很快，隨着其餘職能小組疲於應付新的開銷成本，開始出現抱怨的聲音。
咱們團隊製做的在線課程最終將會交到商業、媒體、護理、建築等非技術導師的手中。若是他們沒法弄明白，就會致電 Ed-Tech Support。若是 Ed-Tech 沒法解決問題，那麼這些工做就會從新回到咱們的手裏。
這是災難性的，由於咱們人手不足。教師們都很緊張，須要支持的問題堆積如山，咱們的團隊成了學生經過課程的瓶頸。

咱們被這些框架的易用性承諾所吸引，但事實證實，這些承諾大都停留在表面。Bootstrap 致使咱們付出不少努力卻沒有得到多少回報。咱們掉入了假裝的維護陷阱。
通過幾個月的掙扎以後，團隊開始着手建立一個基於極簡主義的自定義框架（或者更確切地說是剔除 HTML 全部的複雜性）。一個使用在線學習專用術語構建超級乾淨代碼的解決方案。
咱們最終獲得了一個廣受歡迎的產品，儘管它（和我）今天仍然要承受政治小轟炸。除了徹底消除了維護問題，還提升了整個在線課程的質量和效率。
最重要的是，咱們的團隊再也不是個瓶頸。
從那之後，我對前端工具及其猖獗的擴散變得更加警戒。我擔憂的是，採用這些工具是爲了它們的實現者的利益，而不是爲了整個組織的利益。我不由想：
不少現代前端工具和實踐只是假裝的技術債務嗎？

歷史

異步 JavaScript
2005 年，谷歌推出谷歌地圖，震驚了全球。拖動屏幕，磁貼就會一個接一個進入視野。

對於大多數來講，這是他們第一次體驗 AJAX 的強大力量。這是一個「殺手級應用」，它證實了客戶端應用有潛力提供很是優秀的用戶體驗。這是咱們朝着現代單頁應用程序（SPA）邁進的重要一步。
CSS 框架
2011 年，Twitter 用 Bootstrap 來歡迎咱們加入他們的開發風格。

Bootstrap 是第一個被普遍採用的 CSS 框架，下降了前端開發的門檻。忽然之間，開發服務器端頁面模板的後端開發人員均可以直接將 class 添加到元素上——不須要 CSS。他們得到的能力與傳統前端開發人員至關，甚至超過了後者。

症狀

div
現現在，CSS 框架幾乎無處不在。Bootstrap 彷佛一直保持着至高無上的地位。此外，對 Tailwinds 這種可組合框架的支持也在不斷增加。

SPA 框架比 CSS 框架更加不穩定。Backbone、Knockout 和 Ember 一直佔據了至高無上的地位，直到谷歌 Angular 出現。其餘框架來了又走，沒有一個可以真正提供價值的飛躍，卻都致使了「JavaScript 疲勞」。
而後，Facebook 推出了 React，一個基於可組合組件和快速虛擬 DOM 想法的框架，這就像用馬達和顏料搭樂高積木。
在打開開發者工具以前，一切都很好。在打開以後，你會看到一堆雜亂無章的「div」。

關注點的混合
當向 HTML 標記添加 六、7 個隱藏的 class 被定義爲「樣式化」時，我認爲咱們已經退了一大步。咱們已經超越了表格佈局，但也僅僅比內聯樣式好一些。
如今都鼓勵開發人員將 CSS 直接注入到 HTML 的 style 屬性中。更糟糕的是，這些標籤如今充斥着三元表達式和映射函數，迫使開發人員在 HTML 和 JavaScript 之間來回切換。
對於那些在過去幾年內加入 Web 開發的人來講，這個很不正常。

問題

難以捉摸的忍者
2014 年，前端開發人員的成本明顯低於後端開發人員。5 年後的今天，前端開發變成全棧式的。
你可能已經注意到，崗位描述中的必備技能清單出現了指數級增加。你的優秀員工被挖走，你想要的候選人被其餘公司以更高的工資、更好的福利和更靈活的工做安排所吸引。
但不要誤會個人意思，這對一小部分人來講是件好事，但對於那些想要經營中小型企業（SMB）的人來講多是毀滅性的。
當你的成功策略取決於你招募、訓練和留住明星級人物的能力時，你可能會發現本身在原地打轉。
專業知識的缺失
忍者實際上並不存在。樣樣通，洋洋不精。做爲一名多面手，我很清楚你不可能什麼都很精通。雖然通才會在你的業務中佔有一席之地，但不該該讓他們單獨工做。
若是團隊中的每一個開發人員都是「JavaScript 忍者」，實際上你是在將本身暴露在盲點之下。毫無疑問，應用程序將會充斥着像<div className="btn" onClick={this.handleClick}>這樣的悲慘實例。
你可能會說：「誰在意呢，只要能運行就能夠了」。對於身體健全的人來講可能沒什麼問題，但那些須要依賴輔助技術的人將徹底沒法訪問你的部分應用程序。
若是你沒有道德上的強迫，也許會受到金錢的驅使。你須要認真考慮這樣的一個事實：可訪問性（A11Y）的疏忽實際上表明着巨大的經濟風險，不管是在失去商業機會方面，仍是在遭到訴訟威脅方面。
此外，由於急於讓應用程序可運行，JavaScript 專家可能會忽略了進行搜索引擎優化（SEO）。這可能會形成很大的傷害，由於持續不斷地燒錢可能對任何形成致命打擊。若是產品沒有吸引力，產品的質量再好都沒有用。
敏捷的喪失
像 Bootstrap 和 React 這樣的框架很吸引人，由於它們提供了使人難以置信的前期速度。Bootstrap 一般被認爲是一種優秀的原型設計工具。不過原型工具天生就能帶來低成本、低保真度的產品。

甚至「bootstrap」這個詞也成了使用有限資源的代名詞。在「good-fast-cheap」的模式中，你選擇了 fast 和 cheap——不管這些決定是不是有意識的。換句話說，你選擇投資一個充滿技術債務的產品。
不相信我說的？考慮一下將來你的造型開始變得過期的狀況。新的競爭帶來了更吸引人的用戶體驗，是時候升級你的遊戲了，不然你將地位不保。

你開始進行品牌重塑，調整 Bootstrap 無窮無盡的變量列表。通過一陣的折騰，卻發現你所但願的改變只有在讓輪換全部開發人員以後才能保持一致。
此外，你真正想要的深度定製涉及構建複雜的 CSS 特性，以覆蓋 Bootstrap 對選擇器的自由使用。
你想要修改佈局，但發現每一個組件都使用 col 類進行硬編碼。可悲的是，每一個元素都在以不一樣的屏幕分辨率爭奪空間。一個變動須要其餘五個甚至更多的地方也作出修改。
這並無那麼糟糕，除非作出每一個變動都須要深刻到不可讀的結構、樣式和行爲代碼中，這些代碼都在 render 函數中，而這些函數要在每一個組件文件的末尾才能找到……
幾個月後，在喝了 10 磅咖啡以後，你爲再次加入競爭作好了準備（但其實那不是真的）……
若是你的目標是短時間收購，你可能會不在意。但請記住，技術的靈活性和敏捷性就是力量。若是產品的長期願景是一臺緩慢傾斜的機器，你可能會發現本身在談判桌上處於下風。
問題的影響
在飆升的勞動力成本、訴訟風險、錯失的商業機會、有限的客戶獲取以及沒法迅速掌控局面之間，看似微不足道甚至明智的技術決策忽然之間對現實世界的商業產生了影響。
對於正在處理某些類型應用程序的一些企業來講，我所討論的一切都在徹底掌控之中。然而，其餘致力於其餘類型應用程序的企業可能會盲目陷入長期的承諾和高維護的噩夢之中。
請記住，與開發相比，軟件將在維護中度過大部分時間。經過快速搜索，我找到了如下有關維護成本分配的經驗法則：

• 年度維護 = 初始支出的 15-20％；
• 終身維護 = 總支出的 40-80％（平均 60％）。
  如下是一個 10 年期的成本投入狀況，初始投入 100 美圓，年度維護費用爲 20%：
  
  如你所見，維護成本僅用了 5 年就超過了開發階段。在第 7 到第 8 年間超過了 60％的總成本閾值。
  固然，這只是一種簡化的成本示例。最有可能的狀況是，在應用程序的整個生命週期中，項目越大，維護起來就越困難。從長遠來看，短時間目標可能致使長期後果，這種後果只會隨着時間的推移而複雜化。
  我也想知道如何將這些不可維護的項目排除在這些規則以外，由於維護成本變得如此之高，以致於項目直接以失敗了結，並被拋棄……

  根本緣由

  我相信，從服務器端到客戶端應用程序的重大轉變，將大量有才華的開發人員從後端拉到了前端。因爲優點和劣勢的不一樣，這些程序員開始改變前端的開發方式。
  固然，這只是一個假設，但我認爲下面這個圖表有助於解釋咱們正處在一個惡性循環之中：
  
  你可能已經注意到圖中使用了引號，這是有緣由的。「Highly skilled」只是相對於其餘開發人員引入前端工具能力而言的，「Complexity」是相對於被解決的問題而言的，「Low skilled」是相對於目前在生產環境中使用的工具的複雜性而言的。
  咱們能夠合理地假設「Highly skilled」開發人員正在引入工具來彌補他們在前端方面的不足，而不是加強整個組織的能力。例如，從使用 CSS 框架中獲益最多的人是維護 CSS 能力最差的人。
  我常常從 Bootstrap 支持者口中聽到的一句話是「建立一個漂亮的原型是多麼容易」。一樣，React 的支持者會說：「永遠不離開 JavaScript，我喜歡這種感受。」
  若是這些狀況在你的組織中很常見，那麼你的技術棧可能更多的是爲傳統後端開發人員的需求而設計的，而這些開發人員剛好在前端工做。
  我曾經目擊過一場關於基礎設施解決方案的激烈辯論，其中一方指出：
  「爲了讓瑣碎的任務變得更加容易，反而讓簡單的任務變得更加困難。」
  當我看到咱們的團隊試圖使用 Bootstrap 和其餘替代方案解決問題時，我反而以爲沒有這個必要。在我看來，他們試圖使用笨拙的解決方案來規避微不足道的問題。對於這些工具的支持者來講，他們好像在爲嚴峻的挑戰提供解決方案。

  解決方案

  CSS 框架
  爲了減小對 Bootstrap 等框架的依賴，個人建議是中止將特定於框架的類直接應用於 HTML。相反，我會鼓勵下面這樣的作法：

  %our-warning-button {
  @extend .btn;
  @extend .btn-warning;
  }
  .empty-shopping-cart-button {
  @extend %our-warning-button;
  }

  這種方法有助於將應用程序與 CSS 框架分離，能夠將它們視爲內部 CSS 框架的「裝飾器」。你如今能夠輕鬆地替換框架、覆蓋樣式，甚至能夠在不犧牲前期速度的狀況下發布本身的代碼。
  集中樣式的能力意味着 UI 設計人員能夠處理 CSS，不須要陷入組件的迷宮之中。經過使用領域特定語言，還能夠與整個組織內的非技術團隊成員和利益相關者進行更好的溝通。
  最後（也是最重要的），你在結構和風格之間有了分離的關注點。
  SPA 框架
  這可能具備爭議的，感受就像一個使人難以置信的長期騙局，但我建議從 React 切換到 Vue.js，緣由是：

  <template>
  <!--Structure-->
  </template>
  <script>
  <!--Behaviour-->
  </script>
  <style>
  <!--Style-->
  </style>

  你在這裏看到的是 Vue 的「單文件組件」，它鼓勵對關注點進行分離。我很是喜歡 Vue（以及它對簡約性的承諾）。
  我認爲使用 Vue 有一個很是強大的商業理由，由於它下降了非 JavaScript 開發人員參與貢獻的門檻。除了專業技能的價值，還會釋放出忍者們在其餘方面的專長。
  不要誤會個人意思，Vue 具備 React 等框架的全部特徵。它很是靈活，可讓你創造任何你喜歡的項目。相似地，React 的實現方式更加容易掌握（雖然遠不到 Vue 那樣的程度）。
  總的來講，個人建議採用強制分離關注點的編碼實踐。簡化成一套簡單的規則：
  1.切勿在模板中放入任何不直接引用預先計算的數據、方法或組件的內容。
  2.僅經過本身設計的類應用樣式，並不惜一切代價地避免使用 style 屬性。
  如上所述，再加上將代碼庫劃分爲智能組件和非智能組件，應該能夠保持 HTML 足夠的邏輯和樣式自由。它可能會消除一些捷徑，但長期的可維護性收益能夠補償前期的成本。
  英文原文：
  https://hackernoon.com/the-backendification-of-frontend-development-62f218a773d4