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.
Version 1 (published on NPM under the next tag)
Releasing stable v1 is our top priority. It's going to be huge ✨.
We are just at the beginning, we hope to make it:
the simplest React UI library available for new Front-End developers to start with.
very customizable so highly UI demanding production applications can save time building on top of it.
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 has been dedicated to the rewrite effort for one and a half years.
If you are interested in following our progress or if you want to help us reach that goal faster, you can have a look at the following milestones:
The v1-beta version has matured, so we think that it's time to communicate more on this effort. The following Q&A is an attempt at answering some of your questions.
Summarizing, what are our main problems with CSS?
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.
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 weren't available, e.g. keyframes, pseudo-elements, pseudo-classes 💅.
Media queries weren't available on the server. At least not yet.
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:flex is no longer possible 💥.
We don't have an ETA for the release of the v1, however, we are going to try to follow this plan and hope for a Q1-Q2 2018 release:
We completely address the styling issue before moving from alpha to beta.
We publish our first beta releases.
We merge the v1-beta branch into master
We publish our first pre-releases, if all goes well, we move to the next step.
We publish v1 🎉
At that point, some features and components from Material-UI v0.x will be missing in the v1.
So, what about them?
First, both versions can be used at the same time, people can progressively migrate, one component at the time.
Then, with the help of the community and over time, we will support more and more components.
We would rather support few use-cases very well and allow people to build on top of it than many poorly.
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.: