And this is a very good article, if you ignore all the author's attempts to not offend anyone with words. But those are the times nowadays.
Last year we implemented a design system in Compose at our place, we continue to use and improve it, and now I can relate to a lot of this.
A design system is tokens (colors, fonts...) and components (buttons, text fields...). In this sense, any project has a design system in one way or another, even if it's unsystematic 🙃.
So, Material is already a design system, although for some reason it's not customary to think of it that way. And we as a community don't really understand who it's for. Objectively speaking, the world in general doesn't care at all about some design guidelines from Google, especially considering that Apple has different ones. Any business cares more about its own identity, and the idea of forcing everyone under one set of rules from both platforms is doomed to fail.
That is, in reality Material is just such an opinionated default for pet projects on Android. And if we want to grow, and grow in parallel with iOS, then continuing to use Material means constantly making compromises.
The problem is that it's almost impossible not to use it on Android. We can't just substitute our custom tokens instead of Material tokens, because Material components want Material tokens. We'll have to fit the designers' theme onto Material, starting with tokens, and most likely there's no one-to-one correspondence between them.
Google suggests several options for how to customize the design. The only one where Material is completely excluded from the equation implies that we either wrap each Material component or write our own.
- Writing your own from scratch properly and then maintaining it is incredibly expensive, so we discard this idea altogether.
- Wrapping is not a panacea, in a button we can't override the default font or minimum sizes, i.e. it doesn't customize the way you need it, it's all hardcoded there.
- The middle option implies that we copy all the necessary code from Material. But there's such spaghetti dragging because of a bunch of abstractions and privacy that in terms of maintenance complexity it's approaching the first option. In general, all options are bad. 😓
And we dream of having some layer of components that would implement functionality without mixing it with appearance. That is, we want a button to not depend on tokens at all, but give the ability to set EVERYTHING through parameters. And to have no opinionated hardcode in the code of these components. That would be great, right?
And on top of that, if Google wants it so much, we wouldn't mind having Material components that would simply fill component parameters from corresponding Material tokens. And if we want our own, we would create types for tokens ourselves and in our wrappers we would just pass them through.