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 
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â. 
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.
)
