Reusable Blocks Deserve Reusable Styling

Why we’re introducing Tailwind into our bespoke WordPress development process

Technology moves quickly, but we’ve never felt the need to adopt every new framework or development trend. A new tool only becomes valuable if it genuinely improves the websites we build or the experience of maintaining them over time. Otherwise, it’s simply another dependency to learn, support and eventually replace.

We’ve taken our time with Tailwind rather than adding it to our process straight away. We’re not using it because it’s fashionable or because it promises less CSS. We’re using it because it fits the way we now build WordPress websites, with reusable components that can be updated and extended over time.

As WordPress has become increasingly component-driven through Gutenberg, one question kept coming back to us: If content is reusable, shouldn’t the styling be reusable too?

Websites are no longer built page by page

Visitors experience websites one page at a time, but that’s rarely how they’re built.

Modern WordPress websites are usually assembled from reusable blocks that solve common content problems. A testimonial might appear across dozens of pages. A call to action could be used throughout an entire site. News listings, event cards, FAQs and promotional banners are all created once and reused wherever they’re needed.

This approach has clear advantages. Editors become familiar with a smaller number of flexible components, designers can establish consistent patterns across the website and developers only need to improve a block once for every instance to benefit. As websites grow, those advantages become even more valuable because consistency becomes easier to maintain. The styling deserves to follow the same principle.

When every component gradually develops its own collection of one-off CSS rules, maintaining that consistency becomes much harder. Similar blocks begin behaving slightly differently, duplicate styling accumulates and making simple changes becomes more time-consuming than it should be.

Component: Why reusable matters

Reusable blocks deserve reusable styling

This is where Tailwind began to really make sense for us.

As more of our WordPress work has moved towards reusable Gutenberg blocks, the styling behind those blocks has needed to become more reusable too. Continually adding new CSS rules as a project grows can make similar components behave differently and make future changes harder to trace.

Tailwind gives us a consistent way to apply the design decisions agreed for each project. Colours, spacing, typography and layout still come from the website’s own design system, but they can be implemented using shared rules rather than recreated each time a new component is built.

That does not reduce creativity or make different websites look the same. Every project still has its own identity, design language and bespoke components. The difference is that those decisions can be applied more consistently across the whole website.

Better components rather than bigger stylesheets

Working with WordPress, not around it

WordPress now offers more ways to manage colours, typography and spacing across a website. Tailwind lets us carry those choices through the bespoke blocks and front-end components we build.

We align the two so editors and the front end work from the same set of design decisions. That was one of the reasons we felt comfortable introducing Tailwind. It fits the way WordPress has developed rather than creating a separate system alongside it.

That alignment was one of the reasons we felt comfortable introducing Tailwind. It supports the way WordPress itself has evolved without creating a separate set of design decisions alongside it.

What this means for our clients

None of this changes how our clients manage their websites. It simply gives us a more consistent and maintainable way to build them, while supporting the performance standards we already work towards.

Tailwind is entirely part of our development workflow. Editors will continue creating pages using carefully designed Gutenberg blocks in exactly the same way they do today. They won’t need to understand utility classes, write HTML or think differently about managing content.

Clients should notice benefits such as:

• More consistent layouts and spacing.
• Fewer unexpected differences between similar components.
• Easier future enhancements as requirements change.
• A design system that’s simpler to extend and maintain.

If we’ve done our job properly, clients shouldn’t notice Tailwind itself at all. They should simply experience a website that behaves consistently and is easier to update and grow.

Isn’t the HTML harder to read?

One of the main concerns developers have about Tailwind is that utility classes can make the HTML look more cluttered.

Traditional CSS keeps most styling in separate stylesheets, while Tailwind places more of it directly on the component. That makes it easier to see how a component has been put together without moving between several files.

Component: Two valid approaches

Both approaches are capable of producing excellent websites. For the component-based WordPress projects we now build, keeping more of a component’s implementation together makes the work easier to follow and maintain.

Tailwind doesn’t replace CSS

Adopting Tailwind doesn’t reduce the importance of understanding CSS. We still write conventional CSS where it is the right approach. Developers need to understand layout, typography, responsive behaviour, accessibility and browser behaviour regardless of the framework they use. Tailwind changes the workflow, but it doesn’t replace the knowledge required to build well. Like any framework, it is only as effective as the decisions made by the people using it.

Performance is a welcome benefit, not the reason

Tailwind can help keep stylesheets focused by generating CSS for the utility classes used within a project.

That is useful, but it is not the main reason we are adopting it. Website performance depends on hosting, caching, images, JavaScript, third-party services, page structure and many other technical decisions.

The main benefit for us is easier maintenance. Tailwind gives us a consistent way to style reusable components, while performance still depends on the many technical decisions made across the website.

Another step towards maintainable websites

Every development decision should make a website easier to live with in the future, not just easier to launch today.

Introducing Tailwind won’t dramatically change the websites our clients see, nor should it. What it changes is how consistently those websites are built. It helps us create reusable Gutenberg blocks with reusable styling and reduces the one-off decisions that make projects harder to maintain over time.

What visitors should notice is something much more valuable: a website that remains consistent as it grows and adapts more easily to changing requirements.

If adopting Tailwind helps us build websites that remain coherent as they evolve, then it’s earned its place in our development process.

How this translates