How Blade components and plain HTML relate — an honest account of what is automatic and what is manual.
The short answer: one direction is automatic, the other is manual
Blade → HTML is automatic and always accurate. Blade components render on the server into plain HTML. The HTML tab on every component page of this site is the actual rendered output of the Blade tab's code — never a hand-written transcription, so it can never drift from the real output.
There is no automatic HTML → Blade converter. Replacing your existing HTML with Blade components is manual work (see the recipe below). "Interconvertible" is only true at the class-vocabulary level — at the markup level, the conversion is one-way.
How the two doc tabs work
Every component page's Usage section has Blade / HTML tabs. The HTML tab is generated on the spot via Blade::render(), so the documented HTML can never go stale when the library updates. Here is a live one embedded on this page:
The HTML tab's output is plain HTML plus class strings, so you can copy it into a project that doesn't use Blade. Two things are required:
The compiled CSS — the classes reference theme tokens (bg-primary, …) and tune tokens (p-md, var(--radius-box), …). The official distribution is currently the Composer package build; a standalone CSS package (npm) is in the works.
Alpine.js — the HTML output of dynamic components (modal / tabs / dropdown …) includes their x-data attributes as-is. Load Alpine.js (+ @alpinejs/focus / @alpinejs/collapse) on the page and the copied HTML just works. Static components (button / badge / card …) need no JS at all.
The reverse direction: migrating existing HTML to Blade
There is no automatic converter, but the recipe is simple:
Copy the minimal example from that page's Blade tab and match the props (color / size / appearance …)
Throw away your hand-written class piles — color, shape, and spacing are handled by the theme and tune
The opposite move — leaving Blade for plain Tailwind — does have an official tool: php artisan ui:eject rewrites pinion-ui classes into the vanilla Tailwind that reproduces your chosen theme × tune (the no-lock-in escape hatch).
The class strings and structure work as-is (the look is reproduced as long as the CSS is loaded). The x-data interactivity is Alpine's, though — in React/Vue you'd port it to that framework's state. Official multi-framework support is planned as Web Components.
None — it isn't baked. The output classes are semantic tokens (bg-primary, p-md, …), so they follow whatever data-theme / data-tune the destination page uses.
Yes. Every example shown is actually rendered and verified — the HTML tab is the proof; an example that fails to render cannot appear on the page.
data-theme = pinion
Blade & HTML
How Blade components and plain HTML relate — an honest account of what is automatic and what is manual.
The short answer: one direction is automatic, the other is manual
Blade → HTML is automatic and always accurate. Blade components render on the server into plain HTML. The HTML tab on every component page of this site is the actual rendered output of the Blade tab's code — never a hand-written transcription, so it can never drift from the real output.
There is no automatic HTML → Blade converter. Replacing your existing HTML with Blade components is manual work (see the recipe below). "Interconvertible" is only true at the class-vocabulary level — at the markup level, the conversion is one-way.
How the two doc tabs work
Every component page's Usage section has Blade / HTML tabs. The HTML tab is generated on the spot via Blade::render(), so the documented HTML can never go stale when the library updates. Here is a live one embedded on this page:
The HTML tab's output is plain HTML plus class strings, so you can copy it into a project that doesn't use Blade. Two things are required:
The compiled CSS — the classes reference theme tokens (bg-primary, …) and tune tokens (p-md, var(--radius-box), …). The official distribution is currently the Composer package build; a standalone CSS package (npm) is in the works.
Alpine.js — the HTML output of dynamic components (modal / tabs / dropdown …) includes their x-data attributes as-is. Load Alpine.js (+ @alpinejs/focus / @alpinejs/collapse) on the page and the copied HTML just works. Static components (button / badge / card …) need no JS at all.
The reverse direction: migrating existing HTML to Blade
There is no automatic converter, but the recipe is simple:
Copy the minimal example from that page's Blade tab and match the props (color / size / appearance …)
Throw away your hand-written class piles — color, shape, and spacing are handled by the theme and tune
The opposite move — leaving Blade for plain Tailwind — does have an official tool: php artisan ui:eject rewrites pinion-ui classes into the vanilla Tailwind that reproduces your chosen theme × tune (the no-lock-in escape hatch).
The class strings and structure work as-is (the look is reproduced as long as the CSS is loaded). The x-data interactivity is Alpine's, though — in React/Vue you'd port it to that framework's state. Official multi-framework support is planned as Web Components.
None — it isn't baked. The output classes are semantic tokens (bg-primary, p-md, …), so they follow whatever data-theme / data-tune the destination page uses.
Yes. Every example shown is actually rendered and verified — the HTML tab is the proof; an example that fails to render cannot appear on the page.
data-theme = pinion-dark
Blade & HTML
How Blade components and plain HTML relate — an honest account of what is automatic and what is manual.
The short answer: one direction is automatic, the other is manual
Blade → HTML is automatic and always accurate. Blade components render on the server into plain HTML. The HTML tab on every component page of this site is the actual rendered output of the Blade tab's code — never a hand-written transcription, so it can never drift from the real output.
There is no automatic HTML → Blade converter. Replacing your existing HTML with Blade components is manual work (see the recipe below). "Interconvertible" is only true at the class-vocabulary level — at the markup level, the conversion is one-way.
How the two doc tabs work
Every component page's Usage section has Blade / HTML tabs. The HTML tab is generated on the spot via Blade::render(), so the documented HTML can never go stale when the library updates. Here is a live one embedded on this page:
The HTML tab's output is plain HTML plus class strings, so you can copy it into a project that doesn't use Blade. Two things are required:
The compiled CSS — the classes reference theme tokens (bg-primary, …) and tune tokens (p-md, var(--radius-box), …). The official distribution is currently the Composer package build; a standalone CSS package (npm) is in the works.
Alpine.js — the HTML output of dynamic components (modal / tabs / dropdown …) includes their x-data attributes as-is. Load Alpine.js (+ @alpinejs/focus / @alpinejs/collapse) on the page and the copied HTML just works. Static components (button / badge / card …) need no JS at all.
The reverse direction: migrating existing HTML to Blade
There is no automatic converter, but the recipe is simple:
Copy the minimal example from that page's Blade tab and match the props (color / size / appearance …)
Throw away your hand-written class piles — color, shape, and spacing are handled by the theme and tune
The opposite move — leaving Blade for plain Tailwind — does have an official tool: php artisan ui:eject rewrites pinion-ui classes into the vanilla Tailwind that reproduces your chosen theme × tune (the no-lock-in escape hatch).
The class strings and structure work as-is (the look is reproduced as long as the CSS is loaded). The x-data interactivity is Alpine's, though — in React/Vue you'd port it to that framework's state. Official multi-framework support is planned as Web Components.
None — it isn't baked. The output classes are semantic tokens (bg-primary, p-md, …), so they follow whatever data-theme / data-tune the destination page uses.
Yes. Every example shown is actually rendered and verified — the HTML tab is the proof; an example that fails to render cannot appear on the page.