Tabletop vs Filament

Server HTML or a React client

Filament calls itself a server-driven UI framework built on Livewire, Alpine.js and Tailwind CSS. PHP classes render to HTML on the server, and every page is a full-page Livewire component; v5 requires Livewire 4. A click on Save sends a request that runs PHP, and Livewire morphs the returned HTML into the page. For most screens that means one language end to end and no JavaScript to write.

Tabletop keeps the PHP authoring and moves rendering to the browser. A page is serialized to JSON, sent as Inertia props and rendered by a React 19 client. Form state lives in React, and hiddenIf and disabledIf conditions (a field, an operator and a value) are evaluated in the browser with no request. Saves and navigation go through Inertia, using Laravel's errors bag and flash. Table refetches, charts, async selects and uploads call plain JSON endpoints.

Neither sends a request per keystroke by default: Filament fields are not reactive until you mark them live(). The difference is where conditional and derived UI runs. A Filament condition written as a PHP closure needs a request, and a reactive change re-renders the whole component unless you enable partial rendering; for instant behaviour you write JavaScript strings in PHP (hiddenJs(), actionJs()). Tabletop's conditions are declarative, so they run in the browser but cannot run arbitrary PHP; anything that needs PHP is an opt-in liveRegion, one round-trip per change of a declared dependency. Filament navigation is a full page load unless you enable SPA mode. Neither project publishes a benchmark: this is a difference in architecture, not a speed ranking.

The cost is a JavaScript build. The admin is a sizeable React bundle (the richtext chunk alone is about 270KB) that your Vite compiles, the host has to compile Tailwind v4, and custom UI is written in two languages. The admin gets its own Inertia entry, so the bundle stays off your public pages.

Authoring: close by design

The two are close here on purpose: Tabletop's README describes it as Filament's authoring model without Livewire. A Filament screen is a schema of component objects. A resource groups the form and infolist schemas, a table class and the resource's Livewire pages.

Tabletop has no Resource class. A screen is a Page class with path() and view(), and view() returns a tree built with the fluent S builder. A CRUD resource is a set of pages: create, index and edit. Validation is Laravel rules in PHP. The client's zod mirror gives on-blur feedback only, and the server never trusts it.

Authorization is where they part. Filament picks up your model policies automatically. Tabletop does not: you declare a Gate ability on each page with can() and on each action with authorize(). An action that fails the check is left out of the payload, as in Filament, and is checked again on dispatch.

Extending: Blade and Livewire, or React

This is the real difference. A custom Filament field is a PHP class that extends Field, plus a Blade view, with state bound through wire:model or Alpine's entangle. A custom page is a Livewire class and a Blade view. Filament's own docs say many parts of the framework need no Livewire, but building custom components might, and they point teams that want to avoid Livewire to Nova, which runs on Vue and Inertia.

In Tabletop the same work is a React component. A field is registered with defineFieldClient for both the form input and the table cell, next to a PHP Field subclass registered through S::register(). A widget is registered with registerBlock and placed from PHP by name. Inside a form it reads live form state through useNearestFormController(). Neither touches the core packages. For content that changes with the form but needs no client code, liveRegion re-renders display nodes on the server.

If your product's frontend is already React, you build custom admin UI from the components and skills your team already has. If your frontend is Blade and Livewire, Filament is the shorter route.

Screens and the shell

Both put several forms and tables on one screen, and neither documents a limit. A Filament page body is a schema you override with content(); it can hold several forms, several tables (each with its own query-string identifier so pagination does not clash), header and footer widgets, and any Livewire component. A Tabletop page's view() is one tree: several independent tables and named forms, each form posting to its own endpoint, laid out with stack, grid, section and tab primitives beside stats and charts.

The shell is where the approaches differ. Filament offers sidebar or top navigation, a collapsible sidebar and toggles for the topbar and breadcrumbs, and lets you replace the sidebar and topbar with your own Livewire components. Everything else goes through render hooks, CSS hooks and themes; Filament advises against publishing its Blade views. Tabletop authors the header, sidebar and footer in PHP in a Chrome class, where you append to a stock area or replace it, with React slots as the last resort. It has three navigation layouts and a chrome-less layout per page.

Multilingual content

Tabletop builds in what Filament leaves to a plugin. ->translatable() on a field stores a per-locale map, the form gets a locale tab bar with per-locale error counts, rulesForLocale() validates each locale separately, and table columns read the active locale. Content locales are set globally, apart from each panel's UI language. The docs do not say whether every field kind supports it, so check yours.

Filament v5 core has only a driver contract for translatable content. Its former official Spatie plugin is now maintained by Lara Zeus, whose free Spatie Translatable plugin is listed for v5. For the panel's own interface Filament is far ahead: it ships UI translations for 64 locales, where Tabletop ships English and Ukrainian.

Where Filament is ahead

Maturity. Filament tagged v1.0.0 in 2021, and v5, its fifth major, shipped in 2026. A written support policy keeps 4.x on fixes alongside 5.x, and an automated script handles upgrades between majors. It has tens of thousands of GitHub stars, a Discord and a public demo. Tabletop is at v0.5 in public beta. Until 1.0, pin the minor version and read the changelog before you upgrade. Only the latest release is supported.

Ecosystem. This is Tabletop's weakest point. Filament plugins are ordinary Composer packages with a formal Plugin API, a skeleton and a shared asset system, and the directory lists more than a thousand. Most are third-party and their security is not reviewed, but there is plenty to choose from. Tabletop extensions are Composer packages too, built on S::register() and the client block registry, but there is no plugin API and no directory, and there is one first-party extension so far: an image-picker field for spatie/laravel-medialibrary. Expect to build what Filament users install.

Built-in features. Filament ships multi-tenancy with team switching, testing guides built on Livewire's helpers, and a Tailwind theme per panel. Tabletop ships no testing helpers, so you write plain Laravel and Pest feature tests. The package also lists its own gaps: no auth backend (the login screens are DSL pages and you supply the controllers), no CSV export or import, no search across models, and no multi-tenancy.

Choose Filament if…

Filament is the safer default for a team that works mostly in PHP.

• Your team builds UI in Blade and Livewire and wants custom fields and pages in the same stack.
• You need a stable major, a support policy and upgrade tooling now.
• You would rather install a plugin than build the piece yourself. The ecosystem gap is real.
• You need multi-tenancy out of the box.
• Your admin interface has to ship in many languages out of the box.

Choose Tabletop if…

Tabletop fits a narrower case.

• Your product's frontend is React 19, and you want custom admin UI built from the same components.
• You want screens authored in PHP with no Livewire on the page.
• Your content is multilingual and you want translatable fields, locale tabs and per-locale validation in core, not from a third-party plugin.
• You run several panels, each with its own guard, prefix and locales, and want them to share page classes.
• You are on PHP 8.4+ and can run a 0.x release: pin the minor and read the changelog before upgrading.