CSS 框架或 CSS 網格：我的項目應該使用什麼？

在我最常被問到的問題中，有各種各樣的問題，“我應該使用 CSS Grid 還是 Bootstrap？” 在這篇文章中，我將看看這個問題。 您會發現使用框架的原因是多種多樣的，而不僅僅是圍繞使用該框架中包含的網格系統。 我希望通過解開這些原因，我可以幫助您做出自己的決定，即最適合您正在開發的站點和應用程序以及與您合作的團隊。

在本文中，當我談論框架時，我描述的是第三方 CSS 框架，例如 Bootstrap 或 Foundation。 您可能會爭辯說這些確實是組件庫，但許多人（包括他們自己的文檔）會將它們描述為一個框架，因此我們將在這裡使用它。 重要的因素是這些是您在外部開發的東西，與您的具體問題無關。 使用第三方框架的替代方案是編寫自己的 CSS——這可能涉及開發自己的內部框架，使用一堆通用文件作為起點，或者將每個項目創建為新事物。 所有這些事情都是根據您自己的特定需求而不是非常通用的需求來完成的。

為什麼選擇 CSS 框架？

使用 Grid 還是框架的問題是有缺陷的，因為 CSS Grid 不是 CSS 框架所做事情的直接替代品。 對該主題的任何探索都需要考慮我們的框架 CSS Grid 將取代什麼。 我想首先找出人們選擇使用 CSS 框架的原因。 所以我轉向推特並發布了這條推文。

一個問題：如果您選擇在項目中使用 CSS 框架（Bootstrap、Foundation 等），這樣做的主要原因是什麼？

— 雷切爾·安德魯 (@rachelandrew)，2018 年 10 月 16 日

有很多回應。 正如我所料，使用框架的理由遠不止它包含的網格系統。

框架為您的團隊提供現成的文檔

如果您正在與許多其他開發人員一起開發一個項目，那麼您創建的任何內部系統都需要包含文檔以幫助您的團隊成員有效地使用它。 創建有用的文檔本身就是一項耗時的、熟練的工作，而且大型框架做得很好。

框架文檔一次又一次地出現，許多經驗豐富的前端開發人員加入並解釋這就是他們推薦和使用 CSS 框架的原因。 我有時會聽到人們使用框架的意見，因為他們並不真正了解 CSS，但是，許多回复的人對我來說都是專業的 CSS 開發人員。 我敢肯定，他們有時會對框架做出的選擇感到沮喪，但是，該選擇的積極方面超過了這一點。

在線社區：輕鬆獲得幫助

當您決定使用特定工具時，您還會獲得一個用戶社區來尋求幫助。 除非您有一個非常明確的 CSS 問題，並且可以生成一個簡化的用例來演示它，否則就 CSS 尋求幫助可能會很困難。 如果您想詢問如何構建某個組件，尤其如此。 使用框架可以為您的問題提供一個起點； 通常，您將詢問如何修改或設置特定組件的樣式，而不是從頭開始。 這是一個更容易問的事情，也是一個更容易回答的事情。

網格系統

儘管我們有 CSS Grid，但許多人回答說他們決定使用框架的主要原因是網格系統。 當然，其中許多項目可能早在 CSS Grid 可用之前就已經開始了。 然而，即使在今天，對向後兼容性或團隊對新佈局方法的理解的擔憂可能會導致人們決定使用框架而不是採用原生 CSS。

項目交付速度

當擁有獨特的設計和高效的 CSS 時，優先級遠低於到期日

— CodingBlocks.net (@CodingBlocks) 2018 年 10 月 16 日

一般來說，選擇一個框架可以更快地交付您的項目，特別是如果該項目非常適合框架做事的方式並且不需要大量定制。

在為新想法開發 MVP 的情況下，框架可能是一個很好的選擇。 您將有很多事情要花時間，並且仍在根據項目需求測試假設。 能夠使用框架開發第一個版本可以幫助您更快地將產品呈現在用戶面前，並節省大量時間來開發您決定不使用的東西。

我會使用任何 MVP 的框架——在工具和框架上的最小開發工作，以優化處理實際概念的時間。

我在任何重做現有大型網站/應用程序的東西上創建自己的 CSS“框架”。

— Ben Bodien (@bbodien) 2018 年 10 月 16 日

另一個速度和一堆現成的組件非常有用的地方是為站點或應用程序開發後端管理系統時。 在您只需要創建幾個管理屏幕的情況下，框架可以節省大量時間來設置表單字段和其他組件的樣式！ Bootstrap 和 Foundation 的儀表板主題甚至可以提供有用的起點。

我不是設計師！

這就是我過去選擇 CSS 框架的原因。 我不是設計師，如果我必須同時設計和構建某些東西，我會花很長時間嘗試做出我完全沒有資格做出的設計決策。 有資金為每個副項目聘請設計師會很不錯，但是，我沒有，因此框架可能意味著交付與不交付之間的區別。

處理 CSS 錯誤和瀏覽器兼容性問題

提到的比我想像的要少，可能是框架作者已經處理了瀏覽器問題，這是由於實際的錯誤或缺乏對某些功能的支持。 然而，這仍然是許多人做出決定的一個因素。

