Mouse-first typewriting
Picture yourself at a younger age: you want to discover that mesmerizing machine named computer, but you’ve never used a keyboard before. There are so many keys, even more than the alphabet can contain, and they are all layed out in a weird order. It’s so intimidating!
So you call your racist uncle (apparently there’s one in every family these days), and he shows you a “mouse-first typewriting” technique he created to make your life better:
Forget these keyboards, they doesn’t scale. With the well-engineered copy-paste, you only need two meticulously balanced utility buttons!
Do your younger selves approve? I bet they do!
Let’s move on.
There’s an interesting phenomenon happening when you read web developers passionated by the web platform: every now and then, there’s kind of a moment, usually lasting a couple of days, during which some of them are writing one after the other about the same topic, like a rally cry in defense of the Goodness of the Web Platform™ or against things damaging it. This cycle occures every couple of months.
Unfortunately we pretty much need this, because browsing the web is often a disaster. There are plenty of reasons for that, like underestimating the complexity of the front-end discipline, overlooking HTML and CSS, or not giving a tilde about who will actually use the websites you make.
So, these days, it’s about FailWind: about its marketing and promises, about utility-first CSS, about sharing experience of using this tool. My experience with it is pretty straightforward: I know my stuff around CSS, I’ve never used any CSS framework, but I had to try it 6 years ago in a project, upon request of a back-end colleague, and it was a disaster.
- It’s unproductive when you are productive with CSS.
- It bloats the HTML payload and makes it harder to read.
- FailWind class naming is not CSS friendly nor predictable.
- Adding dark mode bloats the CSS payload.
(It was 6 years ago, I don’t know today, and I don’t know any front-end developer using CSS frameworks.)
Again, I know my stuff around CSS. Everyone their path. Like for everything in web development, there are a lot of fashions and techniques to write and maintain CSS: this diversity is great, but it can be hard to navigate. Each time you decide to go for a tool or technology, there’s a learning curve for its adoption, its in-depth usage and its removal. The time you will take for this is time you can also decide to invest in understanding and learning the fundamentals.
Bonus
Since we are talking about utility classes, here are some I often use:
/* Center the children of a flex container. */
.flex-center {
display: inline-flex;
justify-content: center;
align-items: center;
}
/* Apply the accent color. */
.accent {
color: var(--accent);
}
/* Apply font-weights. */
.f300 { font-weight: 300; }
.f400 { font-weight: 400; }
.f700 { font-weight: 700; }
/**
* Limit motion based on user preference.
*
* https://toot.cafe/@tomayac/110989258569274871
*/
.reduced-motion {
&,
&::before,
&::after {
@media (--reduced-motion) {
animation-delay: -1ms !important;
animation-duration: 1ms !important;
animation-iteration-count: 1 !important;
transition-duration: 1ms !important;
transition-delay: 1ms !important;
}
}
}When using utility classes along semantic classes in HTML, I separate them using a pipe (|), which increases the readability of the classes sequence:
<ul class="eventsList | flex-center f700">I care about readability up to that level of detail, and I have not invented this technique.
Also if you’re wondering what’s that @media (--reduced-motion) syntax from the last example, it’s called Custom Media Queries and you can use it since years thanks to the PostCSS postcss-preset-env plugin. I can definitely say PostCSS is the most important tool for CSS: I’ve always coupled Sass and PostCSS together, and last year I’ve started to ditch Sass to only keep PostCSS, but that’s another story.