重磅來襲！設計師不應該錯過的響應式設計框架

2022-06-08 分類：網站建設

Ethan Marcotte稱響應式設計是基于網格建立一個網站。Marcotte定義這項技術后，響應式設計框架開始出現，主要是css和JavaScript的結合。許多框架都是開源的，可以免費下載和快速定制。

當下最火熱的框架就是Bootstrap和 Foundation了。

隨著響應式設計框架越來越火，一個巨大的爭議出現了：為什么一個專業的設計師還需要用這些框架呢？

許多人宣稱響應式框架是可怕的，因為他們根本不懂一點點html和css的知識。下面是另一些具有標志性的反對使用框架的意見：

設計師可以寫自己的框架，如果他們懂得一點點html和css的知識的話就更應該自己寫。

基于框架的網站加載非常慢。
基于框架的網站看起來大同小異。
伴隨多余的div標簽，5000+行的css后者更多的javascript文件，網站膨脹是常見的。

盡管反對者的抗議很強烈，但是絲毫不影響框架的持續流行。我認為框架是有用的，即使是最有經驗的web前端開發人員也可以好好研究一下。下面我將說說我支持框架的原因。

Paul-rand

一、響應式設計框架

一天早上，我正在看 Eli White在 Northeast PHP Conference上的的關鍵演示，他是譯文PHP開發人員，他所談到的是web和PHP在過去20年的發展。他說道一點：在15年前，后臺開發者構建一切東西都是從零開始的。那個時候沒有多少可用的開源資源，也沒有專門的內容管理系統（CMS）或者數十萬美元的成本。如果你想要為你的網站做一個概觀，那么你需要從頭自己編寫一個。

而如今在2014年，后臺開發者不再這樣做了。現在他們可以用SurveyMonkey的API在10個小時內為用戶創建內容，已經不再是100或者1000小時了。是SurveyMonkey的代碼比較可怕嗎？它們是高效、最巧妙的嗎？我不是一個PHP開發者，我不知道這個問題的答案，但是這個API不斷被測試和debug，它運行良好，早就可以拿來用在你其他的項目上，這就是它的價值所在。

White說道，除非你的客戶想要的東西非常的特殊并且有足夠的資金支持，不然大多數的PHP開發人員沒有理由在2014年還親手從頭編寫自己的概觀。

So~有什么可以等價于快捷的網站前端技術呢？不幸的是我們沒有。

目前我們有兩個選擇來創建一個網站前臺。第一個選擇是下載一個主題（或者模板）。通常都是用于基于CMS的網站，一套主題可能會提供一些顏色的選擇和一些變量的調整。另外一方面，相對于整個網站的成本來說，一套主題大多數都是免費的或者是低成本的。下載一套主題，改一下顏色換一個logo是非常簡單的事情。

更重要的是，一套好的主題是會定期更新的。并且會附帶說明文檔使修改顯得很直觀容易。在消極方面呢，一套主題可能會被很多人使用，看起來并不是非常的新穎獨特，更像是屬于特定的內容管理系統。

另外一個選擇就是自主完全定制解決方案。需要雇請設計師來討論品牌方案，他們會經歷再三設計和多次修改，或許會直接把原型實現到瀏覽器上，或者把設計稿用html和css實現到網站上，使用CMS集成設計，考慮要不要使用后臺管理，最后交付給客戶好的成品。另一方面，每個標簽都被精確放置，和代碼是完全互相輝映的，沒有絲毫的冗余標簽。

但是，為了實現這一點，開發者們必須做到訓練有素經驗豐富。一旦這樣高水準的成員加入進來，項目價格就會直線上升，項目已經從小客戶目標移位到大客戶目標，成本高升。此外，除非花費額外的費用在寫文檔上，不然一旦初始成員離開，那么新來的成員就必須從新看一遍老成員的代碼，做到熟悉，然后修改，這又是不小的成本了。

