Ask a coding agent for a dashboard in a library its training data barely saw, and one of two things happens: it quietly switches to the popular library it has seen a million times, or it stays loyal and invents props that don't exist. We fought that with agent skills, playbooks that teach an agent our library. This is the story of what came after: proving the skills actually work, then making them better the way evolution would, just faster.

The fight itself is quick to retell. bestax is our React component library for Bulma, young enough and niche enough that no model's training data carries it properly. Whatever is over-represented gets recommended, recommendations compound, and a library outside that flywheel barely exists to an agent; even a model that has met bestax has met an old bestax, frozen at its training cutoff. I made the long version of that argument in Fighting AI Training Bias, along with everything we ship to counter it: docs a machine can read whole, a complete component catalog, and seven agent skills. What that post couldn't answer was the question that matters: do the skills actually make agents better? This one is about how we found out, and what we did with the answer.

Skills in the Wild​

A skill is a folder of instructions and reference files a coding agent loads before it works. Documentation tells an agent what exists; a skill tells it how we actually build things. bestax ships seven: page layouts, forms, theming, icons, custom components, CSS optimization, and migrating off an older Bulma library.

They aren't an internal experiment, either. Every app scaffolded with npm create bestax@latest gets the bundle preinstalled, and npx skills add installs any of them into an existing project. That makes them a product, and products meet reality: people install them, hit the gaps, and file them as bugs. Good. A skill that teaches a wrong pattern is worse than no skill at all, because it teaches that mistake to every agent that loads it. It's why skill bugs get a particular kind of fix around here: repair the guidance that produced the bad output, not just the example that exposed it.

But bug reports only tell you where a skill failed someone. They can't tell you whether the skills work at all. For that, we built an exam.

The Exam: Cold-Start Runs​

You can't ask an agent whether the skills helped. You have to strip everything away and watch one work. One run of our harness goes like this:

• Scaffold a brand-new app with the current tooling: the seven skills plus the small rules file the scaffolder writes.
• Hand a frozen brief (build this SaaS marketing site) to a cold-start agent session: fresh directory, no project history, empty memory, the library installed from the public registry. Exactly what a stranger's agent sees on day one.
• Measure the result by machine: did it build, how many type errors, how many inline styles, how many raw CSS classes where a component prop existed, how many hand-rolled widgets, which skill files the agent actually opened.
• Have a separate grader agent score it against a frozen 100-point rubric, under one hard rule: the machine-measured numbers are ground truth the grader may not contradict.

My favorite part is the gate at the very top of the rubric, a specific kind of paranoia. An untouched scaffold typechecks, builds, and reports zero inline styles, zero invented props, zero hand-rolled widgets. Graded naively, an agent that does nothing collects 50 of 100 points. So before anything is scored, the harness checks whether the agent modified the app at all, and zeroes the run if it didn't. Doing nothing is a failed exam, not a clean sheet.

Accelerated Evolution​

One exam gives you a score. The interesting move is running it as a loop, because the loop is evolution with the waiting removed.

Evolution needs three things. A fixed environment: the brief, the rubric, the model, and the budget caps stayed frozen for the whole experiment. Variation: after each run we read the scorecard and revised the tooling, the skills, the generated rules file, the component catalog, then rebuilt. Selection: a fresh cold agent took the same exam against the revised tooling, and revisions that didn't survive the grading didn't stay. We ran ten generations that way and wrote everything down, scorecards and metrics per run.

The score rose while the cost of earning it fell 43% and the turn count fell 38%. Better guidance doesn't just produce better apps; it produces them with less thrashing.

Two disciplines kept the selection honest. The yardstick never moved: improvements went into the tooling, never into the brief or the rubric, or the generations stop being comparable. And the graders got audited: three of the ten scorecards contained a factual error, caught by checking them against the run transcripts before anything acted on them. After the last generation, a compare-only pass confirmed the gains without shipping anything unvalidated.

One lesson from those generations transfers to anyone writing guidance for agents: placement beats content. Facts that lived on surfaces the agent always loads held in every generation that followed. Facts one reference-hop away failed randomly, even when the agent read the pointer to them. If an agent must know something every time, put it where the agent already is.

And that's what "accelerated" means here. The slow version of this loop exists everywhere: ship guidance, wait months for bug reports, fix, wait again. Model training is slower still; a fix in our skills reaches agents today, while a fix in training data doesn't reach them until the next model ships. The loop compresses a feedback cycle we don't control into one we run on a schedule, ten generations for the price of a script.

Runs You Can Watch​

Numbers convince maintainers. Seeing convinces everyone else. Our Storybook has a Skills section where the showcases are agent-generated: each skill's canonical example was built by an agent following that skill, and it renders live next to the components themselves. Every example opens with a small header recording exactly what produced it: the skill, the prompt, the model, and the date. The current set lists two different models, because the record keeps what actually ran. It's the exam at eye level: prompt in, rendered page out, replayable with your own eyes.

Holding the Line Between Generations​

Evolution only accumulates if survivors don't quietly regress between generations, so the daily machinery guards the skills the way it guards the library code.

Every skill change goes through the same adversarial review as a component change: two AI reviewers pick at it and a human does every merge (that pipeline is its own story). The icons and optimization skills landed that way, and so did the dark-mode contrast rules in the theming and layout skills.

The build itself also fails when the skills drift from the library:

• The component catalog agents read is generated from the docs, and CI fails on any diff, so the list is complete and current on every commit. A component the catalog can't see is a component an agent will rebuild.
• The theming skill's inventories must name every themable component and CSS variable the library registers. Add a themable component without updating the skill, and the build says no.
• A house rule with teeth: a library change that invalidates skill guidance updates the skill in the same pull request, always.

None of that replaces the loop. It keeps the loop's winnings from eroding while nobody's looking.

Still Evolving​

A working loop's best output isn't the score; it's the to-do list. The ten generations filed real bugs and gaps, open right now: color props that typecheck values with no shipped styles, a form label never wired to its input for screen readers, no clean route to a scheme-aware background in dark mode, casing traps like isFullWidth on one component and isFullwidth on another, and scaffold rough edges an agent shouldn't have to route around. I like that list more than I like the 95.2. Agents tripped over these in a test chamber so users don't have to in production.

The honest limits, straight from the harness's own docs: one brief, one model, ten runs, and single-run scores swung by six points on identical tooling, so one run is one sample and trends need several. That's fine. The yardstick is built, the baseline is recorded, and the next loop starts where this one stopped: swap the brief or the model, freeze everything else, and evolve again.

That's the whole story. Training bias made our library invisible to agents, so we made it legible and taught the technique with skills. The exam made the skills provable. Accelerated evolution keeps making them better. If you want the skills in your own agent, the last post has every entrypoint, and the tracker is where the next generation lands.

A coding agent can't one-shot a library its training data barely saw. Ask one for a dashboard in an under-represented library and you get one of two failures: it quietly reaches for the incumbent it has seen a million times, or it stays loyal and invents props that don't exist. bestax's answer is to make the real, current API machine-legible so one shot is enough, and this post is everything that ships today.

This is post six of the catch-up series (tracker). The v5 recap closed out the release backlog; this one explains where the AI effort has been going. The title says training bias. That's my word for it, not the repo's, and I already argued the case at length in July: what's over-represented gets recommended, recommendations compound into monoculture, and nobody compares two options anymore. I'm not re-arguing it here. This is the build log.

