There are two camps when it comes to simplicity in software: those who believe that simplicity comes in having many small, composable parts and those who believe that it comes from having a unified, batteries-included experience.
🧵1/7
🧵1/7
I can honestly see the value in both approaches, as long as they are followed rigorously, but I think that simplicity is too ill-defined to be a good goal in itself. The better goal, I think, is mechanical sympathy.
2/7
2/7
Understand how the machine helps you teach your goal, and work with it. Start from the lowest level of abstraction that makes sense for you, and build only what you need on top of that.
3/7
3/7
With this as a goal, you get a unified experience because your design informs every layer and component of the system. You can also have small, composable parts because you control the design language and the interface.
4/7
4/7
The best example of small components getting out of hand is JavaScript. This leads to problems in build time, performance, supply chain security, and cognitive overhead.
5/7
5/7
On the other hand, you have those Rails sites that are hard to scale and have code upon code trying to hack around "the Rails way" to implement a handful of features that don't fit the paradigm.
6/7
6/7
Mechanical sympathy, on the other hand, can lead to few, but maximally reusable, components. This is in addition to the energy and infrastructure cost savings. I don't think that we are going to lean into this paradigm for a long time, but I'm hopeful we get there eventually.
7/7
7/7
• • •
Missing some Tweet in this thread? You can try to
force a refresh