在哪里可以下載一個介于低端設計、遍布互聯網和高級定制、無比昂貴之間的東西嗎？相當于一個后臺開發者的API或者代碼庫的東西？我們可以創建出某種專為前端而定制的東西嗎？

我們需要能夠利用一些預先寫好的元素，將他們添加到定制專欄，并開發一個定制的解決方案這就是介于低端和高端之間的產物。我們不再需要從零開始構建框架，我們可以節省好幾個小時呢！

我是在說我們應該拋棄定制解決方案的框架嗎？不，當然不是。在web開發的世界里，一個完整的定制解決方案已然存在，就好比CMS的存在一樣，各有各的用武之地。如果你的客戶有時間和金錢來構建出最好的效果，那么何樂而不為呢？

但是要知道客戶一般都是沒有足夠的資金和時間來等你從頭構造。或許“不好”是允許存在的，或許需要下載的代碼會稍微冗長一些，然而這個解決方案會被記錄下來，并在開發的時候起到很積極的作用。它可以快速產出一個并不低級的產物，這是值得的。

在web世界里，其他技術在處理響應式設計方面有自己的優勢與不足，所以我們大可以好好考慮一下這個框架。

Grk

二、響應式設計框架的優缺點

聚焦Bootstrap 3和Foundation 5，讓我們一起來分析使用其中一種框架構建自己的網站的優勢與短板。

瀏覽器兼容性

瀏覽器調試所花的時間有時趕上了制作網站本身所花的時間。如果你可以減少調試瀏覽器所花的時間，那么就是在為客戶節約成本（當然也是在保護的你的頭發不那么早就掉光）。

響應式設計框架是一個基于在各種瀏覽器調試成功的框架。使用這些框架，可以大大減少建設網站時所耗費的時間（測試次數的多少取決于你定制了多少框架的內容，如果你僅僅只是改變了幾個顏色而已，那么調試的次數就非常少；如果你把框架的網格系統改來改去，那么你就需要多番調試）。

最新的框架支持IE9及以上瀏覽器版本。在IE8上使用框架有一點點小技巧，但是框架完全不兼容于IE6和IE7。一般情況下，框架還支持其他瀏覽器，比如Firefox、Safari和Chrome，以及移動端瀏覽器。

不幸的是，如果你想要把框架應用在還沒被調試過的瀏覽器上，那么你需要自行花時間來修改代碼做測試。

自定義文件

Bootstrap或Foundation的下載包里面都含有最基本的網站構建文件，包括富有風格的圖標和小部件。一些文件會比較大。一般來說文件都是可讀的經過壓縮的文件格式。

由于你所選的每個框架都是集大成的框架，所以介于你不需要完全使用整個框架的所有元素，Bootstra或Foundation允許你自定義下載自己需要的部分。所以你完全可以僅僅托用你需要的css和javascript文件包用在你的web上。這樣就減輕了文件膨脹，并且也減少了下載時間，同時效果是（與你下載了整個框架包所用的效果）一樣的。

但是，如果你想要添加一個之前被排除在外的小部件或者風格，現在你就得重新配置包。不過這完全是可以避免的。我建議首先以建立網站為首，不要去考慮外觀。首先定制自己需要的特性，然后再來下載那些僅包含特定特性的包，一旦框架就位，你就可以開始定制網站的外觀了。

注意：每當新版本的Bootstrap 或Foundation發布，你就得重新下載定制包。仔細記錄下你所采用的和沒有采用的文件，這樣在文件更新時就不需要重復這個步驟了。

CMS Critic

自定義代碼

可能需要某種程度的自定義，框架不是下載下來就可以立即上線使用的。你可能會想要改變一些顏色。而如果你有一定的經驗，或許你會直接攻克網格系統。

自定義代碼僅僅是因為你使用一個框架并不是為了使你的網站顯得很大眾化。你可以自定義css來改善你的網站外觀。要么引用LESS (Bootstrap) 或者Sass (Foundation)，要么直接自己寫都行。