Start with the staleness math. Avatar and Badge shipped July 10. Dot-notation sub-components landed across every parent component on July 20. What does a model trained in the spring know about a component that shipped July 10? Nothing, and that's the good case: even a model that has met bestax has met a bestax that no longer exists. Under-represented and stale, at the same time. The bestax homepage has an AI-Ready section, "Bring Bestax to your AI tools," with three cards: LLM-ready docs, Agent skills, and an MCP server marked coming soon. This post is those three cards in order, with receipts.

Machine-Readable Docs​

Every page of the bestax docs ships in a form a model can read whole. The site build regenerates three artifacts on every deploy:

• llms.txt, a curated index of the docs, small enough to pin in your project rules
• llms-full.txt, the entire documentation as one file
• a Markdown twin of every page: append .md to any docs URL, like bestax.io/docs/api/elements/button.md, when you want one component in a small context

The LLMs guide pitches the big one with a line I didn't have to write for this post: "Feed it everything. For a one-shot load of the whole library." The docs already speak this vocabulary, because the artifact exists for exactly this reason: a single context load standing in for what training never contained. And because the artifacts regenerate on every build, they can't drift behind the deployed site. There's no stale window between what the docs say and what the model reads.

Agent Skills​

Docs give an agent knowledge; skills give it technique. That distinction took me a while to respect. With llms-full.txt in context an agent knows every prop of every component, and it will still open a layout task with four clarifying questions, or validate a form the way its favorite form library does. Knowing the API and knowing the house way to use it are different things.

A skill is a folder with a SKILL.md of instructions the agent always loads, plus deeper references it reads on demand. bestax ships seven:

• bestax-layout-scaffold: scaffold a complete, responsive page, from app shells and marketing pages to auth screens and card-grid catalogs
• bestax-form: Field and Control composition, the whole input set, and the validate-it-yourself pattern
• bestax-theming: brand colors, tokens, and dark mode through --bulma-* variables
• bestax-custom-component: build beyond stock Bulma without leaving the bestax style
• bestax-icons: Icon and IconText across the five supported icon libraries
• bestax-optimize: measure the built CSS, then shrink it with the cheapest lever that fits
• bestax-migrate: move an app off react-bulma-components with the codemod, then resolve every TODO it leaves

My favorite sentence in any of them is a behavioral rule in the layout skill: "Select an archetype from the request and build it in one shot." The same rule forbids asking layout questions. That's the thesis of this post with a lint rule attached. And yeah, skills really are cartridges: snap one in and the agent knows moves it didn't know a minute ago.

Two Ways to Install​

Channel one is the skills CLI:

npx skills add https://github.com/allxsmith/bestax --skill bestax-layout-scaffold

The same command takes any of the seven names, or drop the --skill flag to pick from a list.

Channel two is the scaffolder. pnpm create bestax@latest offers to preinstall the skill bundle into the new app's .claude/skills/, and while it's in there it writes two more files: a .claude/launch.json so an agent's browser preview can boot the dev server by name, and a CLAUDE.md recording the choices the scaffolder just made (CSS flavor, class prefix, icon library). The agent never has to rediscover the setup it was born into.

Don't Reinvent: The Component Catalog​

The most expensive agent failure isn't a wrong prop; it's a rebuilt component. A wrong prop fails loud, in the console or the type checker. A hand-rolled tooltip works, looks almost right, ships, and is quietly yours to maintain forever.

So the custom-component skill leads with a generated catalog whose header states its job: every documented component, "so you don't reinvent one that already exists." All 87 components fit in 149 lines, names and one-line purposes only, each linked to its full API page. It's lean on purpose, cheap to hold in context, with the full prop tables one fetch away.

The part I care about most is the guard behind it. The catalog is generated from the API docs, and CI fails if any exported component lacks an API page. A component the catalog can't see is a component an agent will rebuild, so completeness isn't a habit here. It's a build gate. The list the agent reads is guaranteed complete on every commit.

I've watched an agent lovingly hand-roll a tooltip while Tooltip sat one import away, shipped and tested and documented. Small heartbreak, nobody's fault: to a model with a stale snapshot, some of these 87 components simply don't exist. The catalog is how they exist again. Here's the kind of thing that's already in the box:

<Block>
  <Tooltip label="Shipped, tested, one import away">
    <Badge dot color="success" overlap="circle">
      <Avatar name="Ada Lovelace" />
    </Badge>
  </Tooltip>
</Block>

A Tooltip, a Badge, and an Avatar, composed instead of hand-rolled.

Meeting Agents in node_modules​

Some agents never fetch a URL; they read what's on disk. Since 5.8.0, the published npm tarball carries three pointer files at the package root, llms.txt, AGENTS.md, and CLAUDE.md, named for the filenames agent tooling probes first, "so agents exploring node_modules land on these resources by filename," as the package README puts it. They're pointers, not documentation: each is a short signpost back to the site artifacts above, which stay the single source of truth, so nothing in the tarball goes stale between releases. Network context, project context, and now the filesystem itself. The LLMs guide lists exactly what ships.

What's Next: The MCP Server​

The third AI-Ready card says coming soon, and it means it. A first-party MCP server is planned: a Model Context Protocol endpoint an agent can query for component props, variants, and live examples while it builds. It isn't shipped, the homepage card deliberately has no link, and this post won't describe software that doesn't exist. When it ships, it gets its own post.

The nearer sequel is live: the accelerated evolution loop that keeps those seven skills honest. The tracker has the rest of the plan.

Point Your Agent at It​

Pick whichever entrypoint matches your setup:

• In an existing app: paste https://bestax.io/llms.txt into your project rules, or point the agent at the LLMs guide.
• For the technique, not just the API: npx skills add any of the seven skills.
• Starting fresh: run pnpm create bestax@latest and say yes when it offers the skills.

And if bestax makes your agent sharper, a star on the repo is the whole marketing budget.

You don't fight training bias by arguing with the weights. You hand the agent the current docs, and you let one shot be enough.

A form in bestax-bulma is plain React: state goes in, props come out, and nothing new sits in between. There's no bundled form library and none is coming; the library's job ends at rendering Bulma correctly, so your form state stays yours. By the end of this post you'll have a validated signup form built with nothing but useState, you'll see where the validation library of your choice plugs in, and you'll know where every escape hatch is.

This one's part of the catch-up series, but it's a design post, not a release recap. The components here shipped across v2 and the v3 forms release; what follows is how they're meant to be used together.

Field, Control, and Auto-Wrap​

Bulma builds every form the same way: a field div handles layout and the label, a control div wraps exactly one input and owns its icons and loading spinner, and an optional help paragraph carries the message. Our Field and Control components render exactly that structure.

Writing three wrappers for every input gets old fast, so the convenience inputs handle it. Input, Select, and TextArea wrap themselves in a Field and Control automatically, which is what lets props like label, iconLeftName, and message exist on a single tag:

function AutoWrapDemo() {
  const [email, setEmail] = useState('');

  return (
    <Input
      label="Email"
      type="email"
      placeholder="you@example.com"
      value={email}
      onChange={e => setEmail(e.target.value)}
      iconLeftName="envelope"
      message="One tag, and you get the label, the icon, and this help text."
      id="autowrap-email"
      labelProps={{ htmlFor: 'autowrap-email' }}
    />
  );
}

To be precise about the mechanics: the wrapping isn't triggered by those props. A convenience input always wraps itself unless it detects it's already inside a Field or Control, and label and friends just forward into the generated wrapper. The field-level props are shared across inputs (label, labelSize, labelProps, horizontal, message, messageColor, and fieldClassName), with messageColor tinting the help text.