幫助響應式設計

網頁的響應性。 我發現我很難為網頁決定斷點。

——費薩爾·阿里 (@f_a_akhtar) 2018 年 10 月 18 日

這齣現了幾次； 人們之所以選擇一個框架，是因為它具有響應性，或者我為他們做出了關於斷點的決定。 我認為有趣的是，這特別是選擇使用框架的一個因素。

為什麼不使用框架？

選擇框架的積極原因之一是人們在選擇時遇到的一些問題。

覆蓋框架代碼的難度

許多人評論說，覆蓋框架中使用的代碼可能變得很困難，如果框架不需要大量覆蓋，框架是一個不錯的選擇。 如果有大量的自定義設置，那麼易用性的好處以及團隊中了解如何使用框架的每個人都可能會失去。

所有網站最終看起來都一樣

所有網站開始看起來都一樣的責任已經直接歸咎於眾所周知的 CSS 框架。 我看過一些網站，我確信使用了某個框架，然後發現它們是自定義 CSS，因此在這些框架中做出的設計選擇非常普遍。

覆蓋已經提到的框架樣式的困難是使用特定框架開發的網站看起來相似的很大一部分原因。 這不僅僅是一個創造性的問題，作為一些網站的用戶，這些網站都選擇了相同的框架，卻覺得它們都是一樣的，這可能會很奇怪。 在傳達你的品牌，並讓良好的用戶體驗成為其中的一部分時，在選擇框架的通用選擇時，你可能會失去一些東西。

繼承整個世界的 CSS 問題

無論是前端還是後端，任何尋求成為主流的工具或框架都必須解決盡可能多的問題。 除非該工具與解決一個特定用例緊密耦合，否則它將包含許多非常通用的代碼，以及解決您沒有並且永遠不會遇到的問題的代碼。

您可能很幸運，只需要在最新的瀏覽器中查看您的完整體驗，從而在 Internet Explorer 或舊版 Chrome 中獲得更有限的體驗。 使用具有大量內置支持（可追溯到 IE9）的框架會導致大量額外代碼——尤其是考慮到最近 CSS 佈局的改進。 它也可能會阻止您發揮創造力，因為框架中的所有內容都假定了這種支持要求。 使用 CSS 可能的事情可能會受到框架的限制。

例如，流行框架中的網格系統沒有跨行的能力，因為在網格佈局之前的佈局系統中沒有任何概念或行。 CSS 網格佈局很容易做到這一點。 如果您被綁定到 Bootstrap Grid 並且您的設計師提出了一個包含跨行元素的設計，那麼您將無法實現它——儘管您的目標瀏覽器可能支持 Grid。

性能問題

與上述相關的是使用相當通用的代碼所固有的性能問題，而不是針對您擁有的確切用例進行優化的東西。 在嘗試提高性能時，您會發現自己與框架的決定發生了衝突。

技術債務增加

主要是速度，儘管我們很快發現它有點虛假經濟，因為從長遠來看它會產生大量的技術債務。

— Tim Cthulhuegdon (@nefarioustim) 2018 年 10 月 16 日

雖然框架可能是讓您的初創公司快速起步的好方法，並且在做出決定時您確定會替換它，但是否有計劃實現這一目標？

學習框架而不是學習 CSS

在與會議和研討會與會者交談時，我發現許多人只使用過框架來編寫 CSS。 鑑於當今 Web 平台的複雜性，我想這將是許多人的途徑，通過這些工具之一進入 Web 開發並沒有錯。 但是，它可能會成為限制職業生涯的選擇，尤其是當您基於技能的框架失寵時。

沒有 CSS 知識的前端開發人員應該讓公司擔心。 如果您的團隊實際上不了解如何在沒有它的情況下使用 CSS，那麼離開該框架將變得非常困難。 雖然這並不是不使用框架的真正理由，但在使用框架時要牢記這一點。 當離開的那一天到來時，您會希望團隊準備好接受新事物，而不需要記住（或第一次學習）如何編寫 CSS！

選擇不考慮最終用戶

Nicole Sullivan 在我提出問題的前幾天問了幾乎相同的問題，因為我正在考慮寫這篇文章，儘管她正在考慮將前端框架作為一個整體而不僅僅是 CSS 框架。 Jeremy Keith 指出，與最終用戶有關的答案恰好為零。 對我的問題的回答也是如此。

在我們快速建立網站的競賽中，作為網站的設計者和開發者，我們希望為自己創造盡可能好的東西，我們是否忘記了我們這樣做是為了誰？ 框架開發人員做出的決定是否與您正在構建的站點用戶的需求相匹配？

我們可以用“Vanilla” CSS 替換框架嗎？

如果您正在考慮更換您的框架或開始一個沒有框架的新項目，您可以考慮哪些事情來簡化該過程？

了解您需要框架的哪些部分

如果您要使用自己的 CSS 替換框架的使用，一個好的起點是審核您對當前框架的使用。 弄清楚你正在使用什麼以及為什麼。 考慮如何在新設計中替換這些東西。