來自Bootstrap框架里的盒子樣式是非常寬泛的。這里的假設就是你根本不會改變它們。所以你可以在一個單獨的樣式表里面引用LESS或Sass文件來覆蓋它們。不幸的是LESS和Sass文件也是極小的，你需要額外的補充自己的代碼。Bootstrap豐富的內置風格使它很受前端開發人員的歡迎。

Foundation有少量的風格基礎。你也自定義一個樣式表來覆蓋它們、引用外部樣式表，看起來完全自定義一個樣式表會更加容易。總的來說在Foundation方面，沒有一定基礎的開發者會比較難以駕馭這個框架，因為它需要你首先掌握比駕馭Bootstrap需要更多的CSS 和Sass的知識。

Bootstrap和Foundation，可以在下載之前就被自定義，盡管需要簡單改變一些LESS和 Sass。在Bootstrap里面，自定義選項用了幾個頁面來展示（與此相反，Foundation僅僅只是一點點的改變）。但是如果你對LESS和 Sass不熟悉的話，這就顯得比較快捷但是比較骯臟。

同樣的，你也可以通過定義javascript來定義功能。最新版本的Bootstrap和Foundation都支持使用jQuery來自定義部件。

如果你使用專門的屏幕來引用框架，那么在下次框架更新時，你還需要另外再自定義一次。

請留意Foundation擁有許多javascript分號，但是Bootstrap只有少量，這回影響開發人員的一個選擇。

可訪問性

可訪問性對于開發者來說已經變得越來越重要了。這兩個框架都有有效地HTML，但是我們有必要比較一下在HTML之外這兩個框架的可訪問性。

Bootstrap在 Joomla的幫助下取得了一定的進步。Joomla是一個開源的CMS，把Bootstrap引向了第3版本。Joomla的開發人員在它的可訪問性方面做了很長的探討，他們不希望Bootstrap減少CMS的可訪問性，所以他們引用了ARIA規范和screen reader-only風格。

Foundation比較不幸的是到目前為止都還沒有優先考慮可訪問性。它不引用ARIA規范和screen reader-only風格。不過Zurb已經表示Foundation會做到更多。

Webflow

三、總結

沒有一個響應式框架是好的。作為一個執行各種任務的工具，需要額外的代碼來使這個框架響應我們的需求。當然，完全自定義一個網站或許會比使用一個框架更加有效。

一些前端開發人員告訴我他們有自己的網格系統、css和javascript組件來維護自己的網站。當然這樣的方法沒什么錯誤可言，但是這樣做你就需要維護自己的代碼。而一個流行的框架可以減少你的維護成本。

我呼吁我的前端開發者重新考慮使用響應式設計框架的前景。把它當做一個生產力工具，你可以使用其中的一部分，甚至是全部。下載部分文件或者所有，使用僅僅一個原型或者所有，總之你知道用在你的項目上你需要使用多少。

一個框架旨在使網站在最少調試的情況下運行得很快。自定義它的過程是完全不同的，或許你會改變少量顏色或者其他。但是無論何種自定義，你都需要做到規范定義，一切做到標準化，記錄下代碼，做到可以很容易就傳遞給另一個開發人員并被他所熟悉。代碼當然不是好的，但是已經很好了。它大大降低了我們開發一個網站所需要的時間。

這個世界當然有完全定制的空間。我的意思并不是支持大規模定制。當客戶想要在設計里面添加更多的內容時就有必要考慮一個響應式框架了。總的來說它是一個非常好用的工具。在快速原型實現、測試甚至是生產代碼方面都能夠讓你的客戶滿意。

當前名稱：重磅來襲！設計師不應該錯過的響應式設計框架
本文網址：http://www.js-pz168.com/news13/165163.html

成都網站建設公司_創新互聯，為您提供網站維護、網站改版、云服務器、面包屑導航、網站導航、網站內鏈