One accessibility note: label now wires the <label> to the input on its own (a generated id plus htmlFor, or your own id if you pass one), and composing a Field around a single base input gets the same treatment. The demos on this page wire it explicitly, which still works and is the way to go when you want a stable id; on library versions before this shipped, it was required.

Skip-If-Wrapped​

Write the wrappers yourself and the inputs get out of the way. Here's the detection mechanism, from FormContext.tsx:

const FieldContext = createContext(false);
const ControlContext = createContext(false);

export const useInsideField = () => useContext(FieldContext);
export const useInsideControl = () => useContext(ControlContext);

That's it. Field and Control each set their context to true, and an input checks both hooks before wrapping. Presence detection, not state: no values flow through this context, it only answers "am I already wrapped?" So composed layouts and convenience inputs mix freely. This is the same Input from the demo above, dropped into an addons layout:

function SearchDemo() {
  const [query, setQuery] = useState('');

  return (
    <Field hasAddons>
      <Control isExpanded>
        <Input
          placeholder="Search the docs"
          aria-label="Search the docs"
          value={query}
          onChange={e => setQuery(e.target.value)}
        />
      </Control>
      <Control>
        <Button color="primary">Search</Button>
      </Control>
    </Field>
  );
}

If Input had wrapped itself again, that button wouldn't sit attached to the field. And because useInsideField and useInsideControl are public exports rather than private internals, a custom input of your own can join the same protocol; the group components (Radios, Checkboxes) already ride on it.

The Base Escape Hatch​

Sometimes you want zero magic. Six components ship as raw versions with a Base suffix: InputBase, SelectBase, TextAreaBase, DateInputBase, TimeInputBase, and DateTimeInputBase. They render the bare Bulma element and never wrap themselves in anything:

// Convenience: one tag, wrappers included
<Input label="Email" message="We only email for receipts." />

// Composed: you own every element
<Field label="Email" labelProps={{ htmlFor: 'composed-email' }}>
  <Control>
    <InputBase id="composed-email" type="email" />
  </Control>
  <p className="help">We only email for receipts.</p>
</Field>

Reach for composition when one field holds several controls, when you're building addons or grouped layouts, or when your markup needs to be exact for a snapshot test or a CSS framework migration. The form guide shows both styles side by side.

Validate It Yourself​

Validation is the part the library deliberately leaves to you, and the pattern is short: own the value with useState (or useReducer, or whatever you prefer), compute the error yourself, and reflect it through the input's color, message, and messageColor props.

function SignupDemo() {
  const [email, setEmail] = useState('');
  const [touched, setTouched] = useState(false);
  const [sent, setSent] = useState(false);

  const valid = /^[^@\s]+@[^@\s]+\.[^@\s]+$/.test(email);
  const error =
    touched && !valid ? 'Please enter a valid email address.' : undefined;

  return (
    <form
      onSubmit={e => {
        e.preventDefault();
        setTouched(true);
        setSent(valid);
      }}
    >
      <Input
        label="Email"
        type="email"
        placeholder="you@example.com"
        value={email}
        onChange={e => {
          setEmail(e.target.value);
          setSent(false);
        }}
        onBlur={() => setTouched(true)}
        color={error ? 'danger' : undefined}
        message={error}
        messageColor={error ? 'danger' : undefined}
        iconLeftName="envelope"
        id="signup-email"
        labelProps={{ htmlFor: 'signup-email' }}
      />
      <Button color="primary" type="submit" mt="3">
        Sign up
      </Button>
      {sent && (
        <Notification color="success" isLight mt="4">
          Signed up. Your state, your rules, no library required.
        </Notification>
      )}
    </form>
  );
}

Type something that isn't an email and tab away: the border goes danger and the message appears, because the component reflects exactly the state you computed. One gotcha worth knowing: validation state belongs on the input, not the Field. Field has no message prop, and although its types accept a color, it renders no class for it, so setting it looks right and does nothing.

The demo's validation is one regex and one ternary. A form used to be an input and an if statement, and it turns out it still can be.

And if you'd rather keep using react-hook-form, or validate with zod or yup? Bring them. The pattern above isn't a lock-in, it's a socket: the text-style inputs are controlled components with a value, an onChange, and a string-friendly message, which is exactly the surface a validation library produces. Prop shapes vary at the edges (the boolean controls take checked, and Autocomplete speaks value, onInput, and onSelect), so wire into each component's documented props and everything here still applies. Here's the same field with its error coming from a zod schema instead of a regex:

import { z } from 'zod';

const schema = z.object({
  email: z.string().email('Please enter a valid email address.'),
});

function ZodSignup() {
  const [email, setEmail] = useState('');
  const [touched, setTouched] = useState(false);

  const result = schema.safeParse({ email });
  const error =
    touched && !result.success ? result.error.issues[0].message : undefined;

  return (
    <Input
      label="Email"
      type="email"
      value={email}
      onChange={e => setEmail(e.target.value)}
      onBlur={() => setTouched(true)}
      color={error ? 'danger' : undefined}
      message={error}
      messageColor={error ? 'danger' : undefined}
    />
  );
}

react-hook-form works the same way: hand its field state to value and onChange, or spread register onto the input, and pass formState.errors.email?.message to message. Same three props, whatever validation library you choose. bestax-bulma doesn't prescribe one, and it doesn't make you carry one either.

The Full Input Set​

None of this would matter if the inputs stopped at <input type="text">. The core set covers stock Bulma, and the extended set goes well past it:

The wrap behavior stays consistent across the table: most of the set generates a full Field and Control, the inputs that manage richer inner markup (Autocomplete, Taginput, File, and Numberinput) generate just the Field, and the small controls (Checkbox, Radio, Switch) plus every Base component never wrap at all. Every input that wraps itself also takes the label and message treatment from the top of this post, and state stays plain React throughout: a value in, a change handler out, whether that value is a string, a number, a tag list, or a Date.

The date and time pickers got their own deep dive in the v3 forms release, so I won't rerun it here. The short version: popover calendar, wheel spinner, segmented keyboard entry, and zero date libraries in your bundle.

Documentation​

• Form components guide: descriptions and live examples for every input
• API references: Field, Control, and Input are the best starting points
• The bestax-form skill teaches AI agents this exact composition and validation pattern
• The blog revival tracker has the rest of the catch-up plan

In June, bestax-bulma v5.0.0 shipped exactly one breaking change, and it was a deletion: 3 files touched, 22 lines removed, 0 added. If you never imported versions/bestax-bulma-prefixed.css, you won't feel a thing.

Same housekeeping as the v4 post: this is a recap, not breaking news. v5.0.0 was tagged on June 26, 2026, six days after v4.0.0, and this is the fifth post in the catch-up series. It also brings the recaps up to the present: the library sits at 5.8.0 today, so the back half of this post sweeps 5.1 to 5.8.

The Breaking Change​

4.x shipped two prefixed CSS bundles: versions/bestax-prefixed.css (bestax- on every class) and versions/bestax-bulma-prefixed.css (bulma- on every class). Same contents, different prefix. 5.0.0 deletes the bulma- one.

The whole change is package.json, the rollup config, and one fifteen-line Sass file: 22 deletions, 0 insertions.

Both bundles and classPrefix date back to v2. The reason the pair didn't survive, straight from the migration guide: "maintaining two parallel prefixed bundles doubled the prefixed build and test surface without adding capability". Anything the bulma- bundle did, the bestax- bundle or a custom Sass build does.

To be precise about the title: all five CSS variations still ship. What v5 removed is the second prefix scheme. One scheme, bestax-, plus a runtime classPrefix that matches whatever prefix your stylesheet uses. Migrating is a two-line swap:

