如何評價 React 實現的前端 UI 庫 material-ui？

01-21

作為 star 數超高的一個 react ui 庫，你對 http://material-ui.com/ 有如何評價？
題主：感覺樓下都歪樓了，不是評價 Material Design 設計，是這個 React 的 UI 實現。

有關 Material Design 的 UI 庫我用過一些，在用 Material-UI 之前用的是 Google 官方的 Material Design Lite，這是一個純前端庫，非 React 庫。

在我用過的庫里 Material-UI 還是不錯的，可以滿足簡單需求。其定位是 Material Design 標準組件的實現（而不是 Material Design 的實現），所以如果你需要一些更個性化的組件或交互，就要自己想辦法「組合」或者自造了。

這個問題在移動端不突出，但對 web 端來說有點明顯。畢竟 Material Design 首先是一套視覺設計規範。真正要用好 Material Design，不能簡單套用組件樣式，而是要學習其「Design」。

這個問題我覺得目前還是挺普遍的，多少號稱 Material Design 的網站基本就是擺一個導航欄，右下角一個 FAB，主界麵攤一堆卡片了事。即使說不上丑，也只能評價為「簡陋」。反觀 Google 就有很多運用 Material Design 做得非常漂亮的網站，每次看的時候都會想，「啊，原來還可以這樣」。

所以我現在基本是在一些生存期不長，樣式基礎，交互簡單的獨立頁面上用 Material-UI。更正式一些的產品還是需要好好做設計的——好好做 Material Design 的設計。

如果目標是拿一套現成庫來做出東西，不在設計上投入，那你最好先仔細評估一下 Material-UI 提供的組件是否能滿足你的需要，如果是，那麼請放心大膽地用。如果答案不是確定的，建議還是去看看 Bootstrap 或 Semantic UI 或 Ant Design（後台系統推薦）。

從實現 Material Design 標準組件這個角度來說，Material-UI 毫無疑問是成熟可靠的（不過也有一些瑕疵，比如其 GridList 的實現就很有問題）。但請把 Material Design 的標準組件看作 Microsoft Word 中的五號宋體——只能作為起點。目前幾乎所有的 Material 庫，都是這個定位。

當初對比過一些Material前端框架或者CSS庫，有些還是基於bootstrap的。包括研究谷歌官方的MD頁面等。

都沒有這個material-ui給人震撼的感覺。這個真的是太強了，幾乎和安卓的界面/規範是一樣的。

谷歌的一些MD風格的頁面都沒它的效果震撼，例如：Youtube Gaming

當初就是僅僅因為這個UI庫所以接觸的React，因為它太突出了甩了其他的MD風格前端框架一大截。

但是它的缺點也明顯... 它太重了，列表數據項稍微多的時候載入很卡。

不過這個用來當React的學習和實驗輔助項目，真的是太適合了。

非常厲害，做一些功能為主，不需要過多品牌調性的 WebApp

只需要前端+交互就可以快速構建做出非常不錯的產品

（icon還是有點點難度，有設計比較專業的人員跟著做產品的質量會更加「產品級」一些）

框架用了很多 MD 的視覺元素，但是還是只是「看著像」，交互，動畫世界觀之類的實現距離最理想的 MD 還是有差距，不過基本感覺可以忽略不計。

非要挑刺的話，就是 Menu 部分的動畫設計感覺有點粗糙，做得不夠好（MD 的世界觀，所有東西的誕生都是「擴散」出來，而不是「縮放」出來的，還有就是先「慢_快」的緩動做得還是差一點點）

不過一考慮到「快速構建」這種定位……還要什麼自行車！

Material UI 源碼很多地方比較偏激，但是亮點和優化非常明顯

偏激：比如通篇樣式使用style和context(個人感覺用styled-components似乎是更好的選擇)

亮點優化：比如很小的細節優化，Overlay里利用了css的willChange，RenderToLayer unstable_renderSubtreeIntoContainer 掛在到domtree 放到body後面解決z-index 等等問題，很用心很細心。

反正是一款很值得尊敬和學習的優秀UI庫

早就用著啦！不過話說回來，這麼多 Material Design 的 UI 設計難道看多了不覺得審美疲勞么？

隨便給大家秀一秀我壓箱底所收藏的 React UI 組件大集合吧：

TouchstoneJS - React.js powered UI framework for developing beautiful hybrid mobile apps.

Elemental UI

RSuite | 一個基於 React.js 的 Web 組件庫

Ant Design of React - Ant Design

Material-UI

React-Bootstrap

React + Foundation · Foundation as React components

Essence - React Material Design Framework

React-MDL: React Components for Material Design Lite

