Comparison: Bulma, Picnic, Tailwind
Krysalicss is closest to Bulma in spirit and Picnic in restraint. It is not a Tailwind alternative. This page locates Krysalicss on the existing map and explains the choices that distinguish it.
The three axes
A useful way to compare CSS frameworks is along three axes: how opinionated the visual baseline is, how granular the selector vocabulary is, and how much JavaScript the framework requires.
| Framework | Opinion | Granularity | JavaScript | Theming |
|---|---|---|---|---|
| Tailwind | None: utilities only | High: one class per declaration | None at runtime; required at build (PostCSS plugin) | Build-time configuration |
| Bootstrap | Strong | Component-level | Required for some components | SCSS variables + CSS custom properties (5.x) |
| Bulma | Strong | Component-level | None (CSS-only by design) | SCSS variables + CSS custom properties (1.x) |
| Picnic.css | Strong, minimal | Component-level, very small | None | SCSS variables; no runtime theming |
| Krysalicss | Strong | Component-level, opt-in per module | None | CSS custom properties as the contract; runtime-switchable |
vs. Bulma
Krysalicss inherits Bulma's class semantics (.button, .card,
.title, .is-primary) and its SCSS-native authoring style. Bulma 1.x
added CSS custom properties for theming, which closed most of the
runtime-switching gap.
Where Krysalicss diverges:
- Strict opt-in. Bulma's feature gating is partial; you can drop
categories but not always individual components. Krysalicss gates every
component behind a flag, and the entry file propagates one
$feature-listto all of them. - Theme contract enforced at compile time. A Krysalicss theme that omits a required token raises a Sass error. Bulma defers to runtime: a missing variable produces an unstyled element instead of a build failure.
- Smaller surface. Bulma ships forms, navbars, modals, tabs, breadcrumbs, panels, etc. Krysalicss ships a deliberately narrower set and will not match Bulma's breadth.
vs. Picnic.css
Picnic is the closest match philosophically: small, opinionated, no JS, SCSS-authored. The difference is theming: Picnic has no runtime theme switching and no token contract. Adding dark mode means recompiling.
Krysalicss treats themes as a first-class concern: the
theme/_create.scss factory is a documented public API, and the docs
site demonstrates the pattern. If you'd reach for Picnic for a small
marketing site or internal tool but want dark mode for free, Krysalicss is
the closer fit.
vs. Tailwind
Tailwind solves a different problem. It is a utility framework: the
selector vocabulary is at the declaration level (p-4, text-sm,
bg-blue-500), not the component level. Components are something you
compose in your application code, not something the framework ships.
The two are not interchangeable. If your team has built a workflow around utility classes (Headless UI, Radix Themes, shadcn) Krysalicss will feel obstructive. If your team writes SCSS or wants to author components in their HTML markup with named classes, Tailwind will feel obstructive.
The honest answer to "should I use Tailwind or Krysalicss?" is: pick the one whose authoring style you already use. Switching to either from the other costs more than the kilobytes you save.
When to pick Krysalicss
- You ship marketing sites, dashboards, or internal tools and want a finished baseline you refine, not a blank canvas.
- You want first-class light + dark with runtime switching and no JavaScript framework.
- Your team is comfortable with SCSS or willing to add
npx sassto the build. - You author web components and need a stylesheet that re-scopes cleanly to a shadow root.
When not to pick Krysalicss
- You're committed to a utility-first workflow.
- You need IE11 or pre-2023 evergreen browser support (we use
:has(),<dialog>, and container queries). - You need a JS-driven component library: modals with focus trapping baked in, autocomplete, drag-and-drop. Krysalicss won't ship those.