Cwicly just released a deep integration with Tailwind, creating some buzz in the WordPress page builder community.
Should users care, though? Should people spend their time investigating this?
I call features like this a “2% feature” because they’re helpful to about 2% of the user base. For everyone else, this is a waste of time. Here’s why…
First, you have to understand the premise of Tailwind. The premise of Tailwind is: You no longer have to maintain a separate stylesheet when building a website or web application. You can style elements with utility classes while you write code in a code editor.
The goal of Tailwind is to never write custom CSS. *All* styling should be maintained within the HTML itself. That’s their core philosophy.
To achieve this, they had to build a massive and hyper-granular framework to cover nearly every possible base.
To make matters worse, many of the utilities are abbreviated (.pl-56) and unconventional (.md:max-lg:flex), so there’s a steep learning curve.
Furthermore, there’s no path to writing custom CSS while remaining hooked into Tailwind unless @apply is supported, but even the creator of Tailwind says @apply shouldn’t be used. So, by using Tailwind, you’re forcing your workflow into a pure utility class workflow (if you want all styling to remain within the control of the Framework).
Having components and “shell” functionality, as Cwicly does, certainly helps keep things maintainable, but it also creates more work and requires more foresight from the user.
Site Note: “Shells” in Cwicly are basically just custom classes that use an @apply type of philosophy. This is, technically, a direction violation of how Tailwind suggests styling should be managed. And … guess what … it’s a *retreat* back to what BEM already would have done for you.
Edit for clarification: Shells in Cwicly don’t output code the way @apply does. It just outputs pure Tailwind utility classes. My point is that a workflow like “Shells,” which is identical to an @apply workflow, is antithetical to Tailwind’s “separation of concerns” philosophy, not having to name things, and not having to systematically group classes for shared styling.
Shells, in fact, are a perfect example of how Tailwind doesn’t work in page builders. The page builder has to invent new concepts, like “Shells,” to work around the issue that the user can’t access the project-wide HTML to maintain the styling like they’re supposed to.
The main point here is that Tailwind’s underlying premise inherently collides with the premise of page builders. Page builders have already solved three enormous problems for us:
- We no longer have to write code.
- We no longer have to write CSS (unless we want to or need to).
- Beginners who don’t know CSS can stick to the builder inputs to guide them.
Introducing a massive, hyper-granular, and low-flexibility framework into a page builder is:
- A really dumb idea in a typical page builder.
- A passable idea in Cwicly, but only beneficial to the 2% of page builder users who already know and love Tailwind and a complete waste of time for everyone else.
The haters will say that I’m “biased.” What they fail to compute is the fact that Automatic.css was created for a page-building workflow, and Tailwind was created for … the opposite.
Tailwind was created specifically for coding environments and relies on features only found within coding environments (like find/replace, multi-cursor editing, maps and looping, etc.).
Tailwind is fucking impressive. Adam is brilliant. And if you’re thinking of trying out Tailwind for your next hand-coded project, you should definitely give it a shot and see what you think.
But Tailwind is antithetical to an efficient and maintainable page-building workflow. Those are just facts. I’ll never tell you it’s a good idea to stuff a square peg into a round hole, regardless of what I’m selling.