Belle - Configurable React Components with great UX

MUI - Material Design CSS Framework

Grommet

React Toolbox

react-blazecss 0.4.3 Demo

Pivotal UI: Intro

BFD UI

排名不分先後，歡迎補充！！！

更加及時的更新請參見：[React UI 組件大集合 · Issue #80](https://github.com/JimmyLv/jimmylv.github.io/issues/80)

適合小團隊，或者個人項目快速搭建前端界面。優點就是快，不需要懂html，css也可以幾個小時可以組合出兼容不同設備的一個完整的ui。比如給運維程序寫個web ui來顯示狀態，做點簡單控制什麼的，很方便。

最大優點是開源免費，不然theme forest上買的模板其實也可以很快修改成組件來用，相對來說，選擇更多，好看很多，只不過要花錢。

用material-ui做過一個中小規模的項目。就直觀感覺來看，對md的還原度真的不錯。從使用上來看，組件質量做得還是很高的，沒遇到什麼bug，寫起來也很順手。當然問題也有：（1）沒有antd那麼多組件，對錶單支持感覺也不是很好。當然原因是md標準也沒那麼多要求。（2）重點是所有的樣式的實現都是行內樣式，所以優先順序什麼的還是會坑下使用者的，

如果你讀過Google的Material設計文檔，你就會發現其對細節和深度的注重。在文檔中你能學到很多東西。其中最為重要的一項，就是其證明了編寫複雜視覺風格指南是完全可能的。儘管可能困難重重，但還是可能的。特別是對於Google複雜多樣的產品組合來說。

如果你想學習視覺設計，就應該認真研究一下Material設計是如何處理不同元素或要素的。Google的文檔詳細介紹了18種不同的設計元素，從按鈕到菜單再到標籤等等等等。那麼，通過分析這些設計元素能給我們帶來哪些收穫呢？

接受變體

文檔中僅按鈕就有很多不同的規則。《素材設計》中介紹了三種不同的按鈕類型：浮動、突起和扁平。在《素材設計》所介紹的各種不同界面中要只使用單一的一種按鈕類型是非常困難的。

同時，要保證各種不同界面之間的一致性也不容易。然而，為了保證最佳設計效果，Material設計採用了三種不同的按鈕類型。其所採用的方法就是將設計改造成有時看似不太好的模式。

「為主要按鈕選擇按鈕類型要取決於按鈕的重要地位、屏幕上的框架數量以及屏幕整體布局情況。」– 按鈕的使用

按鈕方面的部分指南比較具體，還有一部分比較模糊。總而言之，指南思考的非常透徹。指南中就如何使用以及何時不使用按鈕有非常詳盡的說明，以方便設計師開展工作。而這正是這份指南的美妙之處，其將設計的決定權交給了設計師。

注意容易被遺忘的要素

你在設計界面時是否會經常考慮彈窗或提醒模塊？Material設計文檔中有專門介紹對話框的一節。通常來說設計師不會從對話框入手進行設計。但在使用對話框時，它們同樣屬於設計的一個組成部分，需要相應的處理。

指南中有關對話框的部分非常詳盡。其介紹了需要在其中使用的按鈕類型以及相應原因。另外，指南還對對話框的架構進行了解釋，其內容詳實並且透徹。

「如果每個標籤上的文字不超出最大按鈕寬度（例如常用的確定/取消按鈕），那麼推薦使用並排按鈕。」– 對話框

「如果文字標籤超出了最大按鈕寬度，則可以使用層疊按鈕容納文字。」– 對話框

指南中對對話框中應包含哪些類型的內容和操作進行了詳細說明。這部分的介紹非常有趣，同時這也是經常被忽視的一個部分。其介紹道：為了創造出有力的樣式指南和設計語言，所有設計要素沒有大小之分，都非常重要。

一切為了可供性

文檔用很大篇幅強調了可供性。從新創建並統一設計語言的唯一目的，就是為了實現跨瀏覽器/設備的可供性。一份高質量的樣式指南應當將可供性融入設計語言，以求創造出高質量的設計指南。

「標籤的可供性就是顯示相關的內容組。標籤的說明應當簡潔的介紹標籤相關的內容祖。」– 標籤

Material設計文檔中介紹標籤所使用的方式非常精彩。其並不是把標籤視為導航工具的一種形式，而是作為另一種瀏覽內容的方式。標籤欄等特定元素也存在著局限這種觀點非常新穎。顯然，編寫Material設計文檔的設計師不僅考慮到了樣式，還考慮到了元素的功能性，以免其被誤用。

如果不同元素的功能得到了清楚明確的界定，那麼這些元素的使用方式必然也就會被局限。反過來說，這樣將有助於提高可供性。如果某個元素能夠以不同的方式反覆使用，就會給用戶造成誤解。

「標籤可以方便探索和切換應用中不同的視圖或功能區域，或用於瀏覽不同種類的數據集。」– 標籤

打造你自己的元素

「浮窗能夠在移動平台屏幕底部以及台式機左下角以彈窗的形式提供有關操作的少量反饋信息。在屏幕上，他們會覆蓋所有元素，包括浮動的操作按鈕。」- 浮窗和提示欄

「提示欄和浮窗類似，但其中不包含操作內容，因此無法滑出屏幕。」- 浮窗和提示欄

Material設計文檔中有一個很有趣的部分叫做「浮窗和提示欄」。這個設計名詞可能不太常聽見；浮窗和提示欄是我們已經知道的設計元素。如果你讀了下面的註解再看一下下方的圖片，就能夠理解浮窗和提示欄其實就是簡單的彈窗通知。

但文檔裡面的介紹卻非常細緻。Materila設計文檔對彈窗進行了分類。這是其設計語言的需要。浮窗和提示欄類似於對話框但實際卻不同；因此他們是兩個分離的概念。Materila設計文檔將它們區分開的原因是其需要它們執行不同的功能。創建新元素是沒問題的。和Materila設計文檔中其他部分一樣，浮窗和提示欄也有專門的指南——使用、案例、度量和顏色。

通常，我們會忘記這些元素不能以多種或新方式使用。有時候，區分彈窗的兩種不同功能這種簡單的問題也能講出很深的道理，著實有趣。另外，不要忘了你可以加入可能被視為過時的元素，或者你自以為存在實則不然的元素，並以這種方式來革新你的設計。對小玩意的革新能夠給未來的設計帶來巨大的改變。

我很喜歡這個 UI 庫。

持續關注 Material UI 庫，同 @紳士喵，是先關注這個庫然後才接觸 React。

這個庫以前用著的時候都是 0.x 的非正式版。老實說什麼時候會突然不向下兼容也說不定，這個事情在 0.15 左右就發生過一次（以前都是 self-surporting，從0.15.x 開始需要 Theme Provider）。

不過現在 Material UI v1.0.0 已經通過 alpha 並進入了 beta 階段，不過離正式發布可能還需要一些時間。v1.x 相對於 v0.x 又是一個大版本的改變，並不向下兼容，可以說是改動極大。早在 v0.16.x 發布的期間，v1.0.0-alpha.1 第一次發布了。Material UI 的開發任務分成了兩個部分，一方面繼續完善組件，把 v0.16 推到了現在的 v0.19；另一方面進行大刀闊斧重寫v1.x，改良設計與使用體驗。

兩條主線並行開發，我覺得對於一個開源 UI 庫來說，很難得社區沒有分裂。我覺得這是因為有比較穩定的 Google Material Design 設計語言作為理論支持，所以兩條主線的分歧實際上並不是很大。

可用組件：這個庫的本質是一個 React Components 庫，所以隨著這個庫的發展，可用的組件越來越多。現存最早的版本 v0.3.0 公開的組件有11種，現在(v1.0.0-beta.16)已經有 26 種了。

組件庫顯然是應該提供自定義組件的方法的，這就是 UI 庫的 API。對於 React 實現的組件庫，API要分為：

該用什麼組件類？
如何設置屬性？顯示屬性怎麼設定？事件屬性怎麼設定？
如何嵌套元素？

然而，關於如何自定義組件（API），Material UI 的意見有過數次變化。但在 v1.x 的 API 設計中，Material UI 似乎找到了明燈：

Sebastian Markbage: API design is hard because you can make it seem simple but it"s actually deceptively complex, or make it actually simple but seem complex.
Sebastian Markbage: API 設計是困難的，因為你可以讓它看上去簡單但實際用起來非常複雜，或者讓它用起來簡單但看上去複雜。
As Sebastian Markbage pointed out, no abstraction is superior to wrong abstractions. We are providing low-level components to maximize composition capabilities.
正如 Sebastian Markbage 所指出的，不抽象比錯誤地抽象要好。我們準備提供低級別的組件來最大化組件的可組合性。

看來 Material UI 開發組認識到了缺點：在 v0.x 版本中，前端開發者們要麼就按照官方 demo 照葫蘆畫瓢，要麼當他們選擇開動自己的想像力，任意地去組合各種組件的時候，噩夢就降臨了——按鈕錯位，顏色錯誤……非預期的組合效果迫使開發者們編寫額外的代碼來抵消這種默認行為。

API 設計確實是困難的，Material UI 庫的維護者沒有也不可能考慮所有的使用情況。當組件本身是可組合的情況下（React帶來的特性），Material UI 庫已經不能只稱為一個庫（Library），它更應該稱為一個框架（Framework）。框架做抽象，目的就是為了吸收後來的編程複雜度，檢驗抽象的好壞就看這個複雜度有沒有被成功吸收。

之前已經提過，Material UI v0.x 在組件組合嵌套時的表現差於預期，顯然這是因為它進行了錯誤的抽象。新的 v1.x 已經發現了這個問題，決定降低抽象的等級來解決這個問題。於是，對於 v0.x 文檔中的 demo，在 v1.x 中需要多得多得多得多的代碼。所以有的人可能覺得這個 v1.x 是不是看上去過於複雜難用了。對此，我可以明確地告訴你，如果你完全不想改動 demo 中的組件組合方式，那 v0.x 更適合你；而絕大多數應用場景，我相信你會選擇更自由的 v1.x。

Material UI v0.x 中的組合陷阱，對於看熱鬧的人來說，不是那麼容易識別出來的。只有那些真正嘗試過把 Material UI 應用到項目中的人，才會體會其中的痛苦。在 v0.x 中，我們需要藉助 React 開發插件，運用各種 Material UI 官方文檔中沒有提及的 Hack 技巧來使得我們的 UI 符合預期。這非常危險，魯棒性極差。更甚者會讓設計妥協於技術。我覺得正是因此，Material UI 這個庫不可能被大規模應用，動畫漂亮，實現酷炫，看上去簡便易用，實際上代價很大，多可惜啊。

其他答案 ( @傲世笨熊 ) 里也有吐槽 Material UI 關於 CSS 的處理方式。

在 v0.8.x 及其以下版本中，Material UI 的樣式自定義跟其他的 CSS Framework，沒有什麼不同，就是換換顏色，重寫 h1-h6 等基本 HTML 標籤的 CSS 之類的簡單玩意，使用 CSS 跟其他的 React 庫沒有區別。這個時期版本的升級基本等同於「又多了幾個組件」。

自從 v0.9.0 開始，引入了 theme 來支持一致性的視覺設計，但這個時候是一個 global theme 的樣子，更改主題需要一個靜態方法。同時，開始使用 CSS in JS 的套路，開始了 inline CSS 的時代。就是每個組件都有了一些 *style 的屬性可供傳入用 JS 編寫的 CSS 對象。有趣的是，從這個版本開始，Material UI 不再自稱 CSS Framework了。

然後到了 v0.13.0，theme 開始通過 React Context 來進行傳遞，從 global theme 演變到了每個組件都可以 getTheme 的情況。

這個情況在 v0.15.0 又變了，需要專門組織一個 ThemeProvider，配上實例化好的 theme 對象，放在 Material UI 組件的根節點上，提供一個 theme 環境。因此，這個版本產生了向下的不兼容。之後一直到現在 (v0.19.x)，都沒有什麼大的變化。無據猜測他們搞出個ThemeProvider是受了Redux的影響（笑

最後是 v1.x，實際上在 v0.16.x 期間，Material UI 維護者已經發布了新的設計 (v1.0.0-alpha)，其中提到了 self-supporting，實際上就是(開倒車)不需要一個 ThemeProvider 也能設置樣式，他們可能覺得不要 Provider 就不行這件事過於激進了，但也保留 ThemeProvider作為拓展選項；還有就是採用了新的 JSS 作為引入樣式的方式，這是一種將 JS 編寫的 CSS 對象編譯成真正的 CSS 類（具有帶編號的類名），然後往 DOM 里添加 CSS class 來讓瀏覽器渲染樣式的技術。很好，我們擺脫醜陋的 inline CSS 了！而且每次渲染要計算 inline CSS 也是一筆很大的性能開銷。現在 Material UI v1.x 開始使用 styled-components 來處理樣式了。

期待 Material UI v1.0.0 正式發布！

這段時間搭建公司後台頁面一直在用，挺不錯的，可以自定義主題

缺點嘛確實在開發過程中列表項的話會有點卡，而且有些組件的動畫效果差強人意

第一次接觸Material Design是在寫一個APP來玩兒的時候，因為覺得沉浸式狀態欄很酷炫，但是不知道怎麼實現。正好在使用魔趣，看到了馬丁龍豬說5.0提供了介面，然後就實現了一下。效果確實不錯。

但是後來就沒有更多的時間來關注和學習了。到現在也還沒學會這一玩意兒。有時間繼續學習。