Simplicity in CSS
I really like the current discussions going on in the web development community on how to handle CSS in a growing web application. There are some great ideas out there which try to push the boundaries of the constraints CSS is giving us. When I started what I called `programming` in High School 6 years ago, I was amazed by the possibilities HTML and CSS gave me. With almost no knowledge about Computer Science I could easily hack together a simple website for my band on a weekend and make it available to everyone on the web. Years went by, I went to University had Internships in Vienna, New York and I’m now working as a fullstack developer at Crewmeister in Munich. After attending the Barcamp of the Salzburg Web Development User Group where I gave a talk about “JS as preprocessor for CSS” I thought a lot about simplicity of web development in 2016. The main question during my 1.5 hours drive home was: “What happened during the last 6 years that we actually need JS as a preprocessor for CSS”.
We’re sometimes so obsessed with the “How” we built something that we completely forget about the people for “Whom” we build software.
As developers we’re very focused on solving problems in the most elegant way. We try to build abstraction above things which aren’t perfect right now and we fail many times in building the wrong abstractions. Building maintainable software is hard. Even in a perfectly designed programming language there’ll never be a right or wrong about solving a particular problem. This makes it very hard for unexperienced developers to find the right balance between abstractions and duplication. At the end of the day it doesn’t matter what abstraction a developer is using as long as it is easy to understand for the next developer. During discussions with my coworker and attendees of the Barcamp I come more and more to the conclusion we as software craftsman should think more about people outside of the development community. We’re sometimes so obsessed with the “How” we built something that we completely forget about the people for whom we build software. Those people can be kids, teenagers, people with disabilities, grandparents, our boss or even designers and other developers. We need to find a way to better communicate the things we do in our day to day work. That’s why we at Crewmeister are so obsessed with finding the right names for our code. In finding the right names we try to express abstractions to complex problems, which we can communicate with non developers. We often end up asking our marketing/sales department about names for problems we’re currently facing. Those problems can range from names for methods, class names, application layers or even CSS selectors. By creating a common language across all departments we reduce the overall explanation time if issues occur.
A month ago I wrote a post about CSS Architectures in 2016 in which I try to compare different approaches on how to simplify working with CSS. We at Crewmeister decided to use a library called Stilr which is round about 200 Lines long and enables us to define all our styles in JS. This makes it possible to create private CSS mixins and we’re able to easily track down bugs in our CSS codebase. Not fearing the global namespace also helps us to create names for our styles which our grandparents would understand. We don’t need a naming convention like Atomic CSS where implementation details are exposed into our markup or BEM where we have to prefix all our style declarations with the name of the component. The main advantage of our current approach is that I can simply name my styles as I would have named them 6 years ago. Automated refactoring tools available in IDEs like Webstorm help us rename styles automatically without fear. This is something I wasn’t able to do with any other CSS architecture until now. When a Button is simply called `Button` and can be rename to `Solid Button` if the designer wants to add a ‘Hollow Button’ you’re reducing the complexity through the whole application and avoid questions from coworkers who don’t know which button to use. If our Head of Marketing with little knowledge about Computer Science can change a Solid Button to a Hallow Button on one of our landing pages, we did a great job.
I’m often questioning myself whats the right abstraction for a particular problem and often forget about the people who are using this abstraction. Working on a fast growing web application where multiple developers work on the same codebase, giving understandable names is essential. That’s why I think Stilr is the right abstraction for the problems we’re currently facing with CSS.