從後端到前端的轉變：如何選擇框架？
單頁面應用程式（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 標記新增 6、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
更多內容，請關注前端之巔。
