There are many approaches to using Tailwind with WordPress. _tw is the combination of approaches that works best for me. I think it could work for you, too!
I use _tw to build websites for my clients, working from custom designs created in applications like Figma, XD and Sketch. I built it to be:
- WordPress first—I like building websites using WordPress, and if I had to choose between it and the other parts of my development toolkit, I would choose WordPress.
- Block editor focused—My clients have a better time updating their sites when they can use the block editor, so I built _tw to make it easy to customize the block editor and to create as near as possible to a front-end experience when editing.
- Classic editor friendly—But sometimes you have a custom post type where the classic editor (sometimes in conjunction with Advanced Custom Fields) still makes sense, and _tw supports that, too.
- Free of production dependencies—I want a build process running locally that creates a static CSS file for deployment. I don’t want to add any dependencies that generate CSS, either client- or server-side.
- Just Tailwind and WordPress—I’m not interested in making decisions for anyone else about any other frameworks or front-end packages. _tw is a modern WordPress starter theme with Tailwind added—period.
WordPress first
I wanted to integrate Tailwind without making the experience of WordPress theme development diverge in any meaningful way from what is documented on wordpress.org. _tw is a hybrid theme using Automattic’s _s and Varia as a starting point, adding just what I felt was necessary to create a build process for Tailwind and JavaScript.
Block editor focused
Getting Tailwind (and Tailwind Typography) to play nicely with the block editor can take a bit of work. _tw handles that for you so you can focus on building websites.
That said, _tw doesn’t support adding arbitrary classes in the block editor. (For more details, please see the section below on my eagerness to avoid production dependencies.)
Classic editor friendly
I recognize that not everyone has bought into the block editor. (Though I do think those people should give it another chance!)
Also, I still find use cases for overriding the block editor for custom post types that consist exclusively of structured content, and I doubt I’m alone in this.
_tw supports both use cases, automatically injecting Tailwind Typography classes as appropriate.
Free of production dependencies
There are other projects at the nexus of WordPress and Tailwind that take different approaches to adding Tailwind support, and many of them do so by running Tailwind in production. There are a number of ways to do this, but all require some combination of:
- Using server- or client-side resources to generate CSS classes
- Caching CSS classes on a per-page basis, dependent on which classes are used on which pages
I’m not comfortable with either of the above options. These are necessary compromises if you want to support adding arbitrary classes in the block editor, but I worry about potential failures in class generation, caching, and other related brittleness or slowness inherent in running Tailwind in production.
And absolutely there are use cases for the above, and if you have them, those projects will hopefully serve you well! In my opinion, though, generating CSS locally is the most robust approach, and one that ensures the best experience for website visitors.
Just Tailwind and WordPress
Early versions of _tw included Alpine.js (because I love Alpine). But including it meant enqueuing JavaScript that a meaningful percentage of people working with _tw would never use. Watching the count of generated themes move from hundreds to thousands made me realize that I should make as few assumptions as possible about how people should set up their themes.
Since then, I’ve prioritized keeping _tw’s focus on adding Tailwind to WordPress, with a modern development workflow for JavaScript that makes it as easy as possible to add things like Alpine (or Turbo).
In putting _tw out in the world, I have been very conscious of the fact that it represents nothing more than what has worked for me and what I think is the best way for me to make websites with WordPress and Tailwind. There are other ways! But I’d love for you to give it a try and see if it works for you, too.
And if it doesn’t, I’d love to hear why. Maybe we can make _tw better together!