Tailwind CSSCSSBangkok

Tailwind CSS v4 for Bangkok Business Websites

27 April 2026 · by Yunmin Shin

What Changed in Tailwind CSS v4?

Tailwind CSS v4 is a complete rewrite of the framework's internals. The most significant change is that it no longer relies on a JavaScript configuration file by default. Instead, you configure Tailwind directly in your CSS file using the @theme directive. This makes Tailwind feel more like a native CSS tool and less like a JavaScript build plugin.

The performance improvements are substantial. The new Rust-based engine (Oxide) processes large codebases significantly faster than the v3 engine. That matters in practice, not just on paper: when we're rebuilding a clinic site's UI in front of a client during a review call, a build that finishes in under a second instead of several keeps the session feeling responsive instead of turning into dead air while Tailwind recompiles.

How Does the New Configuration System Work?

In Tailwind v4, you define your design tokens directly in your CSS. Say you're rebuilding an aesthetic clinic's site and need its brand teal and a heading font applied consistently across every service page:

@import "tailwindcss";

@theme {
  --color-brand: #0f6b64;
  --color-brand-light: #e3f3f1;
  --font-heading: "Noto Sans Thai", "Inter", sans-serif;
  --radius-card: 12px;
}

These CSS custom properties are automatically available as Tailwind utility classes: text-brand, bg-brand-light, font-heading, rounded-card. There is no separate tailwind.config.js to maintain for theme values — the CSS file is the single source of truth, which makes it much easier to hand off a design system to a client or another developer without hunting through a JS config for where a color is defined.

You can still use a config file for more complex scenarios, but it is no longer required for basic customization.

What New Utilities Help with Thai-Language Content?

Tailwind v4 adds several utilities that previously required custom configuration or plugins, and a few of them solve real problems specific to bilingual Thai/English sites:

text-wrap: balance and text-wrap: pretty — Better typographic line wrapping. Thai headlines wrap unpredictably because Thai doesn't hyphenate the way English does; text-wrap: balance on an <h1> noticeably improves how a clinic's service headline breaks across two lines on mobile instead of leaving one orphaned word.
Container queries are now built in without the plugin. Use @container and @sm:, @lg: breakpoint variants to style components based on their container's size rather than the viewport — genuinely useful for a service-card grid that appears both full-width on a clinic's homepage and squeezed into a sidebar on a service detail page. The same card component adapts to its container instead of needing two separate implementations.
field-sizing-content — automatically resizes a textarea to fit its content, handy for a booking form's "additional notes" field.
not-* variants — apply styles when a condition is NOT met. not-hover:opacity-75 applies opacity when the element is not hovered.

How Do You Upgrade an Existing Site from v3 to v4?

Tailwind provides an official codemod:

npx @tailwindcss/upgrade

This handles the most common migration tasks: updating the PostCSS config, replacing deprecated utilities, and generating a CSS-based theme from your existing config. Review the output carefully — some custom plugin configurations require manual updates.

The biggest breaking change for most teams is that the @apply directive behavior changed slightly and some utility names were renamed for consistency. Run the upgrade on a preview branch first and specifically re-check Thai typography after upgrading — line-height and text-wrap defaults changing can shift how Thai body copy wraps, and that's easy to miss if you only spot-check the English content during review.

Why Migrate Away from WordPress Page Builders?

A large share of the clinic and restaurant sites we take over started life on WordPress with Elementor or a similar page builder, patched together with a dozen plugins for booking, SEO, and caching. The styling in that stack lives scattered across theme CSS, plugin CSS, and inline styles injected by the page builder — nobody can say with confidence where a given color or spacing value comes from.

Rebuilding that site's UI in Tailwind v4 collapses all of that into one @theme block and a set of reusable components. A service card, a booking button, a testimonial block — each becomes one component styled with utility classes, reused everywhere instead of redefined per page. The result is a site that's both faster to load (no plugin bloat, no render-blocking CSS files stacked on top of each other) and faster to maintain, since a brand color change is one line in the @theme block instead of a search-and-replace across dozens of Elementor templates.

Should Bangkok Projects Use v4 Now?

Yes. Tailwind v4 is stable and well-supported. New projects should start with v4 from the beginning. The CSS-native configuration approach is cleaner, the build is faster, and container queries alone make component-based design significantly more maintainable for the kind of multi-page clinic and restaurant sites where the same card or button pattern needs to adapt to several different layouts.

At Bluewich, we use Tailwind v4 on all new projects, including the clinic and restaurant sites we personally operate. The design-token-in-CSS approach works well for Bangkok clients who need a branded design system maintained consistently across a homepage, service pages, and a booking flow, without a separate JS config file drifting out of sync with the actual CSS.