DEV Community: Kerry Boyko

A little trick for CSS/SCSS module safety

Kerry Boyko — Fri, 05 Apr 2024 22:05:24 +0000

This is a tip for those using CSS Modules. You know, things like:

import styles from './componentStyles.module.scss'

While we may never have anything near the "type safety" of TypeScript in styling with SCSS or CSS, we can take advantage of a quirk in how CSS Modules work to make it so that we will be warned if we try to access a style in our stylesheet that is undefined.

This actually comes up quite a bit - you may have a defined style (in BEM syntax) of something like .home__button__main { but reference it in your React code as
<button className={styles.home__main__button}>Text</button>. Or any number of typos. The point is, if you try to access a value on the styles object that is undefined, it will return undefined which is a valid value, and which will be interpreted by your browser as "undefined" leading to elements having class .undefined.

Wouldn't it be great if we could get our browser to throw an error at build time or run time if we attempted to use a property on styles that just wasn't there?

We can.

This is because style modules are interpreted in the JavaScript code as objects. In Typescript, they'd be considered type StyleModule = Record<string, string>

Here's the cool bit. In JS, there's a rarely used set of keywords: "get" and "set". Getters and setters often make code more complicated and hard to follow - that's why they're used sparingly, and many people prefer the syntax of creating a getter function. Setters are even more confusing, because they can execute arbitrary code logic whenever assigning a variable. There are a few cases in which this might be useful. For example:

class Weight {
  constructor(private value: number){}

  get kilograms (){
    return this.value;
  }
  get pounds (){
    return this.value * 2.2;
  }
  set kilograms (value: number){
    this.value = value;
  }
  set pounds = (value: number) {
    this.value = value / 2.2
  }
}

const weight = new Weight (10);
console.log(weight.kilograms); // 10
console.log(weight.pounds); // 22.0
weight.kilograms = 5;
console.log(weight.pounds); // 11
weight.pounds = 44
console.log(weight.kilograms); // 20

And so on and so forth.

Using this, we can actually run code on setting or retrieving values, and change the output conditionally. So what does this mean?

It means we can write something like this:

export const makeSafeStyles = (
    style: Record<string, string>,
    level: "strict" | "warn" | "passthrough" = "strict"
): Record<string, string> => {
    const handler = {
        get(target: Record<string, string>, prop: string, receiver: any): any {
            // if element is defined, return it. 
            if (prop in target) {
                return Reflect.get(target, prop, receiver);
            }
            // otherwise, 
            if (level === "strict") {
                throw new TypeError(`This class has no definition: ${prop}`);
            }
            if (level === "warn") {
                console.warn(
                    `This class has no definition: ${prop}. Defaulting to 'undefined ${prop}`
                );
            }
            // we should 
            return `undefined_class_definition ${prop}`;
        },
    };
    return new Proxy(style, handler);
};

The result: When you use an undefined style in a project... this happens.

I can go into the code and see:

 <div className={styles["progress-bar-outer"]}>
                <div
                    className={styles["progress-inner-bar"]}
                    style={{ width: `${formCompletionPercentage * 100}%` }}
                ></div>
            </div>

and to my module and see

.progress-bar-outer {
    position: relative;
    width: 100%;
    height: $progress-bar-height;
    background-color: get-palette("progress-bar-background");
    margin: 0;
}
.progress-bar-inner {
    position: absolute;
    width: 0%;
    height: $progress-bar-height;
    transition: width ease-out 0.25s;
    background-color: get-palette("progress-bar-fill");
}

And I immediately know that there is a typo or spelling error that is simply fixed by correcting the line:

 <div className={styles["progress-bar-outer"]}>
                <div
                    className={styles["progress-bar-inner"]}
                    style={{ width: `${formCompletionPercentage * 100}%` }}
                ></div>
            </div>

Talking with a client about Tailwind.

Kerry Boyko — Fri, 15 Sep 2023 13:38:20 +0000

I've been working on a 6wk contract gig to shore up some code, and the previous developer decided to go with Tailwind. I've mentioned why I think that's a bad idea before, but I had to explain to my new clients some of the problems that have happened because of that initial poor choice:

ME: So - I realise that it was another {my contractor} developer who chose to add Tailwind to this project. I don't know his or her reasoning. I can tell you, however, that one of the big problems with using Tailwind to create UI components is that it is extremely difficult (near impossible) to overwrite those properties assigned by tailwind utility classes when trying to extend a component to have the same functionality but different styles.

I think for now it's best to just create a seperate "TransparentButton" and "RippleButton" components which are independent of the Button component defined in {our UI library}.

Response:

I believe the overall goal with adding tailwind was to reduce the number of components and or css classes/styling we have to maintain. Ideally we maintain "nothing" outside of our core value prop and can just plug & play industry standard components & libraries.

I think that is a noble goal. Unfortunately, in practice, I find Tailwind to actually be counterproductive to that goal, because since you can't just make minor tweaks to existing libraries, or existing components, you end up having to recreate entire components from scratch.

This is mostly because CSS does something Tailwind doesn't - it cascades.

That is, if the library has a button called "Button" with the className of "bg-orange", it will have an orange background. I can't then modify Button with react props or adding more Tailwind classes to create a button that is identical except it has different styling, (such as a transparent background).

On the other hand, if the library's Button component were created with a CSS file associated with the class .button, where button was defined as

.button { 
  background-color: orange; 
}

I could simply use that component, add another class name (.transparent-button, for example) and then define the .transparent-button with

.transparent-button { 
  background-color: transparent;
}

The computer will read <button class="button transparent-button">Button</button> as "First apply the .button styles. Then apply the .transparent-button styles, overwriting any styles that are different."

Tailwind doesn't have that functionality, in part because a design choice of tailwind is that it sorts class definitions according to it's own criteria (which I presume is alphabetical) in the tailwind postprocessor, not based on the order in which you write them.

So, If you were to define <button class="bg-orange bg-transparent"/> then Tailwind would apply the orange. Because (I presume) "bg-o" comes before "bg-t" alphabetically.

Modifying the Vue prototype is "evil monkey-patching"

Kerry Boyko — Wed, 28 Apr 2021 23:16:05 +0000

If you're not familiar with 'monkey-patching', it's when you modify the prototype of an existing language feature. Like adding a new method to Array.prototype, or redefining Array.prototype.reduce because it's just slightly more efficient to use lodash's version.

It's a feature in a lot of high-level languages that use some type of inheritance, specifically Ruby, Python, and (naturally) Javascript.

But just because you can do something in Javascript doesn't mean you should. Monkey-patching can lead to namespace collisions if two developers have their own methods - and you won't really know "which runs first" until runtime in most cases. (It's also really hard to unit test, since both methods will be tested and get correct assertions in isolation.) Additionally they create a discrepancy between the original source code and observed behavior.

Most importantly for the purposes of this article, it's a change that isn't immediately visible to those who use the code after you. You think you're telling the computer to do one thing, but you're actually telling the computer to do something else. That, of course, is how you get bugs.

Let's switch gears for a moment to the Vue framework.

First, I think Vue is great. It is well designed, written, documented. I like the way it's going with Vue 3.0 and the Vue Composition API, I like Vue templates, I like .vue files, I like that it's about 1/3rd the size of React. I like a lot of things about it.

But if Paulie Walnuts held a gun to my head, and asked me what my favorite framework is, I'd say React.

And the reason is quite simple: Vue gives you a lot of ways to do the same thing, and not all of those ways are good ways. Computed vs. Watch, callbacks vs. emits, mapGetters vs. mapState vs. this.$store...

All are equally valid. None of these methods are canonically wrong or right. They all work. This is part of the reason Vue is much easier to learn and get going with quickly than React is. But you start to lose out as the program and the team starts to scale. If you give a team of 10 developers 10 different ways to code something, you will end up with 10 different ways to do the same thing in your codebase, and a lot of highly-coupled code with duplicated logic.

At Deverus, where I first started working with Vue in 2017, we hired some (good) outside contractors which put configuration information on Vue.prototype.$config, constants on Vue.prototype.$constants, and all our asynchronous API methods on Vue.prototype.$API. They were probably following one of the many blog posts which suggested this pattern, like this one from Telerik.

But this created a problem - and that problem was that now every Vue component - even presentational ones that really did no logic - now had access to every API call, had access to every configuration setting, had access to every constant, even if they weren't needed. They also had the ability to redefine them at will.

The most problematic was the this.$API methods. If there was a problem, you'd have to search through every component to see what components were using this.$API, see where the data was being stored. More often than not, multiple calls were being made to the same API method when one would do - data was often duplicated (or worse, duplicated, then became out of sync) in many different data() observables of components.

This wasn't wrong. It's considered a valid Vue pattern. And if you're using this pattern, you're not using Vue wrong, but for us, it led to these problems. We had to create more style rules (in our case, put all the API calls into the Vuex store, not components, and pass down the data via mapped getters,) and refactor the application so that we could create a more testable application that was easier to add features to.

So - that's a bit of a long way round to get to the point of this post - which is to say that while there's no official best practice guide that says you shouldn't modify, or "monkey-patch" the Vue prototype, I'm saying that from my experience you're probably going to have a bad time if you do.

I suppose that vue prototype modification isn't "monkey-patching" the way that modifying the prototype of, say, Array or Object is. But once you add the Vue framework to an application, it really does become so integral that the Vue prototype takes on a lot of the same importance as a core language feature. React developers expect React to behave like React every React application they work on. Vue developers... well, in an ideal world they should be able to rely on Vue, but because prototype modification is a thing, they can't always.

This can be further frustrating because monkey-patching the Vue prototype is how vue-router and vuex (and a lot of other good plugins) work -- and work well. And it is extremely easy, for example, to get your route params from this.$route.params, compared to the hoops you used to have to jump through passing your parameters to your component with React (though the useRouter hook makes it really easy now).

I'd like to think that they're exceptions. See, one of the things Vue has going for it is that because it doesn't try to stop you from doing stupid things, it allows you to do very clever things as well. And vue-router and vuex are very clever indeed.

And I'm not saying that you or your team isn't clever. But if you're using Vue in production for a mission critical app, changes are you're dealing with things that make your team less clever than a decidicated core of open-source developers making sure that they can rigourously test, type, and develop software over many iterations.

A team that doesn't have time to pay off technical debt is going to lose "cleverness". A team being pressured to add a new feature before a deadline is going to lose "cleverness." It's one of the reasons why open source purists like Richard Stallman (*1) believe that all programming should be open source - a view I don't share, but one that has enough of a point that I can't fault him for holding it.

So in the vein of "real world" programming for commercial applications (as opposed to open-source or academic purposes), monkey-patching the Vue prototype probably isn't something you want to get in the habit of.

As always, looking to have a discussion in the comments below - I'm sure my experience wasn't universal, and plenty of people have been clever with Vue in their teams.

In the meantime, if you want to take a look at some other suggestions I have for keeping large Vue projects organized, checkout my styleguide for Deverus (based on Vue 1.0) and my styleguide for the Vue Composition API back when it was in proposal form. I'll probably update and combine both and put them here on Dev.to soon.

Evil monkey image by Jason Scragz, used under CC-2.0-Attribution

Footnote:
(*1) Correction: An earlier version of this article refered to Richard Stallman as Eric Stallman, (confusing him with fellow open source evangelist, Eric S. Raymond.) I regret the error.

[RFC] Airfoil: Coding an alternative to Tailwind

Kerry Boyko — Wed, 21 Apr 2021 17:18:21 +0000

Update: Created a crude github repo for Airfoil. It's mostly just a placeholder right now.

My previous post on TailwindCSS got a lot of views and comments.

To my horror, while I've convinced many not to go down the path of Tailwind, a few others including, (grumble, grumble) my team lead, still think Tailwind has some good ideas.

And here are some of his points:

Its valuable to be able to define a custom style within a single class, then use that wherever. For example: example box-shadow, border radius, different colors, font styles...
Tailwind (with the CSS-in-JS tool, twind) provides a mental model to organize utility classes without polluting the global stylesheet.
If you're going to use a utility class approach, why not use the same one as thousands of other developers? Otherwise you need to document your stuff well.
I think the alternative: building, managing, planning, documenting, fixing our own utility class solution is a nightmare.

And then he said some words I think he might now regret:

If you think you can do a better job I would love to see how you'd approach it.

WOO! WEEKEND PROJECT

The truth is, yes, I do think I could do better. And I don't think it would take that long.

To his points directly: I think that we can define a much smaller subset of the features of Tailwind, and do it better. I think that the cost of "building, managing, planning, documenting, and fixing" our own library that is tiny (relative to Tailwind) is going to be easier than maintaining Tailwind in our projects, (as I believe Tailwind doesn't remove code you have to maintain, it just obscures it.)

Let's be clear - in this library, (working title: "Airfoil") I wouldn't want to do everything that Tailwind does, because I'm firmly convinced 97% of what Tailwind does, Tailwind doesn't need to do, and indeed, shouldn't do.

Instead, I'm talking about extracting only those utility classes which actually provide a good shorthand for complex concepts in CSS.

So for example, I can see how someone might like the shorthand "container" for something like this:

/* breakpoints */
--breakpoint-sm: 640px;
--breakpoint-md: 768px;
--breakpoint-lg: 1024px;
--breakpoint-xl: 1280px;
--breakpoint-2xl: 1536px;
.container {
  width: 100%;
}
@media screen and (min-width: var(--breakpoint-sm) {
  .container {
    max-width: var(--breakpoint-sm);
  }
}
@media screen and (min-width: var(--breakpoint-md) {
  .container {
    max-width: var(--breakpoint-md);
  }
}
@media screen and (min-width: var(--breakpoint-lg) {
  .container {
    max-width: var(--breakpoint-lg);
  }
}
@media screen and (min-width: var(--breakpoint-xl) {
  .container {
    max-width: var(--breakpoint-xl);
  }
}
@media screen and (min-width: var(--breakpoint-2xl) {
  .container {
    max-width: var(--breakpoint-2xl);
  }
}

This, to me, is the perfect example of when a utility class makes sense to use. One word: "container" replaces 30 or so lines of code. It's reusable and does what it says on the tin. The only thing I'd do differently is name it 'with-container' rather than 'container', as I think the prefix 'with-' makes a lot of sense for a utility class to distinguish it from a semantic class.

And if Tailwind were full of code like this, I wouldn't have a problem with it.

But "container" is one of the eight or so exceptions which prove the 200+ rules that Tailwind is just full of stuff that can be replaced by one or two lines of CSS.

.flex {
  display: flex;
}
.py-6 {
  padding-left: 1.5rem;
  padding-right: 1.5rem;
}

So I went through Tailwind's documentation, and picked out the nine classes that I'd actually keep out of the 200+ that Tailwind offers.

And they are:

container
ring
box-shadow
filter (but possibly as a function/mixin)
backdrop-filter (which will be difficult as neither Edge nor Firefox support backdrop-filter natively)
drop-shadow
animate-spin
animate-ping
animate-pulse
screen-reader-only

And at this point, if you're saying to the screen: "Well, what about X?" -- that's why I'm writing the post.

I'm soliciting comments on what you think needs to be added to such a library. Maybe it's in Tailwind and I missed it. Maybe it's not in Tailwind, but you wish something like it was.

I also would like to know how you think it should be developed. I think right now, the goal is to start life as a .CSS file on Github Gist, to get the proper effects right.

Then, provide two different versions - one as styles and mixins as a partial (_airfoil.scss?) for an SCSS file, another which takes a function and just returns a string, for integration into libraries such as styled-components and emotion/css.

But again - before I do that, I need to scope out the project. So - please retweet this among your dev friends, both "pro-tailwind" and "anti-tailwind" and talk about what you'd like to see - or not like to see - in the comments below.

TailwindCSS: Adds complexity, does nothing.

Kerry Boyko — Mon, 19 Apr 2021 19:39:13 +0000

If you work in the front-end, you've probably heard a lot about TailwindCSS, a CSS library, much like Bootstrap. Much unlike Bootstrap, however, Tailwind takes a different approach - it is all "utility classes".

And I am not a fan. I got a whiff of it and quickly learned the name is appropos: it was as welcome and useful as passed gas.

Before we start, let me try to explain what a utility class is. Let's say that you have many components, and many of them need to have the CSS style property: "display: flex;". Instead of writing that over and over in your css, multiple times, instead you create a class called "flex"

.flex {
  display: flex;
}

Then, in every component that needs to be flexed, you add that "flex" class.

This is not a bad thing. I have written, and used utility classes a great deal myself, especially when I'm writing CSS without the aid of CSS-in-JS solutions or a preprocessor like Sass/SCSS.

What Tailwind does is take that concept to the extreme, with the idea being that you almost never have to write CSS, you just write different classes based on what styles you need to apply.

Which is an interesting choice, because...

This is just inline styles with extra steps.

That's it. Writing <div class="flex">foo</div> has the same exact effect as writing <div style="display: flex;">foo</div>. Well -- slightly different in that inline styles have higher priority than classes, but that's not really relevant in this context.

So - with that in mind, with the exception of CSS prioritization, any argument you could make against using inline styles in your codebase is also an argument against using Tailwind. For example: Lifewire: Avoiding Inline Styles for CSS Design. Or StackOverflow: What's so bad about inline CSS?. Or LogRocket: Why you shouldn’t use inline styling in production React apps.

I know it seems a bit lazy to rehash other users criticisms of inline styles to explain what's wrong with Tailwind, but it really is a 1-to-1 mapping. It's just inline styles with extra steps.

Some of the problems Tailwind shares with inline styles:

It's WET, not DRY.

When you want to change your site styling in a major way, if you've used utility classes, you need to go through each use of those utility classes - that is, every component - and visually determine what needs to be updated. For example, let's say that your company's primary color is blue. You'll have lots of blue stuff in your website, marked with things like: "text-blue-500" or "bg-blue-300" to determine different shades of blue. And that's fine until your company decides to rebrand, and all of the buttons - but only the buttons - on the site need to be red.

Now you have to go through each component and manually change "text-blue-500" to "text-red-500". And with 1000 edits comes 1000 oppertunities to introduce a bug. It is almost a textbook definition of why the DRY principle is in place.

Alternatively, if you're using regular-old CSS, what you probably did is create a class called ".button". You can just go into that class and change a single line: "background-color: 'red';". Any element that uses that class definition will now be red.

That brings us to the next point:

HTML should only concern itself with the structure of your page, not the styling of the page.

People talk about seperation of concerns a lot in development. CSS Modules (and especially .vue files) have done a lot to dispel the notion that you need to segregate structure, behavior, and style of the same basic building block of your site in seperate folders, but there is something to be said for seperating concerns. That is - each part of your code should be "loosely coupled and highly cohesive."

In other words, your HTML (structure syntax) shouldn't have information about what the styles should be, it should only contain information about the structure of the page.

Indeed, the ultimate reason for the invention of CSS, the whole point of the entire enterprise of CSS... was specifically so that you could seperate content from presentation.

And the method for doing this is through the "class" attribute.

The whole point of "class" is specifically that you can tell the computer what an element is - that is, describe an element's content. Once you've defined the content, then you just need to decide what content of that type should look like.

This not only means that you can go and change how an element looks without worrying about the underlying structure of the page, but also means that you can use these classes to describe what an element is. Indeed, part of the reason for BEM's naming syntax is that BEM names not only tell you what the component is, but also what it's relationship to other components in the document is.

Remember that when we write code, we write it for two audiences: the first is the computer itself, which doesn't care how the code looks so long as it runs, and the other is your fellow programmers. The easier it is for them to quickly identify what parts of your program are and how they interrelate, the more quickly that they can fix bugs, add features, and bring value to the organization.

Which brings us to:

It's hard to read

If you look at some HTML with Tailwind in it, you might say to yourself that the HTML looks "busy" or even "ugly." That's true, but it's missing the point.

Say what you will about inline styles, but they're at least providing enough context to let you know what's happening. Tailwind code is full of semantically obscure abbreviations; most of which are just redefinitions of already well known CSS properties.

Worse still, when they're not redefinitions, they can become downright cryptic. Tailwind prefers to use prefixed class names instead of media queries. Here's an example from Aleksandr Hovhannisyan

So this in Tailwind:

<div
  class="w-16 h-16 rounded text-white bg-black py-1 px-2 m-1 text-sm md:w-32 md:h-32 md:rounded-md md:text-base lg:w-48 lg:h-48 lg:rounded-lg lg:text-lg"
>
  Yikes.
</div>

could be expressed as:

<style>
.thing {
  width: 16px;
  height: 16px;
  color: white;
  background-color: black;
  padding: 0.25rem 0.5rem;
  margin: 0.25rem;
  border-radius: 0.25rem;
  font-size: 0.875rem;
  line-height: 1.25rem;
}

@media screen and (min-width: 768px) {
  .thing {
    width: 32px;
    height: 32px;
    border-radius: 0.375rem;
    font-size: 1rem;
    line-height: 1.5rem;
  }
}

@media screen and (min-width: 1024px) {
  .thing {
    width: 48px;
    height: 48px;
    border-radius: 0.5rem;
    font-size: 1.125rem;
    line-height: 1.75rem;
  }
}

</style>
<div class="thing">Yikes.</div>

Now, the first example, I grant, is an awful lot less code to write, but look at how the second example is explictly defining height and width at specific breakpoints.

It is verbose - as raw CSS usually happens to be, but there are other solutions - such as Sass/SCSS, or solutions such as Emotion, Styled Components, etc. which allow you to use much more terse syntax without losing the cohesive meaning behind it.

Again, this is programmer 101. It's why senior developers get on junior developers for naming variables "const h = 10" instead of "const height = 10"

Another reason why the latter is easier to read than the former - Tailwind's classes are arranged horizontally, while the CSS is written vertically. The wider text is, the harder it is for a reader's eyes to jump to the next line, and the harder it is to find the one particular word you're looking for in a wall of horizontal text.

I bet your eyes started glazing over the second you saw the horizontal scroll bar on that Tailwind code sample, didn't they?

You lose a lot of the features built into standard CSS

I won't harp on this too much, but it should be pointed out that because Tailwind doesn't allow you to use the power of many of CSS's basic features. You can't chain selectors together, like so:

.foo:focus,
.foo:active,
.foo:hover {
  /* css code */
}

You can't use combinators.

.foo p {
  /* all p that are decendants of a .foo */
}
.foo > p {
  /* all p that are direct children of a .foo */
}
.foo + p {
  /* all p that are directly -after- a .foo */
}
.foo ~ p {
  /* all p that are siblings of a .foo */
}

It solves a problem that doesn't exist.

One of the craziest things is that there's an obvious limitation to Tailwind's utility-class paradigm. What happens if you want to group related styles together? Rarely is "display:flex;" used without "justify-content: {value}", for example. CSS allows you to group these styles together into (wait for it), classes.

There's a tool for grouping related Tailwind classes together too. It's called @apply. It's special, non-standard syntax that goes in your CSS file (a directive) and allows you to string together a collection of tailwind classes and place them all under one class name.

That is to say, completely defeating the purpose behind the utility-class paradigm. If you end up having to use @apply, then *why don't you just use normal, ordinary, conventional CSS, which is easier to read, understand, modify, and doesn't require special tooling or parsing. CSS syntax can be complex, but it's been pretty stable since the late 90s, and isn't going to radically change anytime soon.

There's a very simple mental experiment I'd like to conduct with you.

Imagine a world in which CSS was never developed, but something akin to Tailwind was. That is, webpages could only be styled through repeating these individual class names... presumably through using table tags for layout. (To give you an idea of how old I am, I used to code web pages as a summer job in my junior year of high school in 1996 - and we used a LOT of table tags.)

If you could go from the limitations of Tailwind to CSS, wouldn't you consider that a quantum leap forward? Expressive syntax! Semantic naming! Style grouping! Selectors and combinators!. It would be like moving from Assembly to C for the first time. If so, why are we considering replacing CSS with something that does less, is more complex, creates bad quality codebases, and possibly ends up with massive vendor-lock in down the line?

If you want better than CSS, there are already solutions.

So a lot of the hype around Tailwind is that you can get rid of CSS. I know, everyone knows CSS can be hard to work with - especially if you have legacy codebases where the CSS wasn't written that well.

But for the most part, there are other, better improvements on CSS that actually do make styling simpler. There's the various CSS-in-JS solutions that allow you to leverage the power of Javascript to create dynamic class definitions; there's preprocessers such as Sass/SCSS/LESS; there's linters like Stylelint; there's best-practices methods like BEM/SMACSS. Is there overhead in learning these technologies? Yes. Is there tooling that needs to be part of your build chain? Yes. But unlike Tailwind, all of these solutions actively provide a tangible benefit to your code -- which is something that Tailwind can't claim.

It literally provides no value, and tons of problems.

At the end of the day, what do you get for all these problems? What are you left with? You're basically left with a less readable, more complex version of inline styles, a coding technique that we've been trying to breed out of junior developers for the past decade or so.

If you adopt Tailwind, it's going to provide problems for you and your team for years to come, and it's going to be hard to remove it.

Updates based on the comments section.

A few notes based on responses from the comments section.

Why trash something if you don't like it?

It's important to write about bad frameworks as much as it is to write about good ones, because of two reasons.

First, is the John Stewart Mill argument of "the value of the wrongful idea" - that in making a (good faith) argument for something incorrect, one arrives at a more correct, more complete view by analysis and refutation. Ideas must be continually challenged lest they go stale. Indeed - "one who doesn't understand one's opponent's arguments does not understand one's own" is a maxim I try to apply. When I wrote this article, I tried to look for the good in Tailwind. Why do people like it? (They don't have to write css. They can put style info in their HTML. They can write terser code. It gives them power to do things they don't know how to do in css.) Once I knew why people liked it, I had a much better understanding of why I didn't. (It combines content and presentation. It makes things harder to maintain. The syntax is obscure. You lose the power to do things that you can do in css.)

Second is that someone down the line is going to think: Hmm, should I add Tailwind to my app that has to be maintained by my team? And they're going to google "pros and cons of TailwindCSS". There will be plenty of articles explaining the pros. Here's one explaining the cons. Hopefully I've made a compelling argument not to use Tailwind so that future developers won't have to deal with it.

You're being disrespectful to the people who like Tailwind.

This isn't New Orleans Jazz.

I don't like New Orleans Jazz, so I don't have to listen to it. I don't buy New Orleans Jazz albums.

I am not in the habit of making detailed criticisms of what I feel to be the music compositional problems of New Orleans Jazz.

But I have never had a team lead, product owner, or stakeholder come up to me and say: "For the next project, I'm thinking that everyone on the team has to learn how to appreciate and play New Orleans Jazz."

Engineers and developers are often required to work with technology that they not only don't like, but which makes their work harder - often because decision makers either didn't care about the software's tradeoffs, or didn't know. Can't do much about the former, but we can do things about the latter.

When team leaders are thinking about incorporating a new technology into their tech stack, they should look for blog posts like this one to help them evaluate whether or not it's worth a try.

My thesis is not, as you seem to think, "I don't like Tailwind, and therefore YOU shouldn't like Tailwind either". That's a 12 year old's viewpoint of technology criticism.

Rather my thesis is: "If you choose Tailwind for a mission critical application, you will end up making your job harder, your application more brittle, and your team, in the long-term, will suffer."

But CSS has massive problems!

It really does. And there are better solutions than plain CSS. But Tailwind isn't one of them.

Say that in the 1990s, the only way to build a house was to bang nails in with a flat rock (CSS). And then, around the mid 2000s, a really smart guy invented "the hammer." (SCSS) It took adjusting, and you have to learn a new tool, but it did the job much better.

Around the early to mid 2010s, another guy invented the nail gun (CSS-in-JS). It did a lot of the same stuff as a hammer, but you had to know how to use it. There were tradeoffs, but generally, people who chose to work with hammers or with nail-guns usually ended up okay. Many peoplee would often use a manual hammer when the manual hammer seemed appropriate, and the nail gun when they seemed to need it. And all was good in the world of carpentry.

Then in 2017, someone came up to the carpenters and said: "Hey, see what happens when I do this!" and starts hammering in nails with the butt end of a loaded revolver (Tailwind).

And it's supporters quickly point out how more effective it is at building houses than banging in rocks.

"But it's a loaded gun. It might go off and shoot someone"
"Hasn't happened to me yet."
"Why don't you use a hammer? Or a nail gun?"
"I don't like hammers or nail guns."
"I can understand why you might not, but even if you used a rock, that would be safer in the long run."
"But using a rock is so difficult and inefficient."
"I'm not saying to use a rock. I'm saying that the hammer already solves the problems you have with the rock, but even the rock is a better tool for this than a loaded gun because it won't shoot anyone."
"But I love my gun."
"I guess it's alright if you use your gun on smaller projects on your own property, but..."
"Nope, I'm the foreman. Everyone on the site is using loaded guns from now on, because they're awesome."

Update: 9 May 2021 - Check out this blog post by Mykolas Mankevicius which attempts to rebut this article. I disagree, of course, but I think it adds to the debate, and if you're reading this deciding whether to use tailwind or not, you should hear what the "other side" of this issue has to say.

Agree but think my writing style might be too abrasive? Check out Benoît Rouleau's take on this article entitled Tailwind CSS might not be for you

Cher writes about some of the response this article has gotten and how it relates to our own unconcious bias in "Sexism, Racism, Toxic Positivity, and TailwindCSS"

This is a test post

Kerry Boyko — Mon, 13 Jan 2020 20:18:27 +0000

I'm going to be frank. This is a test post. I just want to know if I can redirect my domain, www.frontendgineer.com, here.