Lily Design System and DaisyUI — Lily Design System

DaisyUI is a Tailwind CSS plugin that gives you finished, styled components through class names such as btn and card, while Lily ships framework components with no CSS and keeps its themes in separate stylesheets. This matters because daisyUI decides how your interface looks and leaves behaviour to you, whereas Lily decides markup, keyboard behaviour and accessible names and leaves the look to you. Choose daisyUI when you already use Tailwind and want a good-looking interface quickly; choose Lily when you want the same accessible components across several frameworks without adopting a CSS framework.

A Tailwind plugin with styled class names versus components with no CSS

DaisyUI is installed as a Tailwind plugin. Its install page says you need Node.js and Tailwind CSS, then run npm i -D daisyui@latest and add @plugin "daisyui"; after @import "tailwindcss"; in your CSS. Its own llms.txt tells an AI agent to use Tailwind CSS 4 with daisyUI 5. What you write is ordinary HTML with class names; the Button page lists btn with colour, style, size and modifier classes such as btn-primary, btn-outline, btn-sm and btn-wide. Its home page says "Pure CSS. No JS dependency" and counts 68 components and 600+ utility classes.

Lily's headless libraries ship no stylesheet at all. A component gives you the most specific semantic element, a stable kebab-case class hook such as button or breadcrumb-nav, ARIA, and focus and keyboard behaviour; the visual decisions are yours. The root specification rules out a Tailwind dependency or utility classes. The consequence is practical: with daisyUI, adding one class gives you a finished button; with Lily, you get the right element and behaviour and must supply, or choose, the styling. Lily does ship styling as a separate, optional layer: the example apps and 63 reference theme stylesheets.

DaisyUI is also easier to use outside a build step in one respect: its CDN page describes a plain stylesheet link (the full daisyui.css is stated as 63kB compressed, plus the Tailwind browser script), and it documents include, exclude and prefix options so you can ship only some components. Lily has nothing equivalent yet: each theme file carries the whole component stylesheet, and its own review of daisyUI lists a build-only-what-you-use slicer as planned, not built.

How themes work: token-only on data-theme versus separate stylesheets

In daisyUI, themes are sets of CSS variables. Its themes page says light and dark are enabled by default, themes: all enables all 35 built-in themes, and a theme is applied with data-theme="name" on <html> or on any element, with unlimited nesting. A custom theme is a daisyui/theme plugin block that sets --color-* variables plus radius, size, border, depth and noise values; there is also a theme generator on the site. The components themselves come from one shared stylesheet, so a section of a page can be switched to another theme.

Lily's themes descend from daisyUI's. Lily's own review records that 35 of its 63 themes/ files are daisyUI-derived and credited in their headers, and the rest cover NHS England, Scotland and Wales variants, GOV.UK, USWDS, Carbon, Fluent, Primer and others. The difference is structure. Each Lily theme file carries its token block and then the component rules for the whole catalog, and selects the document root, so a theme applies to the whole page, not to a subtree. The review measured every file at about 134 KB with an identical component section. Splitting this into one shared component sheet and token-only theme files, so themes can be scoped and nested as daisyUI's can, is item 1 of that review and is unchecked; nothing in the repo shows it built.

Lily does have a runtime theme picker helper that swaps the stylesheet and sets data-theme in eight frameworks. DaisyUI's themes page describes a theme-controller approach and CSS-only switching; this page did not document a persistence mechanism, so do not assume either way.

Framework coverage and what JavaScript behaviour you get

DaisyUI says it is "Framework agnostic" and "Works on all frameworks", and its install page links guides for Vite, Next.js, Nuxt, Astro, Laravel, Rails, Django, Angular and WordPress, among others. That works because it is only CSS: you write the markup yourself in whichever framework you use. The trade-off appears in the component pages. The modal page says the recommended native <dialog> is opened with ID.showModal(), so JavaScript is required for that variant; the popover and legacy checkbox variants need none. Its llms.txt says the countdown "requires JavaScript to update the text" and the calendar needs a third-party library (Cally, React Day Picker or Vanilla Calendar Pro).

Lily ships the same 607-component catalog as real components in seven framework libraries (HTML, Svelte, React, Vue, Angular, Blazor, Nunjucks), a Web Components library that covers 572 of the 607 components it was built for, and Alpine.js markup snippets with one plugin. Focus, open and closed state and keyboard movement are part of the components, not something you wire up. The cost is that you adopt a component library in a specific framework, and Lily's count is larger than daisyUI's partly because it includes things daisyUI does not try to be, such as 164 national identifier inputs and viewers and chart components.

Accessibility and keyboard behaviour

DaisyUI does not make accessibility its headline: the home page makes no explicit accessibility claims. Where its component pages speak to it, they are specific and honest. The modal page says the native dialog "is accessible" and closes with Esc, while the legacy checkbox and anchor variants have no Esc support or background locking, and the page does not document focus trapping, focus return or ARIA beyond role="dialog" in legacy examples. The dropdown page describes a focus-based dropdown on a div with tabindex="0" and role="button", closing "when focus is lost", and does not document arrow-key navigation or Escape. The Button page explains that btn-disabled is only visual and must be paired with tabindex="-1", role="button" and aria-disabled="true".

Lily targets WCAG 2.2 AAA and follows WAI-ARIA Authoring Practices for keyboard patterns, with a documented keyboard contract per component. Be clear about what that means: Lily has never been independently audited, runs automated axe-core checks, and its own COMPARE.md says it has shipped green test suites over real defects. DaisyUI has not been audited either as far as these pages state. The honest reading is that Lily is built around keyboard and ARIA behaviour as its main job while daisyUI leaves much of it to you, but neither offers a conformance statement.

AI tooling: Blueprint, a skill and llms.txt versus a link map

DaisyUI is well ahead here. Its home page lists an llms.txt, a UI design MCP server called Blueprint, a UI design agent skill and plugins for several coding assistants. Its llms.txt is not a link map but a very long skill file with rules for an agent, including to use only current class names and semantic colours and to use primary once per page. Each component page offers Open in ChatGPT, Open in Claude, a Markdown version and the raw CSS source. Blueprint is a paid product: its page lists $22 per month, $45 per quarter and $600 lifetime, with six tools run in a fixed order.

Lily publishes an llms.txt and llms.json as a curated map of the project, Claude skills for each framework layer, and per-component Markdown on its docs site. Lily's review of daisyUI lists a rules file, per-page AI links and a read-only MCP server as planned work, and its acceptance criteria for them are unchecked. A search of the repo finds no MCP server script and no .mcp.json, so Lily has no equivalent of Blueprint today. Lily's would be free and read-only if built.

Size, licence and maintainers

The daisyUI home page lists 68 components, 35 themes and 600+ utility classes. The GitHub licence file begins "MIT License" with "Copyright (c) 2020 Pouya Saadeghi", although the home page links the licence without naming it. The repository page shows about 42.7k stars, and the site credits Pouya Saadeghi as creator, says it is built by the community and links sponsors. It is a mature, widely used project with a large community.

Lily lists 607 components in its catalog, 63 themes and one maintainer, with a first commit in August 2025. Its licence is a multi-licence SPDX expression (MIT, Apache-2.0, GPL-2.0-only, GPL-3.0-only or BSD-3-Clause), and it has no plugin ecosystem or community to speak of. In Lily's own 429-row survey of component equivalents, 194 rows match a daisyUI component, the most of any system compared; Lily scores 429 of 429 by construction, because the survey is built from Lily's catalog. That tells you daisyUI covers much of the same ground, not that the two are equal in maturity.

Sources

All comparisons