Before (4.x):

import { ConfigProvider, Button } from '@allxsmith/bestax-bulma';
import '@allxsmith/bestax-bulma/versions/bestax-bulma-prefixed.css';

function App() {
  return (
    <ConfigProvider classPrefix="bulma-">
      <Button color="primary">Save</Button>
    </ConfigProvider>
  );
}

After (5.x):

import { ConfigProvider, Button } from '@allxsmith/bestax-bulma';
import '@allxsmith/bestax-bulma/versions/bestax-prefixed.css';

function App() {
  return (
    <ConfigProvider classPrefix="bestax-">
      <Button color="primary">Save</Button>
    </ConfigProvider>
  );
}

And the rendered HTML moves with it:

<!-- 4.x with bestax-bulma-prefixed.css -->
<button class="bulma-button bulma-is-primary">Save</button>

<!-- 5.x with bestax-prefixed.css -->
<button class="bestax-button bestax-is-primary">Save</button>

If custom CSS overrides or test selectors target .bulma-* names, update those alongside the swap. Miss the swap entirely and the failure is loud: the package export is gone, so the old import dies at build time with ERR_PACKAGE_PATH_NOT_EXPORTED instead of quietly serving an unstyled page. Need to keep the bulma- prefix? It isn't reserved; rebuild the same stylesheet from Sass with $class-prefix: 'bulma-'.

classPrefix itself is unchanged, the same ConfigProvider prop it's been since v2; the configuration guide covers it end to end.

Scaffolding Follows​

create-bestax cut 3.0.0 the same day, fixing a bug with the same root cause. Only the complete flavor scaffolded the bundled bestax CSS; the other four imported stock Bulma plus a separate extras.css for the bestax-only components. On the prefixed flavors that combination shipped broken: components emitted prefixed class names while extras.css was unprefixed, so the bestax extras (Tooltip and friends) rendered unstyled in a fresh project.

The fix is the same consolidation: every flavor now imports the single bundled bestax variant for its choice, and the prefixed flavors set classPrefix="bestax-" to match. With one CSS path to wire, the scaffold is correct by construction.

create-bestax is on its 4.x line today, so pnpm create bestax@latest already scaffolds all of this (two minutes to a running app); the installation guide covers the manual path.

Everything Since: 5.1 to 5.8​

The major carried one deletion; the minors carried the features. Eight of them in three weeks:

Reveal, the avatar family, and the accessibility batch are covered in Enhanced Add-Ons, Round Two, so 5.3 through 5.5 stay one-liners here. One patch is worth a call-out: 5.6.1 routed every hardcoded class name through the prefix helpers and added a sweep test that renders the library under a custom prefix and fails on any class that ignores classPrefix.

Four of the minors deserve more than a row.

Dark Mode on Demand​

Since 5.1.0, Theme takes a colorMode prop: 'light', 'dark', or 'system'. It sets Bulma's data-theme on <html>, 'system' follows the OS preference, and omitting it leaves whatever's already set, so single-mode designs should pin it (the Theme docs explain the contrast trap).

import { useState } from 'react';
import { Theme, Button } from '@allxsmith/bestax-bulma';

function App() {
  const [mode, setMode] = useState<'light' | 'dark' | 'system'>('system');
  return (
    <Theme isRoot colorMode={mode}>
      <Button color="primary" onClick={() => setMode('dark')}>
        Dark
      </Button>
      <Button color="primary" onClick={() => setMode('light')}>
        Light
      </Button>
      <Button onClick={() => setMode('system')}>System</Button>
    </Theme>
  );
}

Static on purpose: the blog's live sandbox pins its own light and dark preview, so a toggle that flips the document theme can't run in it. Paste it into an app and it works as written.

One Gap Scale for Columns and Grid​

Grid takes gap on Bulma's 0 to 8 scale; Columns wanted gapSize. 5.6.0 gives Columns the same gap prop, plus gapMobile, gapTablet, and the other responsive variants; gapSize still works as a deprecated alias. This one is live:

function GapDemo() {
  const [gap, setGap] = React.useState<0 | 2 | 5 | 8>(2);
  return (
    <Block>
      <Buttons mb="2">
        <Button onClick={() => setGap(0)}>gap 0</Button>
        <Button onClick={() => setGap(2)}>gap 2</Button>
        <Button onClick={() => setGap(5)}>gap 5</Button>
        <Button onClick={() => setGap(8)}>gap 8</Button>
      </Buttons>
      <Columns gap={gap}>
        <Column>
          <Notification color="primary">One</Notification>
        </Column>
        <Column>
          <Notification color="info">Two</Notification>
        </Column>
        <Column>
          <Notification color="success">Three</Notification>
        </Column>
      </Columns>
    </Block>
  );
}

Dot-Notation Sub-Components​

