Bulma vs. daisyUI: One Card, Measured at 65.2 KB, 6.4 KB and 2.5 KB

Bulma is a standalone CSS framework you link and use; daisyUI is a Tailwind plugin that adds component classes to a build you already run. Both give you button and card as class names. The difference that decides it is granularity: asked for one card, Bulma shipped 65.2 KB gzipped, daisyUI 6.4 KB, and plain utilities 2.5 KB. Those are measured numbers, below.

The short answer

Pick Bulma when you want a complete design system with no build step — a <link> tag and semantic classes, Sass optional. Pick daisyUI when Tailwind is already compiling your CSS and you want component-shaped classes instead of utility strings. Pick neither if the project already has its own components and token scale, because both bring a second one.

The vendor's own comparison page puts Bulma at 20 components against daisyUI's 65, and Bulma's two themes against daisyUI's 35. Treat those as daisyUI's framing of its own advantage — they are counts of inventory, not of what you ship.

The measurement

Everything below ran today in one scratch directory: npm install bulma@latest daisyui@latest tailwindcss@latest sass, resolving to Bulma 1.0.4, daisyUI 5.7.47, Tailwind 4.3.3, sass 1.105.1. The target was one card — a title, two buttons, an email input and a badge.

The daisyUI version:

<div class="card bg-base-100 shadow-xl">
  <div class="card-body">
    <h2 class="card-title">Pricing</h2>
    <button class="btn btn-primary">Buy</button>
    <button class="btn btn-outline">Preview</button>
    <input type="email" class="input input-bordered" />
    <div class="badge badge-secondary">New</div>
  </div>
</div>

Compiled through Tailwind's CLI with nothing but that file as content:

$ npx @tailwindcss/cli -i daisy.css -o daisy.built.css --content src/daisy.html --minify
/*! 🌼 daisyUI 5.7.47 */
Done in 210ms

The last row is the one that reframes the others. The whole of this marketplace — 92 components, 762 prerendered pages, home, pricing, docs, blog, 111 product pages — ships 14.5 KB of gzipped CSS. That is less than a quarter of what Bulma's precompiled file costs before you have written any markup at all.

Why Bulma's number is so large, and how to make it small

Bulma's default distribution is the entire framework. bulma.min.css is every component, every helper, every colour modifier, whether or not your page has a navbar. There is no content-aware step in the pipeline, because there is no pipeline — that is the appeal.

The Sass source is the escape hatch, and it works:

@use "bulma/sass/base";
@use "bulma/sass/elements/button";
@use "bulma/sass/form";
@use "bulma/sass/themes";

$ npx sass --no-source-map --style=compressed --load-path=node_modules subset.scss subset.out.css

65,219 bytes gzipped becomes 25,349 — a 61% cut from four @use lines. Bulma vs. Sass is the whole of that decision; the short version is that Sass is not Bulma's alternative, it is Bulma's granularity knob.

Two things to know before relying on it. The subset still carries themes, and not for tidiness: Bulma 1.x components resolve their colours through a chain that bottoms out at --bulma-scheme-main and its lightness siblings, which only the themes file declares. Omit it and a button keeps every geometry variable it needs — --bulma-control-radius and --bulma-button-h are declared by base and the button file themselves — while its background and border colours resolve to nothing. The result is a correctly sized, colourless button, which is a more confusing failure than an unstyled one. And the compile is noisy on sass 1.105.1:

DEPRECATION WARNING [if-function]: The Sass if() syntax is deprecated in favor of the modern CSS syntax.

Repeated across the build. It is Bulma's own source, not yours, so it is not a warning you can fix — only one you agree to see.

Why daisyUI's number is 6.4 KB and not 2.5 KB

daisyUI is content-aware in the way Tailwind is — it emits the components your markup names. The card above pulled in card, btn, input and badge and nothing else. So where does the gap to hand-written utilities come from?

The theme layer. daisyUI's components are written against semantic variables (--color-base-100, --color-primary and their siblings), and that variable layer is emitted whole, because any component might reference any of it. You pay for the design system once, then each component is cheap. Hand-written utilities have no such layer: bg-indigo-600 compiles to one rule with a literal colour in it.