在考慮是選擇框架還是編寫自己的框架時，您可以遵循類似的過程。 您可以合理地期望這其中的哪些部分需要？ 它在多大程度上符合您的要求？ 您是否會導入大量代碼，可能會要求訪問者下載但從不使用？

創建文檔化模式庫或樣式指南

我非常喜歡使用模式庫，您可以在 Smashing Magazine 上閱讀我關於我們使用 Fractal 的帖子。 模式庫或樣式指南可以創建文檔以及所有組件。 我的所有項目都是從模式庫中的 CSS 開始的。

作為編寫文檔的人，您仍然需要編寫文檔，但是，我知道通常最難的事情是知道從哪裡開始以及如何構建文檔。 模式庫通過將文檔與組件本身的 CSS 一起保存來幫助解決此問題。 這種方法還可以幫助防止文檔過時，因為它們與所引用的組件緊密相關。

開發自己的 CSS 代碼指南

整個團隊的一致性非常有用，如果沒有框架，可能沒有任何東西可以規定這一點。 特別是對於較新的佈局方法，通常有幾種方法可以構建模式，如果每個人都選擇不同的方法，那麼可能會出現不一致。

更好的尋求幫助的地方

除了向 Stack Overflow 方向派人外，似乎很少有地方可以在 CSS 上尋求幫助。 特別是對於初學者來說似乎很少有地方可以接近。 如果我們要鼓勵人們遠離第三方工具，那麼我們需要滿足對來自這些工具周圍社區的友好、有用的支持的需求。

在公司內部，更有經驗的開發人員有可能成為新團隊成員的 CSS 支持。 如果從框架轉向您自己的解決方案，明智的做法是考慮可能需要哪些培訓來幫助彌合差距，尤其是當人們過去需要幫助時習慣於使用第三方工具提供的幫助時.

非設計師的風格指南或起點

我糾結於諸如“我應該使用哪種字體？”、“標題與正文的關係應該有多大？”、“可以使用陰影嗎？”之類的問題。 我可以輕鬆地編寫 CSS — 如果我知道我要做什麼！ 我真正需要的是一些規則來製作一個不可怕的設計，某種排版起點，或者一組基本指南將取代在很多情況下能夠使用框架的默認值。

教育人們了解現代瀏覽器互操作性的現狀

我發現，多年來一直沉浸在基於框架的開發中的人，通常對瀏覽器互操作性的看法已經過時了。 在 CSS 跨瀏覽器工作方面，我們的情況從未像現在這樣好。 可能是某些瀏覽器不支持一種新的閃亮的 CSS，但總的來說，CSS（當支持時）不會充滿奇怪的錯誤。 例如，在幾乎所有情況下，如果您在一個瀏覽器中使用 CSS Grid，您的 CSS 將在另一個瀏覽器中以完全相同的方式工作。

如果試圖向那些相信框架可以使他們免於瀏覽器錯誤的團隊成員證明不使用框架的理由，那麼這一點可能是一個有用的問題。 瀏覽器兼容性問題是真實存在的，還是基於過去的擔憂？

我們會看到一種新的框架嗎？

讓我感興趣的是我們的新佈局方法是否有助於引入一種新的工具和框架。 我們是否會看到利用新佈局方法的工具，允許更多的創造力，但仍然給團隊和個人一些不可否認的優勢，這些優勢來自對我的推文的回應。

也許通過依賴新的佈局方法，而不是內置的網格系統，新式框架可以輕得多，成為有用組件的集合。 然後它可能能夠擺脫非常通用代碼中固有的一些性能問題。

框架可以幫助的一個領域是幫助為不支持更新佈局方法的瀏覽器創建可靠的後備，或者通過將真正可靠的可訪問性嵌入到組件中。 這可能有助於為考慮互操作性和可訪問性的工作方式提供指導，即使對於那些沒有將這些事情放在首位的人也是如此。

我認為簡單地將 Bootstrap Grid 切換為 CSS Grid Layout 並不能實現這一點。 相反，提出新框架的作者也許應該看看這裡列出的一些原因，並嘗試以新的方式解決它們，使用我們在 CSS 中的新功能來做到這一點。

你應該使用框架嗎？

您和您的團隊需要自己回答這個問題。 而且，儘管人們可能試圖讓你相信，但沒有普遍的正確或錯誤答案。 您的項目只有正確或錯誤。 我希望這篇文章和對我最初問題的許多回答可以在你思考這個問題時給你一些討論的東西。

請記住，答案會隨著時間而改變。 這可能是一個有用的思想實驗，不僅要考慮您現在需要什麼，首先要為網站進行開發，還要考慮網站的生命週期。 你認為這仍然會在五年內出現嗎？ 那麼你的選擇是積極的還是消極的呢？

記錄您的決定，不要害怕重新審視它們，並確保您和您的團隊在您決定使用的任何框架之外保持您的技能。 這樣，您將處於一個很好的位置，可以在未來繼續前進，並為項目的下一階段做出最佳決策。

我希望在那條推文中開始的對話繼續下去。 在評論中讓我們知道您的故事——他們很可能會幫助其他人試圖找出最適合他們的項目的東西。