我很喜欢这个 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 似乎找到了明灯：

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 正式发布！