Clean Code


[Tailwind CSS](https://tailwindcss.com/) has been the talk of the web dev Twitter all this week with people getting heated on both sides with bad take after bad take with actual, legit criticism in the mix [getting shouted down because of the classic tech-bro double whammy of racism and sexism](https://dev.to/cher/sexism-racism-toxic-positivity-and-tailwindcss-cil). So I figure I might as well jump into the conversation a bit and talk about my thoughts on Tailwind because god knows we need another man coming in with his opinion. However, I do think I maybe have a slightly interesting point of view on the topic as I do use Tailwind, but totally not how they want me to because I fundamentally don't agree with the conceit of the framework. Let's dig in.

1. **Should you be using Tailwind?** Sure, why not. I'm always of the mindset of use the tools you like and make you productive. Our field changes so quickly that if you are going to survive you will eventually need to learn good ol' HTML, CSS, and JavaScript outside the context of a framework. If you don't agree, then I'm sorry you are so very, very wrong.

2. **Does Tailwind fix and/or replace CSS?** Absolutely not. So why are people over the moon for it? It does 3 things very well: compiles down to a very small bundle, reduces issues with specificity and scope, forces people to use a design system. Where does it fall short? It can be very tough to read, it creates a pseudo second syntax for CSS, it hides the power of the cascade, and it feeds, unintentionally (likely... hopefully...), into the growing perception that CSS is fundamentally broken or bad that a lot of devs, usually young inexperienced devs, have been promoting which usually stems from the popular mix of incompetence, arrogance, and sexism.

3. **Are frameworks bad?** Of course not! Frameworks area great tools and certainly have their place. Need to spin up a concept quickly? Just starting and don't know how to make pretty things yet? Need a quick template to get a project off the ground? Go get that framework! They are incredible tools that can help bridge knowledge gaps and product gaps. In fact, I primarily learned CSS via reading through how Bootstrap was put together back in the day.

So now that all the caveats are out of the way, let's get down to business on how I use Tailwind. To start, I don't use the actually framework at all. As presented, Tailwind just doesn't jive with how I think about CSS; I can't deal with the cryptic looking utility classes cluttering up my HTML and I understand and use the cascade a lot. But I love how Tailwind forces you into a design system.

When I say design system, I mean a system of [spacings](https://tailwindcss.com/docs/customizing-spacing#default-spacing-scale), [font sizes](https://tailwindcss.com/docs/font-size), [color palettes](https://tailwindcss.com/docs/customizing-colors), etc. Instead of having these as utility classes, I map them to CSS variables. [Here's an example of my early work playing around with Tailwind inspired CSS variables](https://sv-design-system.glitch.me/).

I've found this approach to suit my needs nicely and have even expanded on it when it comes to colors:

<Code language="css">
{`--primary-color-hue: 210;
--primary-color-100: hsl(var(--primary-color-hue), 100%, 96%);
--primary-color-200: hsl(var(--primary-color-hue), 81%, 86%);
--primary-color-300: hsl(var(--primary-color-hue), 82%, 76%);
--primary-color-400: hsl(var(--primary-color-hue), 79%, 66%);
--primary-color-500: hsl(var(--primary-color-hue), 73%, 57%);
--primary-color-600: hsl(var(--primary-color-hue), 62%, 50%);
--primary-color-700: hsl(var(--primary-color-hue), 61%, 43%);
--primary-color-800: hsl(var(--primary-color-hue), 49%, 34%);
--primary-color-900: hsl(var(--primary-color-hue), 47%, 22%);`}
</Code>

Here I have a gradient of pinks all being generated off a defined hue. This means that I can simply change the hue and get a dramatically different gradient of colors. It also means that I can, if needed, leverage the hue outside of the standard primary color variables in other contexts. Another benefit is that I can quickly create a dark theme or any other kind of theme by simply redefining these low-level variables.

Now, this isn't as ideal as it could be due to HSL being kind of a mess, but once [LCH is broadly available this approach will become even more ideal](https://lea.verou.me/2020/04/lch-colors-in-css-what-why-and-how/).

Now I have a model for building out a design system that lets me write CSS the way I want to write CSS, leverages the cascade, enables easy themes. And, I have to say, it's been an absolute joy to use. I liked it so much that we've adopted this practice at my work for my teams core product and it's been game changing for us.

Is this something you should do? I don't know. It works for me and the work I do for the type of product I develop. You'll have your own needs and should evaluate what is going to work best for you. And, really, that's the only thing that matters; what works best for you for your specific situation. Maybe it's something you roll yourself. Maybe it's a framework. Maybe, like for me, it's something in the middle. Good ideas exist everywhere and we can always learn something from someone elses work.


How I Use Tailwind CSS

CSS Frameworks like Bootstrap, Foundation, and Bulma help us describe our HTML in terms of layout structure and components, but I'm not a fan of that approach.

I prefer an approach I learned from [Jen Simmons](https://www.youtube.com/watch?v=qNtJ5p3h2A4) where HTML is used to describe the actual content of the page. Layout doesn't ever factor into it. After all, it is _markup_ so it should be used to add semantic meaning to your content. But aside from this philosphical interpretation there are other reasons to not bake layout into your HTML.

A big one is there are fewer `div`s cluttering up the DOM which can improve performance. And it also results in cleaner looking code since there are fewer utility-classes in the HTML (though this last one is subjective as frameworks like [Tailwind CSS](https://tailwindcss.com/) make a reasonable argument for more of these utility-classes in your HTML).

- [View Demo App](https://ui-playground-grid-demo.glitch.me/)
- [Download Source Code on GitHub](https://github.com/arkmuntasser/css-grid-demos)

## Prerequisites

- Working knowledge of [HTML and CSS](https://internetingishard.com/html-and-css/)
- Familiarity with [Responsive Web Development](https://www.smashingmagazine.com/2011/01/guidelines-for-responsive-web-design/)

Let's consider this following layout:

![](https://res.cloudinary.com/arkmuntasser/image/upload/c_scale,f_auto,q_80,w_800/v1564885707/PixelSnap_2019-08-03_at_19.21.49_2x.png)

Using Foundation, I might write some HTML like this:

<Code language="html">
{`<section class="articles">
  <div class="row">
    <div class="columns large-8">
      <div class="row">
        <div class="columns large-6">
          <article></article>
        </div>
        <div class="columns large-6">
          <article></article>
        </div>
      </div>
    </div>
    <div class="columns large-4">
      <article></article>
      <article></article>
    </div>
  </div>
  <div class="row">
    <div class="columns large-8">
      <article></article>
    </div>
    <div class="columns large-4">
      <article></article>
    </div>
  </div>
</section>`}
</Code>

This is fine, but what is this thing? Really? It's just a list of articles, right? So shouldn't the HTML just look like this:

<Code language="html">
{`<section class="articles">
  <article></article>
  <article></article>
  <article></article>
  <article></article>
  <article></article>
  <article></article>
</section>`}
</Code>

That's a lot cleaner looking and a lot more descriptive of the content we have. But now that we've gotten rid of the layout, how do we add it back in? That's where CSS Grid comes in!

<Code language="css">
{`.articles {
  display: grid;
  grid-template-columns: 5fr 5fr 4fr;
  grid-template-rows: repeat(6, 7vw);
  grid-gap: 1rem;
}\n
.articles article {
  grid-column: span 1;
  grid-row: span 3;
}\n
.articles article:nth-child(3) {
  grid-row: span 1;
}
.articles article:nth-child(4) {
  grid-row: span 2;
}
.articles article:nth-child(5) {
  grid-column: span 2;
}`}
</Code>

That's it! That's all the CSS that you need to recreate the layout. I find this to be far easier to read than the framework-based solution above.

So now we've cleaned up our HTML and more accurately and concisely describe the actual content we have and we we're able to move our layout logic into just a few lines of CSS. But we haven't even gotten to the best part!

Because we're now handling layout in the CSS, we can take our simplified HTML and display it nearly anyway that we want without altering it!

What if we change our CSS to this:

<Code language="css">
{`.articles {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  grid-template-rows: repeat(18, 6vw);
  list-style: none;
}\n
.articles article:nth-child(1) {
  grid-column: 1 / span 2;
  grid-row: 1 / span 3;
}
.articles article:nth-child(2) {
  grid-column: 2 / span 2;
  grid-row: 3 / span 3;
}
.articles article:nth-child(3) {
  grid-column: 1 / span 2;
  grid-row: 5 / span 3;
}
.articles article:nth-child(4) {
  grid-column: 2 / span 2;
  grid-row: 7 / span 3;
}
.articles article:nth-child(5) {
  grid-column: 1 / span 2;
  grid-row: 9 / span 3;
}
.articles article:nth-child(6) {
  grid-column: 2 / span 2;
  grid-row: 11 / span 3;
}`}
</Code>

And get this:

![](https://res.cloudinary.com/arkmuntasser/image/upload/c_scale,f_auto,q_80,w_800/v1564885707/PixelSnap_2019-08-03_at_19.22.39_2x.png)

Or maybe we want something a little wilder?

<Code language="css">
{`.articles {
  display: grid;
  grid-template-columns: repeat(5, 1fr);
  grid-template-rows: repeat(3, 19vw);
}\n
.articles article {
  grid-column: span 1;
  grid-row: span 1;
}\n
.articles article:nth-child(2) {
  grid-column: 3;
}
.articles article:nth-child(3) {
  grid-column: 5;
}
.articles article:nth-child(4) {
  grid-column: 2;
}
.articles article:nth-child(5) {
  grid-column: 4;
}
.articles article:nth-child(6) {
  grid-column: 3;
}`}
</Code>

![](https://res.cloudinary.com/arkmuntasser/image/upload/c_scale,f_auto,q_80,w_800/v1564885707/PixelSnap_2019-08-03_at_19.23.33_2x.png)

Maybe something a bit more standard?

<Code language="css">
{`.articles {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
  grid-gap: 2rem 1rem;
}\n
.articles article {
  height: 19vw;
}`}
</Code>

![](https://res.cloudinary.com/arkmuntasser/image/upload/c_scale,f_auto,q_80,w_800/v1564885708/PixelSnap_2019-08-03_at_19.24.07_2x.png)

Across all these layouts, there's only maybe 12 lines of CSS that's different. That's the power of CSS Grid and the power of moving layout out of the HTML.

Write Better Code with CSS Grid


Clean. Code. Clean code. CLEAN CODE! C-L-E-A-N C-O-D-E. Clean code.

What does that even mean? It's something we all say at some point, but it's meaningless. Or, more accurately, means different things to different people with different priorities and contexts.

For the purpose of this post I'm going to focus on separating business logic from the template. To illustrate this, I'll be using a code snippet I pulled from actual production code a developer on my team wrote. I've slightly modified it for clarity. Additionally, this is not meant to be an end-all-be-all way to write "clean code", but rather how I would approach writing this bit of code.

Before I get started, just a couple notes about the code:

1. The solution I end up with is not intended to be production-ready.
2. I am using server-side rendered [goatee](https://github.com/simpleviewinc/goatee) for templating, so syntax may seem unfamiliar at times.

Let's get into it:

<Code language="html">
{`<picture>
	<source
		srcset="{{image.getUrl({
			width: 900,
			height: 300,
			crop: 'fill',
			quality: 60
		})}}"
		media="(min-width: 641px)"
	/>
	<source
		srcset="{{image.getUrl({
			width: 1280,
			height: 500,
			crop: 'fill',
			quality: 60
		})}}"
		media="(min-width: 1025px)"
	/>
	<source
		srcset="{{image.getUrl({
			width: 1600,
			height: 700,
			crop: 'fill',
			quality: 60
		})}}"
		media="(min-width: 1440px)"
	/>
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

Here our dev created a responsive image to draw on the page. It works! But there's a few things that stand out to me about it.

First, there are 3 source elements that are nearly identical; that looks like an opportunity to simplify.

Second, it looks like the crop and quality properties are the same across all calls to `getUrl()`.

Third, if I need to introduce another source, then I need to make yet another source element and it's own call to `getUrl()` which grows adds visual clutter to the template and promotes copy/pasting which can lead to unexpected results if the dev isn't paying attention.

Let tackle this in phases. To start, I'm going to pull out the `getUrl()` calls and make the HTML simpler to read.

<Code language="html">
{`{{~exec(function() {
	helpers.var.srcSm = data.image.getUrl({ width: 900, height: 300, crop: 'fill', quality: 60 });
	helpers.var.srcMd = data.image.getUrl({ width: 1280, height: 500, crop: 'fill', quality: 60 });
	helpers.var.srcLg = data.image.getUrl({ width: 1600, height: 700, crop: 'fill', quality: 60 });
})}}\n
<picture>
	<source srcset="{{~var.srcSm}}" media="(min-width: 641px)" />
	<source srcset="{{~var.srcMd}}" media="(min-width: 1025px)" />
	<source srcset="{{~var.srcLg}}" media="(min-width: 1440px)" />
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

Already, this feels better. It isn't actually better, but I'm headed in the right direction. I still have a lot of repeated code, but at least I can more readily see how I might be able to simplify the multiple sources into a loop over a single source. Similarly, now that I've pulled out the `getUrl()` calls into a JS context, I can standardize how I generate the URLs.

<Code language="html">
{`{{~exec(function() {
	const props = {
		641: { width: 900, height: 300, crop: 'fill', quality: 60 },
		1025: { width: 1280, height: 500, crop: 'fill', quality: 60 },
		1440: { width: 1600, height: 700, crop: 'fill', quality: 60 },
	};
	const widths = [641, 1025, 1440];
	helpers.var.srcs = widths.map(width => ({
		width,
		src: data.image.getUrl(props[width]),
	}));
})}}\n
<picture>
	{{#~var.srcs}}
		<source srcset="{{src}}" media="(min-width: {{width}}px)" />
	{{/}}
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

This is starting to look much better now.

Starting with the HTML, I've condensed the multiple sources into a single, easy-to-read loop. This also means, that if I needed to add a 4th or 5th source, I modify the array.

Next, let's take a look at the JS. I've created an array of viewport widths called `widths`; these widths are also the keys in the `props` object so I can associate a width with a set of arguments for our `getUrl()` call. And lastly, I map over the widgets to create and array of `srcs` which is what drives the generation of source elements in our HTML.

At this point, the HTML is pretty much where I want it. However, there's still room for improvement in the JS; `crop` and `quality` are still shared across all the sets of arguments.

Let's address that.

<Code language="html">
{`{{~exec(function() {
	const sizes = {
		641: { width: 900, height: 300 },
		1025: { width: 1280, height: 500 },
		1440: { width: 1600, height: 700 },
	};
	const settings = { crop: 'fill', quality: 60 };
	const widths = [641, 1025, 1440];
	helpers.var.srcs = widths.map(width => ({
		width,
		src: data.image.getUrl({
			...sizes[width],
			...settings
		}),
	}));
})}}\n
<picture>
	{{#~var.srcs}}
		<source srcset="{{src}}" media="(min-width: {{width}}px)" />
	{{/}}
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

Here I've pulled out the `crop` and `quality` into their own object called `settings`. I've also renamed `props` to `sizes` which is much more descriptive now since all that object is concerned with are the sizes of the images to render.

Next, in the map, I spread the sizes and settings into an arguments object to be passed to `getUrl()`.

This is looking really slick now, but I'm not a fan of managing the viewport widths both in the `sizes` object and in the `widths` array. I really would like to keep it to a single touch point to reduce my chances to break something.

<Code language="html">
{`{{~exec(function() {
	const sizes = {
		641: { width: 900, height: 300 },
		1025: { width: 1280, height: 500 },
		1440: { width: 1600, height: 700 },
	};
	const settings = { crop: 'fill', quality: 60 };
	helpers.var.srcs = Object.entries(sizes).map([width, size] => ({
		width,
		src: data.image.getUrl({
			...size,
			...settings
		}),
	}));
})}}\n
<picture>
	{{#~var.srcs}}
		<source srcset="{{src}}" media="(min-width: {{width}}px)" />
	{{/}}
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

To simplify the handling of widths, I removed the `widths` array altogether and am, instead, mapping over the entries of the `sizes` object and destructuring out the size and the width. This is what I would consider "clean code".

First off, the HTML is greatly reduced and can support an indefinite number of sources. And there's no ambiguity about what the HTML is doing: it's putting a picture on the page.

Second, I have a single entry point for getting the actual image URLs that, ideally, I or a future developer supporting this site shouldn't need to touch.

Third, moving out the shared settings like `crop` and `quality` afford me two things:

1. I can easily make a global quality or crop change.
2. I can ignore them if I don't actually care about what they're set to.

Lastly, I am freed up to focus on the part that I most care about: defining sizes of images for different screen sizes.

I would and have delivered something like this in production. I find it to be much more readable, maintainable, and extendable compared to any of the previous iterations I ran through in this post.

How would you approach this? Do you have a better idea? Let me know in the comments below.


Category:
Clean Code

How I Use Tailwind CSS

Write Better Code with CSS Grid

Write Cleaner Code by Separating Logic from Templates

Category:Clean Code

Category:
Clean Code