Why I use Tailwind with Shopify’s Dawn theme (out of spite)

Dawn is a modern, accessible, go-to starter theme, and a complete pain in the ass to work with…

If you’ve spent any real time building Shopify themes, especially for clients who care about conversions, performance, and maintainability, you already know what I mean.

Shopify’s default theme gives you some real gifts: fast load times, semantic HTML, solid accessibility practices.

But it also ties your hands behind your back with deeply abstracted markup, strange JavaScript patterns, and a structure that feels more like a riddle than a framework.

And yet… I keep using it. Why?

Well, when you combine Dawn’s foundations with the speed and sanity of Tailwind, you can ship fast, perform well, and avoid most of the conversion killers you get with bloated premium themes.

But it doesn’t come easy. Let me explain why.

Dawn: The Good

I’m not here to tear Dawn down completely. There are legit reasons it’s become the go-to theme for agencies and merchants:

• Accessibility: Great ARIA support, thoughtful keyboard navigation, semantic markup.

• Performance: Minimal JS (by design), lazy loading built in, responsive images that just work.

• Predictability: Dawn follows Shopify’s schema system closely, which makes it compatible with Online Store 2.0 features like app blocks and dynamic content.

If you're trying to build a storefront that ticks Lighthouse boxes out of the gate, it's not a bad place to start.

Dawn: The Bad

But then you actually open it up and start trying to build on it – suddenly you're 8 layers deep in main-product.liquid trying to figure out why a price isn’t showing the way it should.

You dive into price.liquid and you're greeted with a mess of nested if/else statements, tangled logic that checks for variant.compare_at_price, unit_price_measurement, sale states, and on and on.

And all of this is wrapped in CSS classes that seem like they're meant to be DRY but end up being cryptic and hard to override.

Need to restyle or reposition a price? Hope you enjoy overriding five different selectors across three files, just to move something 10 pixels to the left.

This is a consistent pattern across the theme. Shopify clearly wants to avoid duplication (understandable), but in doing so, they’ve leaned hard into abstraction.

Combine that with web components (like <product-form> or <modal-opener>), and you’re now debugging behavior across JS modules, custom elements, and dynamic schema. 

The result? Good intentions, bad DX (developer experience).

How Tailwind Helps

This is where Tailwind becomes my secret weapon.

Tailwind cuts through Dawn’s abstraction with a utility-first approach that lets me style quickly, visibly, and with confidence. No more hunting through stylesheets for .banner__hero--adapted-height.

Instead, just use on bg-black text-white py-2 px-4 and move on.

When you combine Tailwind with a simple build step – yes, we’re breaking Dawn’s precious “no tooling” rule – you get:

• Reusable components styled your way, without clashing with Shopify’s existing CSS.

• Rapid prototyping with consistent spacing, typography, and layout control.

• Full control over purging unused styles for performance.

Is it heresy? Maybe. Is it faster and more scalable? Absolutely.

Setting It Up the Smart Way

If you're going to do this, you need a dev setup that respects Shopify's theme development quirks but still lets you move like a modern frontend dev.

Here’s how I do it:

• Use .shopifyignore to keep your build output clean. Tailwind compiles into assets/tailwind.css, but everything else (node_modules, postcss config, local junk) stays out of the theme.

• Use tailwind.config.js to control which LIQUID files are actually scanned, checked for Tailwind classes, and generated in tailwind.css.

• Use an .env file to store SHOPIFY_THEME_ID and STORE_URL. This means I can deploy in one command with Shopify CLI and instantly sync changes.

Again, this breaks the no-build-step rule. But the payoff is dev speed, consistency, and reduced cognitive load. I’m not here to suffer for purity.

I could keep rambling, but if you just want to see my setup, check out this Git repo I made:

👉 https://github.com/alexggmark/shopify-dawn-starter 

Why do we need to do any of this?

Let’s zoom out. Dawn is technically a “starter” theme. But really, it behaves more like a reference theme. This is what causes headaches.

A starter theme is meant to be forked and hacked apart by devs. A reference theme is more like a demonstration of “best practices,” not necessarily optimized for customisation.

So what happens? Merchants jump in thinking Dawn is ready to go, but as soon as they want to tweak a layout or restyle a section, they hit a wall. The theme isn’t built for non-devs to edit. 

In fact, it’s barely built for devs to edit.

Shopify’s Shift Toward Enterprise

Shopify’s recent moves – Hydrogen, Shopify Functions, storefront APIs – make one thing clear: they’re betting big on enterprise.

And fair enough. That’s where the money is.

But the side effect is that everything else is getting more complex. Dawn, with all its abstractions, is built to scale – but not necessarily to serve the needs of the average merchant or solo dev.

And the more complicated things get, the more merchants are pushed into hiring Shopify Partners or relying on apps to bridge the gap.

(Both things that funnel money straight back into Shopify’s pockets…… strange?)

The result:

• Slower stores (thanks to bloated apps)

• Higher cost of ownership

• Less control for merchants

• More frustration for devs trying to help

Modern Dev Is Weird Now

One last gripe: it’s wild that we’ve come full circle…

Back to vanilla JS and vanilla CSS – after spending years building tools to make development easier.

Remember when we celebrated things like jQuery, Sass, Vue, or React because they simplified complexity? Now we’re told that writing native, unopinionated code is the “right” way. But in practice, it’s just harder to work with…

Web components sound great in theory, but in reality? Well frankly, I didn’t think I’d have to define classes to get a Shopify store working in 2025.

The main focus for 99.9% of merchants is building a high-converting storefront, and being able to move things around and test as needed.

That need clarity, speed, and control is where a proper WYSIWYG editor would be amazing, but Shopify seems to have no intentions of building one.

So yes, I’m sticking with Tailwind and a build process for now.

TL;DR

• Dawn has solid bones but awful developer experience.

• Tailwind makes it bearable – and even enjoyable – if you break a few rules.

• Shopify is shifting toward enterprise, leaving SMBs to fend for themselves.