Since 5.7.0, every parent/child family hangs its children off the parent: Card.Header, Modal.Card, Navbar.Item, Message.Body, and the rest (#331). The statics are the same components as the named exports (attached, not wrapped), so identity checks like child.type === Modal.Card keep working. If you're coming from react-bulma-components, the shape matches; the migration guide maps the differences.

<Message color="info">
  <Message.Header>
    <Paragraph>One Import, Dot Notation</Paragraph>
    <Delete aria-label="delete" />
  </Message.Header>
  <Message.Body>
    <Paragraph>
      Message.Header and Message.Body ride along on the Message import, so the
      whole family stays in one place.
    </Paragraph>
  </Message.Body>
</Message>

The npm Package Reads Itself​

Since 5.8.0, the npm tarball ships llms.txt, AGENTS.md, and a consumer-facing CLAUDE.md (#345). An AI coding agent reading node_modules gets what the library is, where the docs live, and an llms.txt index of what to fetch next, instead of guessing from training data. The LLMs guide covers exactly what ships where.

Documentation​

Everything above, in reference form:

• The 4.x to 5.x migration guide: the two-step swap, the rendered-HTML diff, and the keep-bulma- escape hatch
• ConfigProvider and classPrefix, plus the configuration guide
• Choosing a CSS variation: which of the five bundles to import
• Theme and dark mode
• The LLMs guide: every AI-facing artifact the project publishes

What's Next​

The catch-up series rolls on: next is the agent skills post, then a deep dive on bestax-migrate 1.0. The tracker has the full plan.

One CSS, any prefix. The best thing v5 shipped was a deletion.

In June, bestax-bulma v4.0.0 dropped support for React 16 and 17. That's the whole release: one breaking change, no new components, and if you're on React 18 or 19 you won't feel a thing. Here's why I moved the floor anyway.

Same housekeeping as the v3 forms recap: this is a recap, not breaking news. v4.0.0 was tagged on June 20, 2026, three days after v3.0.0, the library sits at 5.8.0 today, and this is the third post in the catch-up series.

What Changed​

Two lines in package.json. Honestly, that's it:

-    "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0",
-    "react-dom": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0"
+    "react": "^18.0.0 || ^19.0.0",
+    "react-dom": "^18.0.0 || ^19.0.0"

No components changed, no props were renamed, no CSS moved. The rest of the release was internal lint tooling that never ships to you. The 3.x to 4.x migration guide is the shortest one we have, and it exists mostly to say there's nothing to migrate.

Why I Dropped 16 and 17​

The support claim wasn't real. CI built and tested this library against React 18 and 19. Nothing ever ran against 16 or 17, so the ^16.8.0 in the peer range was a claim, not a fact. I know exactly what untested claims are worth, because the day I added a React 18 + 19 test matrix, its very first run failed on React 18: a Carousel test helper passed ref through a prop spread, which only works on React 19's ref-as-prop. If React 18 could break quietly inside the range I actually test, what do you figure the odds were that React 16.8 still worked?

v3 had already crossed the line. The date and time pickers that headlined v3.0.0 call useId for SSR-safe accessible IDs, and useId doesn't exist before React 18. So v3 shipped claiming React 16.8 support while its newest components would have crashed there on mount. v4.0.0 didn't really drop 16 and 17; it stopped claiming something that had already stopped being true.

Old floors are expensive. Keeping 16 and 17 would have meant a fallback ID generator and shims for exactly the versions almost nobody runs. React 18 came out in March 2022, React 19 has been stable since December 2024, and React 16.8 is from February 2019. Every major in a peer range is a promise to test against it, reproduce bugs on it, and design APIs around its limits. I'd rather make a smaller promise and keep it.

The React 18 + 19 Matrix​

Narrowing the range was half the move. The other half was making what's left verifiable: since that same day, every CI run includes a compatibility matrix that builds, type-checks, and tests the library once against React 18 and once against React 19, with real peer installs (no --legacy-peer-deps anywhere) and fail-fast off so a break on either major reports on its own. The peer range and the test matrix now say the same thing. ^18.0.0 || ^19.0.0 isn't a hope, it's what CI verified on the latest commit.

Upgrading​

• On React 18 or 19: skip 4.x and go straight to the current 5.x; that's the path forward. The React floor is identical, and the only breaking change past 4.x is the removal of one prefixed stylesheet variant you probably never imported (the 4.x to 5.x guide has the two-step swap if you did).
• On React 16 or 17: stay on @allxsmith/bestax-bulma@^3 until your app can move to React 18, and mind that the v3 date and time pickers already assume a modern React.

The 3.x to 4.x migration guide covers both paths.

Sometimes You Gotta Move On​

If you maintain a package, a wide peer range feels like generosity. It's also the easiest promise to make, because nothing enforces it: peer ranges aren't verified by your test suite unless you build that verification yourself, and the versions at the old end are exactly the ones your CI stopped seeing years ago. That's how support rots. Not in one decision, but in one hook you adopt, one helper you refactor, one API you design around, until the range describes a library that no longer exists.

So this is me saying the quiet part in a changelog font: I dropped React 16 and 17 because I couldn't keep the promise, and pretending is worse than a major bump. React 16.8 gave us hooks and changed how all of us write components, and 17 carried the whole ecosystem across a bridge. Genuinely: thanks. But sometimes you gotta move on.

What's Next​

The catch-up series rolls on: next is v5.0.0, the release that made the CSS story one story, any prefix. The tracker has the full plan.

Meanwhile, the floor is holding.

New since January​

Same housekeeping as the v3 forms recap: this is a recap, not breaking news. Reveal landed in 5.3.0 on July 8, Avatar, Avatars, and Badge followed in 5.4.0 two days later, and the library sits at 5.8.0 today. And a confession about LinkButton: it isn't new at all. It shipped in the very same commit as the components the January post announced, and that post just never mentioned it. If a component ships in a release and no blog post names it, did it even ship? Consider this its overdue introduction. We won't re-explain the first eight here; the January post has them covered.

Avatar & Avatars​

Avatar shows a person as a photo, initials, or an icon, whichever is available. Avatars stacks them with an overlap and a surplus bubble.

• Automatic fallback chain: photo, then initials, then icon, plus shapes and sizes from 16 to 128 pixels (or any number you want)
• Clickable avatars render a real link or button, and imageProps reaches the underlying img
• Avatars clamps a long list behind a surplus bubble, takes a localized surplus label, and has a spaced, non-overlapping mode

All three fallback stages, side by side. The first loads a real photo, the second points at a domain that's guaranteed to fail (so it falls back to initials), and the third has no photo or name at all:

<Avatars spaced>
  <Avatar src="https://github.com/allxsmith.png" name="Al Smith" size="64x64" />
  <Avatar
    src="https://example.invalid/missing.jpg"
    name="Grace Hopper"
    size="64x64"
  />
  <Avatar icon={<Icon name="user" />} color="info" size="64x64" />
</Avatars>

There's a fourth stage too: with no photo, name, or icon, a built-in generic silhouette renders. And the initials background isn't random. It's hashed deterministically from the name, so Grace gets the same color on every page load.

Badge​

Badge overlays a count or status dot on the corner of anything, or stands alone as a pill.

• Counts with a max (past it the pill shows a plus), dots, and custom node content
• Four positions and an overlap mode that hugs round targets correctly
• Pulse for in-progress states (it goes still under reduced motion), visibility toggling, and zero handling with showZero
• Standalone mode when there's nothing to overlay

A cart button that counts, with a max:

function CartDemo() {
  const [items, setItems] = React.useState(2);
  return (
    <Block display="flex" alignItems="center">
      <Badge content={items} max={9} color="danger" overlap="square" mr="5">
        <Button color="primary">
          <Icon name="shopping-cart" ariaLabel="Cart" />
          <span>Cart</span>
        </Button>
      </Badge>
      <Button onClick={() => setItems(count => count + 1)}>Add item</Button>
    </Block>
  );
}

Click past nine and the pill reads 9+. The count lives in a polite live region, which matters more than it sounds (more on that below).

Reveal​

Reveal animates content into view as it scrolls into the viewport, with IntersectionObserver doing the watching and zero animation libraries in your bundle.

• Seven animation styles with delay, duration, and threshold knobs
• Cascade staggers children, and once={false} re-animates on every entry
• Polymorphic as renders the observed element as any tag

Three boxes, one Reveal, staggered 120 milliseconds apart:

<Reveal
  animation="fade-up"
  cascade
  cascadeInterval={120}
  display="flex"
  flexWrap="wrap"
>
  <Box m="2" flexGrow="1">
    <Title size="5">First</Title>
    <Content>Each direct child gets its own delay.</Content>
  </Box>
  <Box m="2" flexGrow="1">
    <Title size="5">Second</Title>
    <Content>120 milliseconds behind the one before it.</Content>
  </Box>
  <Box m="2" flexGrow="1">
    <Title size="5">Third</Title>
    <Content>No animation runtime in your bundle.</Content>
  </Box>
</Reveal>

Two things worth knowing. First, cascade staggers only the direct children of Reveal, so hand it the items themselves, not a wrapper component. Second, and this one matters: Reveal respects prefers-reduced-motion. When the reader's OS asks for less motion, the animation is skipped entirely and content simply appears. It also renders everything visible during SSR, so crawlers and no-JS visitors never get a blank page. The full accessibility story is on the API page.

LinkButton​

The component the January post forgot. LinkButton is a real <button> dressed as text or a link, and it exists to kill the <div onClick> pattern: you keep native keyboard focus, Enter and Space handling, and screen reader semantics while looking like prose.

• Three variants, text, ghost, and underline, in any Bulma color and size
• Polymorphic as for router links
• Everything Button offers passes through, minus the three props that make no sense on a link look (isOutlined, isInverted, isLight)

<Buttons>
  <LinkButton>Text variant</LinkButton>
  <LinkButton variant="ghost">Ghost variant</LinkButton>
  <LinkButton variant="underline" color="primary">
    Underline variant
  </LinkButton>
</Buttons>

Built for Accessibility​

Some honesty about the rollout: Avatar and Badge shipped in 5.4.0 on a Friday, and by the following Tuesday we'd landed 5.4.1, 5.4.2, and a dedicated 5.5.0 accessibility batch. Shipping fast and patching fast are the same muscle, and the result is a set of defaults we're happy to stand behind:

• An avatar with an explicit alt="" is treated as decorative and skipped by screen readers entirely, but never when it's a link or a button
• Link and button avatars always get an accessible name, even when you forget to provide one
• Badge's role="status" live region stays mounted even when a zero hides the pill, so a change from 0 to 1 is announced reliably instead of inserting a region nobody hears
• Keyboard focus on a stacked avatar lifts it above its overlapping neighbors, so the focus ring is never buried
• The surplus label in Avatars is localizable, and as="button" avatars default to type="button" so a click can't accidentally submit a form

Reveal didn't need the patch batch. Its accessibility story shipped on day one: content never leaves the accessibility tree, the animation touches only opacity and transform, and reduced motion turns it off.

Themeable like Stock Bulma​

Every Enhanced Add-On follows the same SCSS contract as the stock components: its variables derive from Bulma tokens (never hardcoded hex) and register as --bulma-* CSS variables on the component root. That's why the Theme component and plain CSS overrides work on the extras exactly like they work on a Button.

Take the badge's ring, the thin outline separating the pill from whatever sits behind it. It defaults to var(--bulma-scheme-main), the page's scheme color, so it's already correct in dark mode without a dark-mode rule anywhere. Want it branded? One variable:

.badge {
  --bulma-badge-ring-color: var(--bulma-primary);
}

The same goes for the rest: avatar size, background, and radius; Reveal's duration and easing riding Bulma's own motion tokens. Initials avatars even pick their background from Bulma's palette (primary, link, info, success, warning, danger), so a retheme recolors your avatars with everything else. Each API page lists its variables at the bottom: Avatar, Badge, Reveal. For the bigger picture, see the Theme helper and the CSS variables guide.

All 12 Enhanced Add-Ons​

The full set, straight from the homepage grid, four of them new since January:

Documentation​

• API references: Avatar, Avatars, Badge, Reveal, and LinkButton
• Theming: the Theme helper and the CSS variables guide
• Round one: Introducing Extra Components, the first eight

Some honesty up front: this is a recap, not breaking news. v3.0.0 was tagged on June 17, 2026, the library sits at 5.8.0 today, and the blog fell behind the code. This post starts a series that catches things up, one release at a time. (And no, Colorpicker hasn't shipped yet. We're not going to pretend otherwise.)

What Shipped in v3​

v3 was the forms release. The 2.x form story covered the basics (Input, Select, TextArea, File, Checkbox, Radio), and 3.0 filled in just about everything else:

The same release also brought a wave of UI components (Tooltip, Dialog, Toast, Steps, Sidebar, Carousel, and more) and a set of text elements, but this post sticks to the forms story. The 2.x to 3.x migration guide has the complete list.

Native Date & Time Pickers​

The standout of the release. The pickers run on native Date and Intl alone: no date library in your bundle, no peer dependency to version-match, and no locale data to ship. If you've ever shipped an entire date library just so a user could pick a Tuesday, you know exactly why that matters.

What that buys you (each link lands on a live example in the API docs):

• A popover calendar for dates and a wheel spinner for times
• Segmented keyboard entry directly in the field, so typing a date never requires the popover
• Min/max bounds, disabled-date predicates, custom formats, locales, and an inline mode
• A focus trap while the popover is open, with keyboard navigation fully mapped, and a native fallback on touch devices so phones get the platform picker
• On TimeInput, 12-hour or 24-hour formats, optional seconds, and custom minute increments for slot-style pickers

Here's a controlled DateInput clamped to the current month:

function DateDemo() {
  const [date, setDate] = React.useState(null);
  const today = new Date();
  const min = new Date(today.getFullYear(), today.getMonth(), 1);
  const max = new Date(today.getFullYear(), today.getMonth() + 1, 0);
  return (
    <Block>
      <DateInput
        label="Pick a day this month"
        placeholder="YYYY-MM-DD"
        min={min}
        max={max}
        value={date}
        onChange={setDate}
      />
      <Paragraph mt="2">
        Selected: {date ? date.toDateString() : 'nothing yet'}
      </Paragraph>
    </Block>
  );
}

And a controlled TimeInput on the 12-hour clock:

function TimeDemo() {
  const [time, setTime] = React.useState(null);
  return (
    <Block>
      <TimeInput
        label="Departure"
        placeholder="HH:MM AM"
        hourFormat="12"
        value={time}
        onChange={setTime}
      />
      <Paragraph mt="2">
        Selected: {time ? time.toLocaleTimeString() : 'nothing yet'}
      </Paragraph>
    </Block>
  );
}

Note the onChange: it hands you a Date (or null), not an event, so a state setter drops straight in. When you need both halves at once, DateTimeInput combines the calendar and the wheels in a single popover with an iOS-style footer; click the time and the spinner floats over the calendar, which is a pretty cool trick:

<Block>
  <DateTimeInput label="Appointment" placeholder="YYYY-MM-DD HH:MM" />
</Block>

Field/Control Auto-Wrap​

The one breaking change in v3, told straight. In 2.x, <Input> rendered a bare <input class="input">. In 3.x, Input, Select, TextArea, and File detect whether they're already inside a <Field> and <Control>, and wrap themselves when they're not:

<Input value="hi" />
// 2.x → <input class="input" value="hi" />
// 3.x → <div class="field"><div class="control"><input class="input" value="hi" /></div></div>

That wrapper pattern isn't something we invented, it's Bulma stuff. Bulma's form markup puts every control inside a <div class="control"> and groups controls under a <div class="field"> that handles spacing, labels, addons, and icons; Bulma's own form docs build everything on that skeleton. Our Field and Control components render exactly that structure, so in 3.x the inputs guarantee the markup Bulma expects.

Why make wrapping the default? Because <Field><Control><Input /></Control></Field> is the single most common pattern in Bulma forms, and once the wrapper is guaranteed, props like label, message, and iconLeftName can exist at all:

<Input
  label="Email"
  type="email"
  iconLeftName="envelope"
  message="We'll never share your email."
/>

Code that already wrapped its inputs keeps working (context detection skips the re-wrap), and CSS that targets .input still matches. If a snapshot test asserted the root element, or a layout dropped <Input> straight into a flex or grid container, the migration guide has the watch-for list. And if you want the bare element back, InputBase, SelectBase, and TextAreaBase render exactly what 2.x did.

Themed Checkbox & Radio​

Checkbox and Radio got the themed treatment: a visually hidden native input plus a custom indicator span, which unlocks color and size variants like <Radio color="primary" size="large">. The catch is that the indicator needs the new extras stylesheet. Upgrade without it and your radios become invisible click targets.

The easy path is swapping your bulma.css import for bestax.css, a drop-in superset that bundles Bulma plus every bestax extra in one file:

import '@allxsmith/bestax-bulma/dist/bestax.css';

Here's what the checkboxes look like once the CSS is loaded:

<Checkboxes>
  <Checkbox defaultChecked>I agree to the terms</Checkbox>
  <Checkbox color="primary">Subscribe to newsletter</Checkbox>
  <Checkbox disabled>Disabled option</Checkbox>
</Checkboxes>

And the radios:

<Radios name="answer">
  <Radio defaultChecked>Yes</Radio>
  <Radio>No</Radio>
  <Radio disabled>Maybe</Radio>
</Radios>

Checkboxes and Radios also grew optional group state: pass value and onChange to the container and skip wiring each control. Existing JSX keeps working, since the new props are all optional.

The Rest of the Form Suite​

The pickers got the spotlight, but the rest of the suite pulls its weight. Every link below lands on a live example in the API docs, and every demo here is poke-able.

Switch​

A styled checkbox that renders as a toggle, made for settings screens.

• Colors, sizes, and rounded, thin, and outlined styles
• RTL layout and a controlled mode

function SwitchDemo() {
  const [enabled, setEnabled] = React.useState(false);
  return (
    <Block>
      <Switch
        checked={enabled}
        onChange={e => setEnabled(e.target.checked)}
        color="success"
        isRounded
      >
        Enable notifications
      </Switch>
      <Paragraph mt="2">Status: {enabled ? 'Enabled' : 'Disabled'}</Paragraph>
    </Block>
  );
}

Slider​

A range slider for picking values.

• Output display with a custom format
• Custom ranges, colors, sizes, and rounded or circle thumbs
• Controlled and uncontrolled modes

function SliderDemo() {
  const [value, setValue] = React.useState(50);
  return (
    <Block>
      <Slider
        value={value}
        onChange={setValue}
        min={0}
        max={100}
        showOutput
        color="primary"
        isRounded
      />
      <Paragraph mt="2">Value: {value}</Paragraph>
    </Block>
  );
}

Numberinput​

A number input with +/- stepper buttons.

• Min/max and a custom step
• Controls position, colors, sizes, and rounded buttons

function NumberDemo() {
  const [quantity, setQuantity] = React.useState(1);
  return (
    <Block>
      <Numberinput
        value={quantity}
        onChange={setQuantity}
        min={1}
        max={10}
        color="primary"
      />
      <Paragraph mt="2">Quantity: {quantity}</Paragraph>
    </Block>
  );
}

Rate​

Star ratings without hand-rolling the stars.

• Score display and text labels alongside the icons
• Custom max, custom icons, and sizes

function RateDemo() {
  const [rating, setRating] = React.useState(3);
  return (
    <Block>
      <Rate
        value={rating}
        onChange={setRating}
        showScore
        showText
        texts={['Poor', 'Fair', 'Average', 'Good', 'Excellent']}
      />
    </Block>
  );
}

Autocomplete​

An input with filtered dropdown suggestions and keyboard navigation.

• Open on focus, a clear button, and keep-first highlighting
• Object data, custom item templates, and loading and empty states

function AutocompleteDemo() {
  const [selected, setSelected] = React.useState(null);
  const fruits = [
    'Apple',
    'Banana',
    'Cherry',
    'Date',
    'Elderberry',
    'Fig',
    'Grape',
  ];
  return (
    <Block>
      <Autocomplete
        data={fruits}
        placeholder="Search fruit..."
        onSelect={setSelected}
        openOnFocus
        clearable
      />
      {selected && <Paragraph mt="2">Selected: {selected}</Paragraph>}
    </Block>
  );
}

Taginput​

A tag and chip input for managing multiple values.

• Autocomplete suggestions, optionally restricted to the list
• Max tags, duplicate control, and custom confirm keys
• Tag colors and non-closable tags

function TaginputDemo() {
  const [tags, setTags] = React.useState(['React', 'TypeScript']);
  const suggestions = [
    'React',
    'Vue',
    'Angular',
    'Svelte',
    'TypeScript',
    'JavaScript',
  ];
  return (
    <Block>
      <Taginput
        value={tags}
        onChange={setTags}
        data={suggestions}
        placeholder="Add frameworks..."
        tagColor="primary"
      />
      <Paragraph mt="2">Tags: {tags.join(', ')}</Paragraph>
    </Block>
  );
}

Documentation​

• Upgrading bestax-bulma 2.x to 3.x: the complete change list and every watch-for
• Form components guide: live examples of every input
• API references: DateInput, TimeInput, and DateTimeInput

What's Next​

v3 was the first of three majors that landed in under two weeks this June, so the recaps continue: v4.0.0 (React 18 becomes the floor), then v5.0.0 (one CSS story, any prefix). After that, the series digs into bestax-migrate, building forms without a form library, and the AI loop that helps maintain this project. The full plan lives in the blog revival tracker.

Last time we said "coming soon" it took five months, so no dates this time. Yeah, we learned.

That's the whole leaderboard, and it has been remarkably stable for years. Every survey, every npm download chart, every "what CSS framework should I use in 2026" thread lands in the same order.

So let's talk about third place, because third place is the interesting place to be.

Congrats on being different. Now here's what to do.

Third Place Is Not Second Loser​

There's a certain kind of developer who reads "third most used" and hears "the one that lost." I'd like to gently push back on that.

First place in a popularity contest tells you almost nothing about fit. It tells you about momentum, marketing budget, and the gravitational pull of defaults. Tailwind is genuinely excellent and deserves its adoption. Bootstrap earned its position over a decade of being the safe answer. Neither of those facts makes them the right answer for your project.

Here's what third place actually means for Bulma:

• Big enough to be safe. Millions of downloads, a decade of production use, active v1 development. This isn't a weekend project you're betting your app on.
• Small enough to still have a point of view. Bulma didn't chase the utility-first trend. It didn't bolt on a JavaScript runtime. It stayed a CSS framework.
• Boring in the good way. No build step required. No config file with 400 lines. No plugin ecosystem you have to keep in sync.

Bulma is what you pick when you want your HTML to be readable six months from now.

Here's the leaderboard, rendered in the framework that placed third. Every code block in this post is live and editable. Change it and watch it re-render:

<Panel color="primary">
  <Panel.Heading>CSS Framework Leaderboard</Panel.Heading>
  <Panel.Block>
    <Panel.Icon name="trophy" variant="solid" />
    Tailwind CSS: utility-first, enormous, deserved
  </Panel.Block>
  <Panel.Block>
    <Panel.Icon name="medal" variant="solid" />
    Bootstrap: the safe answer for over a decade
  </Panel.Block>
  <Panel.Block active>
    <Panel.Icon name="heart" variant="solid" />
    Bulma: third place, on purpose
  </Panel.Block>
</Panel>

Why That Was React and Not Raw Bulma​

You may have noticed that example is not hand-written Bulma markup. There is no class="panel is-primary" anywhere in it. It is a <Panel> component from @allxsmith/bestax-bulma, and so is every other example in this post. That is a deliberate choice, and it is worth a paragraph before we go any further.

Bulma ships CSS and nothing else. That is precisely what makes it pleasant to write by hand, and precisely what makes it hard for an AI assistant to write correctly. A class string has no schema behind it. Nothing tells a model which modifiers are legal on which element, nothing catches is-primaryy, nothing knows that is-large belongs on the button and not the wrapper. The mistake does not surface until a human looks at the page, and class soup is close to invisible in code review.

Typed components close that gap. color="primary" has six legal values and an editor that lists them. A wrong prop is a red squiggle, not a silently unstyled div. The component owns the class names, so an assistant never has to remember Bulma's naming rules, only the props. On top of that, bestax publishes its full API as a machine-readable LLM index and ships Agent Skills, so an assistant can read the real component surface instead of reconstructing it from whatever it half-remembers about Bulma.

That is the whole point of bestax. Not to replace Bulma, but to give it the surface that modern tooling expects: types, autocomplete, docs a machine can parse, and skills an agent can load. A framework that AI cannot use confidently is a framework AI will not recommend, and as we will get to at the end of this post, not being recommended is how a perfectly good framework quietly disappears. Making Bulma AI-native is how third place stays on the board.

So: Bulma underneath, bestax on top, and every example below is real, running code you can edit.

What Bulma Actually Gives You​

Bulma v1 (2024) was not a maintenance release. It was a rebuild of the foundations:

• CSS variables throughout: theming without a Sass pipeline
• HSL-based color system: derive an entire palette from a few values
• CSS Grid support: modern layouts, not just flexbox columns
• Native dark mode: first-class, not an afterthought
• Skeleton loaders: built into the components you already use
• Prefixed distribution: run Bulma next to another framework without class collisions

And the thing that hasn't changed since 2016: class="button is-primary is-large" means exactly what it looks like it means. You can read a Bulma template out loud. Try that with a wall of utility classes.

Semantic Colors, Everywhere​

One color vocabulary (primary, link, info, success, warning, danger) applied consistently across every component. Learn it once:

<Buttons>
  <Button color="primary">Primary</Button>
  <Button color="link">Link</Button>
  <Button color="info">Info</Button>
  <Button color="success">Success</Button>
  <Button color="warning">Warning</Button>
  <Button color="danger">Danger</Button>
</Buttons>

The same six words work on tags:

<Tags>
  <Tag color="primary">bulma</Tag>
  <Tag color="link">react</Tag>
  <Tag color="info">typescript</Tag>
  <Tag color="success">vite</Tag>
  <Tag color="warning" isRounded>
    open source
  </Tag>
  <Tag color="danger" isRounded>
    please star
  </Tag>
</Tags>

And on messages:

<>
  <Message color="info" title="Third place">
    Big enough to trust, small enough to still have opinions.
  </Message>
  <Message color="success" title="Zero JavaScript">
    Bulma ships CSS. You bring the behavior.
  </Message>
</>

HSL Theming Without a Sass Pipeline​

Bulma v1 derives its whole palette from hue, saturation, and lightness. Change three numbers and get a new theme at runtime, with no rebuild. Edit the primaryH value below:

function ThemeDemo() {
  const [hue, setHue] = useState(270);
  return (
    <Block>
      <Slider value={hue} onChange={setHue} min={0} max={360} />
      <Paragraph mb="3">
        primaryH: <Strong>{hue}</Strong>
      </Paragraph>
      <Theme primaryH={String(hue)} primaryS="90%" primaryL="50%">
        <Box>
          <Title size="5">One variable, whole palette</Title>
          <Buttons>
            <Button color="primary">Primary</Button>
            <Button color="primary" isLight>
              Light
            </Button>
            <Button color="primary" isOutlined>
              Outlined
            </Button>
          </Buttons>
          <Tag color="primary" size="medium">
            Themed tag
          </Tag>
        </Box>
      </Theme>
    </Block>
  );
}

That's the entire theming story. No tailwind.config.js, no Sass variables file, no build step.

Skeleton Loaders, Built In​

Loading states used to be a component library's job. Bulma v1 ships them:

<Box>
  <Skeleton />
  <Skeleton />
</Box>

Columns That Just Work​

<Columns>
  <Column>
    <Notification color="primary">First</Notification>
  </Column>
  <Column>
    <Notification color="link">Second</Notification>
  </Column>
  <Column>
    <Notification color="info">Third, the good one</Notification>
  </Column>
</Columns>

Now: Scaffold a Site​

Enough theory. Let's build something. One command:

npm create bestax@latest my-app

Answer four short questions and you have a working React + Bulma application. Then:

cd my-app
npm install
npm run dev

That's a running dev server with hot reload, Bulma v1 wired up, and the @allxsmith/bestax-bulma component library ready to import.

The Prompts​

Four questions, in order. Click through them:

function ScaffoldSteps() {
  const [step, setStep] = useState(0);
  const labels = ['Project name', 'Framework', 'Bulma flavor', 'Icon library'];
  return (
    <Block>
      <Steps
        value={step}
        color="primary"
        onStepClick={setStep}
        items={labels.map(label => ({ label, clickable: true }))}
      />
      <Notification color="info" isLight mt="4">
        Step {step + 1} of 4: <Strong>{labels[step]}</Strong>
      </Notification>
    </Block>
  );
}

1. Project name: validated to be npm-compatible.

? Project name: my-app

2. Framework: JavaScript or TypeScript, both on Vite.

? Select a framework:
  ❯ Vite
    Vite + TypeScript

3. Bulma flavor: this is the part nobody else automates.

? Which Bulma CSS flavor would you like to use?
  ❯ Complete (Recommended) - Full Bulma CSS with all components and helpers
    Prefixed - All classes prefixed with "bulma-" to avoid conflicts
    No Helpers - Core components only, no utility classes
    No Helpers, Prefixed - Core components only with "bulma-" prefix
    No Dark Mode - Light mode only, smaller bundle size

Bulma v1 publishes several CSS distributions. Figuring out which one you want, and how to import it correctly, is exactly the kind of yak-shave that kills a Saturday. create-bestax picks the file, wires the import, and moves on.

4. Icon library: installed and configured, not just mentioned in a README.

? Would you like to add an icon library?
  ❯ None (I'll add icons later)
    Font Awesome
    Material Design Icons
    Ionicons
    Google Material Icons
    Material Symbols

Skip the Prompts​

Every answer has a flag:

# All defaults, zero questions
npm create bestax@latest my-app -y

# TypeScript + Font Awesome
npm create bestax@latest my-app -t vite-ts -i fontawesome

# Prefixed Bulma (running alongside another framework) + Material Design Icons
npm create bestax@latest my-app -b prefixed -i mdi

# Everything specified
npm create bestax@latest my-app -t vite-ts -b complete -i fontawesome

Your First Component​

The scaffold drops you into a project where this already works:

function ThirdPlace() {
  return (
    <Hero color="primary" size="medium">
      <Hero.Body>
        <Columns>
          <Column size="half">
            <Card>
              <Card.Content>
                <Title size="4">Third place never looked so good.</Title>
                <Button color="success">Ship it</Button>
              </Card.Content>
            </Card>
          </Column>
        </Columns>
      </Hero.Body>
    </Hero>
  );
}

Typed props, Bulma helper props on every component, and no style={{}} in sight. Full reference at bestax.io/docs/api.

A Tour in Live Code​

This is the part where most framework posts show you a screenshot. Instead, here's the actual library, running in your browser, editable. Change anything you like and it re-renders as you type.

Forms​

Every form control is controlled or uncontrolled, typed, and accessible out of the box.

Field, Control, Input: the Bulma form primitives:

<Field label="Repository">
  <Control>
    <Input type="text" defaultValue="allxsmith/bestax" />
  </Control>
</Field>

Select:

<Select label="Which Bulma flavor?">
  <option value="complete">Complete (recommended)</option>
  <option value="prefixed">Prefixed</option>
  <option value="no-helpers">No helpers</option>
  <option value="no-dark-mode">No dark mode</option>
</Select>

Switch: controlled, with a color:

function SwitchDemo() {
  const [on, setOn] = useState(true);
  return (
    <Switch
      checked={on}
      onChange={e => setOn(e.target.checked)}
      color="success"
      isRounded
    >
      Support open source: {on ? 'yes' : 'also yes'}
    </Switch>
  );
}

Slider with a live output:

function SliderDemo() {
  const [value, setValue] = useState(72);
  return (
    <Block>
      <Slider
        value={value}
        onChange={setValue}
        color="primary"
        isRounded
        showOutput
      />
      <Paragraph mt="2">Enthusiasm: {value}%</Paragraph>
    </Block>
  );
}

Numberinput: increment/decrement without writing the handlers:

function NumberDemo() {
  const [count, setCount] = useState(3);
  return (
    <Block>
      <Numberinput value={count} onChange={setCount} min={0} />
      <Paragraph mt="2">Dependencies you've never starred: {count}</Paragraph>
    </Block>
  );
}