Language matters: Building blocks
I have been working on a big platform with countless pages. Since its beginning, it was built using Bootstrap for the front end, but maintenance has become burdensome over time. This is due to multiple layers of custom CSS and the reuse of CSS, which has caused changes in one place to have unpredictable effects on others.
Our way out of this situation is Tailwind. Since you write HTML and style in the same files, the styling is gone when you remove the HTML. You can still create custom tweaks per page or element without impacting another.
Bootstrap did have its benefits: it provided developers with a nice set of UI elements to use when building screens. So, we have started developing a set of reusable elements.
There are several approaches to creating such a set of elements in Rails. Partials and helpers are part of the framework, so it made sense to start from there. I discussed this with the developers, and they set off exploring our options.
Very quickly, I started hearing them say things like:
- “The project’s goal is to build a set of components.”
- “Let’s use View Components by GitHub.”
- “Have we looked at building components with React?”
- “There are also these things called web components.”
Wait a minute?! How did we go from a problem definition of conflicting CSS files and the lack of reusable elements to a whole set of new paradigms? Then it dawned on me. We had named the project “Tailwind Components”.
I then realised that the word “Components” carries so much baggage; people already have a clear picture of what components are in their heads. It might not be the same for everyone, but when you say, “Let’s build components”, it starts having a life of its own.
Components might be the right solution, but I’d like to find out first what we can do by just writing HTML, helpers and partials smarter; we could write “components” afterwards if we still needed them. This whole first phase was skipped because of the choice of words.
The fix was to start calling them ‘building blocks’. This suddenly leaves room for solutions such as writing a modal in a Ruby partial, hooking a stimulus controller to it for the simple dynamics and documenting in Notion, where you can go to copy and paste the modal. This is not the best solution or what we need to go with, but now it is on the table again, along with what might be the real solution.
So, language matters!