Modern CSS with Tailwind Book Club!

Phoenix Forum Chat / Discussions
, , ,
21

You’re welcome. I deliberately stayed away from other information sources about Tailwind as I knew this book club would start. So for the time being this book is gonna be my “source of truth” and I will judge Tailwind by it. Not to say that when this book won’t succeed in convincing me I won’t have another look at Tailwind.

Disclaimer
This is my review of chapter #2 . I am a Tailwind noob and still in the predicted “ugh”-phase and this review will likely reflect so.

Chapter 2: Tailwind Basics

This chapter starts with a little introduction about the naming of classes in in Tailwind, and how utility class names differ from semantic class names. It then goes on to tell why and how Tailwind can work with large sites.

It lists a few advantages I will not summarize here (you have to read the book!). But one of the advantages is that Tailwind can use “modifiers” to define special behavior for things such as “hover and differently sized screens”. This is impossible with inline CSS. I consider this advantage a knock-out for inline CSS. But this major difference it not mentioned.

Not for the first time, the claim is made that with Tailwind the scope of changes is exceptionally clear. So far there has not been an example to proof how it differs from other CSS solutions. It also mentions the class names of Tailwind being “cryptic” at first; (almost) conflicting with the “The Tailwind classes I’m using do a pretty good job of representing my intend” of the first chapter; something I already wrote about.

The first part of this chapter ends with the notion that with Tailwind you can create CSS classes from a list of utilities, but advises to leave it up to the front-end stack you are using (which hopefully already uses some de-duplication pattern)

The second part and third part handle some very basic things like naming convention and reset CSS.

Duplication

This section starts with the advise given earlier: use whatever you already use to prevent duplication. For React devs this means: create a React component with the styling in it.

This section makes me laugh. Can’t help it but it seems utterly clumsy.

  • For React 3 components are created: Header, SubHeader and SubSubHeader. The next example uses a plain JS function named title to return a list of ultility classes. Let’s apply those to H6: SubSubSubSubSubHeader and subSubSubSubSubTitle()! Guess we are back at “naming things is hard”.
  • Then two examples in Ruby on Rail are shown. One is to create a function (just like JS) and the other one uses an ERB partial saying “the syntax is a bit weird”.
  • Glad there is a solution to all the madness: using the css directive @apply.

What I’ve learned so far:

  • The solution to prevent duplication requires you to come up with names.
  • Creating components/partials can cause code with weird syntax AND you still need to come up with those names.
  • When all gets ugly, you can use @apply…just know you will have to…come up with some names.

I feel like we are going in circles, just so Tailwind can get away with “duplication is not an issue” and “with Tailwind you don’t have to come up with names for your shared CSS properties”.

Glad those names are not CSS names cause those were really hard to come up with according to Tailwind :wink:

Next up: The @apply directive.
Just to make this one clear I copy the code block:

@layer component {
   .title {@apply text, text-6xl}
   .subtitle {@apply text, text-4xl}
   .subsubtitle {@apply text, text-lg}
}

Looks a awful lot like LESS and SASS, doesn’t it? Except of course the names. These are Tailwind names not LESS or SASS names and certainly not CSS names cause those were ‘really hard to come up with’. :confused:

You might not have noticed, but I am getting sarcastic the more I read. I am not sure if it’s the way the book claims advantages without backing them up with proof (it could have done easily with the inline CSS knockout!) or the fact that I feel like I am directed in circles with the ‘duplications & naming’ issue. All I know is I need a break to clear my mind.

Edit: it just feels to me (so far!) Tailwind has two major advantages: it’s can do things inline CSS can not and it’s short syntax pattern is solid. And those advantages are major already! The rest of the claimed advantages just cause doubt due to them being seemingly in conflict.

3 Likes