Which is the better deal depends entirely on how many components you have. Six components in, daisyUI is behind by 3.9 KB. Sixty components in, the fixed cost has amortised and the per-component delta is what matters. On a marketing site with one card, daisyUI's theme layer is most of the download; on an application with sixty screens, it is a rounding error.

Where this codebase actually landed

Neither, and the reason is not byte count.

src/app/globals.css is 133 lines. Its @theme block declares 41 custom properties — a primary scale from 25 to 950, the TailAdmin gray scale, and semantic tokens like --color-text-color and --color-title-color. There are zero @plugin lines in the file and zero .scss files in the repository. Those 41 declarations are the entire design-token layer, and they are what every one of the 92 components in src/components is written against.

/* src/app/globals.css */
@theme {
  --color-primary: #465fff;
  --color-primary-600: #3641f5;
  --color-gray-900: #101828;
  /* …41 declarations total */
}

Adopting either library would mean running two token systems at once. src/components/atoms/Button.tsx is the concrete case — three variants, composed from those tokens:

const variants: Record<ButtonVariant, string> = {
  primary: "bg-primary text-white hover:bg-primary-600",
  outline:
    "border border-stroke-tertiary bg-white text-text-color hover:bg-gray-50 hover:text-gray-800",
  dark: "bg-gray-900 text-white hover:bg-gray-800",
};

btn btn-primary would give the same three variants for less markup — and btn-primary would resolve to daisyUI's primary, not --color-primary: #465fff. The reconciliation cost that creates is the Chakra UI vs. daisyUI post's subject and it does not get cheaper here. Bulma's version of the same problem is worse, because its classes are not Tailwind's at all: is-primary and bg-primary would compile through two different pipelines into two different stylesheets.

The atom also does something no class library can hand you: its disabled branch renders a <span role="link" aria-disabled="true" tabIndex={0}>, because HTML has no disabled anchor and three call sites had each improvised a different tab order. That fix lives in a component, not in a class name. It is the clearest argument for owning the component layer that this repository has.

The defect to know about either way

Both libraries are configured from globals.css — daisyUI with @plugin "daisyui";, Bulma's custom properties in whatever layer you put them. Tailwind v4 with Turbopack does not hot-reload changes to @theme or @plugin. Edit a token, see nothing, conclude the plugin is broken. Restart npm run dev. This cost real time here before it became a line in CLAUDE.md, and it is the first thing to check when daisyUI classes appear to do nothing after install.

Mistakes and troubleshooting

Frequently asked questions

Is daisyUI always smaller than Bulma? For anything short of a very large component inventory, yes — measured above at 6.4 KB against 65.2 KB gzipped for the same card, because daisyUI emits only the components your markup names while Bulma's default build is the whole framework. Bulma compiled from a Sass subset closes the gap to 25.3 KB but does not cross it.

Can I use daisyUI without Tailwind? No. It is a Tailwind plugin and compiles through Tailwind's pipeline. Bulma is the option when you do not want a build step at all.

Does either one ship JavaScript? Neither does. Bulma documents that interactivity is yours to write; daisyUI's components are CSS classes. For a Server Components codebase that matters, and it is why both are architecturally cheaper than a React component library.

Should I migrate a Bulma project to daisyUI? Only alongside a move to Tailwind, since daisyUI needs it. The class names do not map one-to-one — is-primary against btn-primary — so this is a rewrite of markup, not a find-and-replace of a stylesheet.

Why does this codebase use neither? 41 @theme declarations and 92 components already in place. Adding a component library would add a second token scale to reconcile for component classes we would not get to write anyway, and the whole stylesheet is 14.5 KB gzipped — there is no byte-size problem for either to solve.

Templates in this post

ASoc Fade is a traditional-barbershop site — services, a full price list, a barber team and booking, plus a small grooming shop — the component-dense page where a card library's inventory looks most tempting. ASoc Fiscal is a financial-platform marketing site with payments, invoicing and a tabbed feature showcase, where the tab interactivity is exactly the JavaScript neither library ships. ASoc Flow is a workflow-automation SaaS landing page built around a hub preview and a visual flow builder, whose custom layout is the case against semantic component classes.

Browse the full sets: Next.js landing page templates, Tailwind landing page templates.