Skip to content
UI Brok

Loading…

No results

Browse catalog

Why Brok

Laravel already has good UI options. Brok is not trying to replace all of them — it occupies a specific niche: teams who want to own and shape their UI source the way React developers do with shadcn/ui, but in plain Blade, and without giving up safe upgrades. This page is the honest version of when that trade is worth it — and when it isn't.

The one-line model

php artisan ui:add button writes a real Blade component into resources/views/components/ui. From that moment it is your file — there is no runtime dependency on Brok. The CLI still tracks it (via ui-lock.json) so you can pull upstream fixes with a 3-way merge instead of a manual copy-paste.

When copy-in is the right call

  • Heavy customization. If you expect to restyle, restructure or extend components well beyond a theme — owning the source is faster than fighting a package's extension points.
  • No-vendor-lock policies. Teams that forbid external UI dependencies, or need every line auditable, get plain Blade with nothing phoning home.
  • Decoupled release cadence. You update on your schedule with a reviewable diff, not when a package ships a breaking major.
  • Learning & onboarding. The source is in your repo — readable, greppable, and a reference for how accessible Blade is built.
  • Livewire-compatible by design. Components are Alpine-based and passthrough-safe, and Brok ships a bounded Livewire reference set (confirm / field / modal / search / tabs / toast) plus documented @entangle / wire:model / wire:ignore interop. "I use Livewire" is not a blocker.

Note

Brok's genuine edge over hand-copying components (the usual shadcn-style workflow) is the safe-update tooling: ui:diff and ui:update --interactive do a 3-way merge between the pristine upstream, the new upstream and your edits — so owning the code does not mean freezing it.

How it compares

The honest landscape. None of these are "wrong" — they optimise for different things.

Option Runtime model Updates Best for
Brok None — copied Blade + CSS tokens CLI-assisted 3-way merge Owning & customising UI, deliberate upgrades
Runtime component packages Runtime: Livewire + PHP package Composer bumps Livewire-native reactive apps, least maintenance
Admin-panel builders Runtime: opinionated PHP framework Composer bumps Admin panels & internal tools
Blade / Alpine package kits Runtime: Blade + Alpine package Composer bumps Fast Blade kits without owning source

When not to use Brok

If you want managed updates with zero merge work, are all-in on Livewire's reactive model, or simply don't intend to customise the UI much — a runtime component package (or an admin-panel builder for admin surfaces) is the lower-friction choice. Copy-in earns its keep when you actually value owning and evolving the code. If you don't, the tracking and merge steps are overhead you won't use.

Note

Already on Livewire but want to own your UI source? Brok is Livewire-compatible by design: components are Alpine-based and passthrough-safe, and there's a bounded Livewire reference set plus documented @entangle, wire:model and wire:ignore patterns. To be clear about scope, the broader catalogue ships Alpine-first interop (not a native Livewire variant of every component) — but adopting Livewire is not a blocker.

Warning

Copy-in is not free: you take on the components as part of your codebase. Brok's job is to make that cheap (accessible defaults, semantic tokens, diff-aware updates) — but the responsibility is real. Choose it on purpose, not by default.

Next steps

  • Install Brok in an existing Laravel app.
  • Theming — re-skin everything by editing tokens, no markup changes.
  • Updating — how diff-aware upgrades work once you've edited a component.