More guidance around making complex things possible vs simple things easy #582
Description
In #306 we attempted to incorporate Alan Kay's maxim ("Simple things should be easy, complex things should be possible") into the Prefer Simple Solutions principle, but as a result, the current guidance seems to favor high-level solutions that make simple things easy, rather than decomposing use cases into primitives and making complex things possible.
However, we've seen time and time again that things not being possible produces much worse pain points for authors, and often our perception of what things are simple/common turns out to be incorrect, so we end up creating high-level solutions that are overfit to a particular set of use cases, effectively doing neither.
Shipping lower level solutions that make complex things possible first gives us more time to figure out which use cases to optimize for and what is the best way to make them easy, as they get the most pressing pain points out of the way.
For example, CSS relative colors are a low-level feature that was designed under the assumption that most color manipulations that authors need are simple additions or multiplications of color components with a number. Thankfully, because the feature was low-level enough to support arbitrary math, practice showed that the color manipulations authors need to make in practice are much more complicated and a higher level solution would have missed the mark. Additionally, because they are so low-level, they can be used to prototype other color functions, such as contrast-color() or gamut mapping. And yet, even the few assumptions it made to simplify the API, such as that most manipulations only involve one color turned out to not be quite accurate which is why we plan to add support for additional colors.
Another example is form elements. Because they started as high level elements that make simple things easy, their lack of stylability and customizability is one of the biggest sources of author pain points around HTML.
I would suggest tweaking the guidance to favor making complex things possible before making simple things easy, unless:
- Making complex things possible involves more privacy risks
- We have very high confidence on which use cases are common and how to best solve them
- Making simple things easy is core to the user need, e.g. because complex things are already possible. E.g. at some point, it was believed that we didn't need CSS Nesting, because authors could just use Houdini APIs to create a custom @-rule for nesting. That missed the mark, because brevity was a core part of the pain point. Nesting was already possible by simply repeating selectors!
This is in principle similar to the Extensible Web Manifesto, but with more nuance. Where the EWM failed was that it did not carve out these exceptions well, and it was often misinterpreted to mean "ship low-level solutions and you're done", while I think it should be carefully framed around prioritization between the two, rather than two distinct paths.