The roadmap is a living document, and it is likely that priorities will change, but the list below should give some indication of our plans for the next major release, and for the future.
v0.17.x have low priority and will most likely not be reviewed nor merged. We want to focus on bug fixes.
The next release is going to be huge ✨.
We host a temporary documentation for the pre-releases.
Material-UI was started 3 years ago. The ecosystem has evolved a lot since then, we have also learned a lot. @nathanmarks started an ambitious task, rebuilding Material-UI from the ground-up taking advantage of this knowledge to address long-standing issues. Expect various breaking changes.
The core team is now helping him in the next branch.
Here are some issues that we plan to fix along the way.
For more details, you can have a look a the next milestone as well as the next project.
The next branch has become more mature.
We think that it's a good time to communicate more on this effort.
We have a lot of people opening PRs and getting them closed, this is not a good thing.
This Q&A tries to answer some of your questions.
The CSS (cascading style sheets) specification emerged in 1994. At that time, a bunch of others specifications were competing. It was the cascading concept that made CSS succeed over its competitors, by allowing users to provide their own style-sheet, that will be later combined with browsers and authors style-sheets. That feature was removed 2 years ago from the most popular browser. My point is, our needs have evolved quite a bit since then.
Back in the beginning of Material-UI, we had many issues with the first LESS approach. Aside from the problem with CSS at scale raised by @vjeux, we had the following ones:
- We had a dependency on the LESS build chain with no way to abstract it away. Users needed to change their theme variables. @gpbl was maintaining a SASS version. (Today, we could be using cssnext).
- The theme was computed at build time but a Material component must be able to render quite differently depending on his context that can only be known at runtime. (Tomorrow, CSS variables will help a lot)
- We were shipping a big monolithic CSS file. That's not great for performance (for example it goes against the PRPL pattern suggested by the Polymer team). That was also an issue for users wanting to use a single component without paying for all the CSS upfront.
- We used multi-level selectors, making the override of styles challenging.
We later came up with an inline-style approach solving the majority of our issues. But:
- We had lost around 25% of the performance 🐢. Computing the inline-style at each render with no caching isn't really efficient.
- Some more advanced CSS feature wasn't available, e.g. keyframes, pseudo-elements, pseudo-classes 💅.
- Media queries aren't available on the server. At least not yet.
- The debugging was really challenging. Browser dev tools aren't tuned for inline-styles.
- React v15 has changed the method of injecting styles into the DOM meaning, for example, that prefixing all browsers for
display:flexis no longer possible 💥.
Yes, it does. You can have a look at this presentation for more details.
Migrating a component to the next branch isn't just a style migration.
We think that it's our best opportunity to clear the API and improve the implementation of the components.
@nathanmarks ended up fixing a lot of long standing issues in the process.
Yes, it would much better to discuss an action plan for each of them. That would save us quite some time following a wrong path. We should answer the following questions:
- What will the API look like?
- What tradeoffs are we going to make?
- What features will be implemented?
That conversation could start on one of the following issues.
We have Github project to coordinate the work toward the next release.
You can check the Component to migrate column to know the ones needing to be migrated to next.
Once we agree on the migration plan you're gonna have to get your hands dirty. That's really up to you. At least, you gonna have to
- clone the
nextbranch - install the npm dependencies
- play with the documentation site
- write some documentation
- write some tests (unit, integration, visual)
We don't have an ETA for the release of the next branch,
however, it's going to follow a specific release plan:
- We focus on migrating the components to the
nextbranch. They may not be fully migrated. - We merge the
nextbranch into master. At that point, we're going to stop supporting thev0.17.xreleases. - We release our first alpha.
- We focus on finishing the migration of all the components to get a good feature parity with
v0.17.x. - We release our first pre-release.
- We ship 💯.
Have we ever considered using the best libraries for each piece of functionality and provide only a wrapper for the UI?
We have, it really depends on the problem we are trying to solve. For UI related things, providing a wrapper for the functionality is often the wrong approach. We think that it should be done the other way around, i.e. providing a low-level API that can be combined with third-party libraries, e.g.:
On the other hand, using a smart date library for the DatePicker / TimePicker would probably be much better as date management is tricky and not a core business.
- [#2863] Add missing components, and missing features from current ones.
- [#593] Full support for react-native.
- Add example on how to use react-virtualized / react-list for lists, menu items and table.
- [#2493] Use higher order components across the library to abstract themes passed down from context.
- [#2784] Stateless components.
- [#1673] I18n for the doc-site.