` #### `reset: Action` Reset width handle: `

` # addSelectedRows > Select rows in the table **Source:** [https://table.svelte.page/docs/plugins/add-selected-rows](https://table.svelte.page/docs/plugins/add-selected-rows) --- `addSelectedRows` keeps track of selected items in the table. Works with sub-rows. ## Options Options passed into addSelectedRows.```ts {3} const table = createTable(data, { select: addSelectedRows({ ... }), }); ``` ### `initialSelectedDataIds?: Record` Initial selected row data ids (by `row.dataId`). Default `{}`. ### `linkDataSubRows?: boolean` Link parent/sub-row selection when updating. Default `true`. ## Column Options Options passed into column definitions.```ts {7} const columns = table.createColumns([ table.column({ header: 'Name', accessor: 'name', plugins: { select: { ... }, }, }), ]); ``` ## Prop Set Extensions to the view model. Subscribe to .props().```svelte {#each $headerRows as headerRow (headerRow.id)} {rowProps.select} {#each headerRow.cells as cell (cell.id)} {props.select} {/each} {/each} ``` ### BodyRow props - `selected: boolean` - `someSubRowsSelected: boolean` - `allSubRowsSelected: boolean` ## Plugin State State provided by addSelectedRows.```ts {3} const { headerRows, rows, pluginStates } = table.createViewModel(columns); const { ... } = pluginStates.select; ``` ### `selectedDataIds: Writable>` ### `allRowsSelected: Writable` ### `someRowsSelected: Readable` ### `allPageRowsSelected: Writable` ### `somePageRowsSelected: Readable` ### `getRowState: (row) => SelectedRowsRowState` ## Examples # addSortBy > Sort table rows by column values **Source:** [https://table.svelte.page/docs/plugins/add-sort-by](https://table.svelte.page/docs/plugins/add-sort-by) --- `addSortBy` sorts table rows by column values. ## Options Options passed into addSortBy.```ts {3} const table = createTable(data, { sort: addSortBy({ ... }), }); ``` ### `initialSortKeys?: SortKey[]` Sets the initial sort keys. _Defaults to `[]`_. ### `disableMultiSort?: boolean` Disables multi-sorting for the table. _Defaults to `false`_. ### `isMultiSortEvent?: (event: Event) => boolean` Allows overriding the default multi-sort behavior. Takes an [Event](https://developer.mozilla.org/en-US/docs/Web/API/Event) and returns whether the action triggers a multi-sort. _Defaults to multi-sort on shift-click_. ### `toggleOrder?: ()[]` Allows customization of the toggling order. This cannot contain duplicate values. Set this to `['asc', 'desc']` to disable toggling to an unsorted column. _Defaults to `['asc', 'desc', undefined]`_. ### `serverSide?: boolean` If `true`, the sort plugin will have no effect on the rows of the table. Instead, you can control sorting by updating [`$data`](/docs/api/create-table#createtable-data-plugins-table). The plugin's state can be used as variables in your data-fetching query to get sorted data from the server directly. _Defaults to `false`_. ## Column Options Options passed into column definitions.```ts {7} const columns = table.createColumns([ table.column({ header: 'Name', accessor: 'name', plugins: { sort: { ... }, }, }), ]); ``` ## Examples # addSubRows > Define sub-rows of rows **Source:** [https://table.svelte.page/docs/plugins/add-sub-rows](https://table.svelte.page/docs/plugins/add-sub-rows) --- `addSubRows` defines the data for deriving the sub-rows of a row. Often used with `addExpandedRows` to visualize sub-rows. The id of a sub-row is in the format `{parentId}>{id}`. Nested sub-rows concatenate parent ids to the top-level row id. ## Options Options passed into addSubRows.```ts {3} const table = createTable(data, { sub: addSubRows({ ... }), }); ``` ### `children: string | (item) => Item[]` Define child items: either a string property on each data item or a function returning an array of child items. If `children` is missing or returns `[]`, no sub-rows are generated for that row. ## Column Options Options passed into column definitions.```ts {7} const columns = table.createColumns([ table.column({ header: 'Name', accessor: 'name', plugins: { sub: { ... }, }, }), ]); ``` ## Prop Set Extensions to the view model. Subscribe to .props().```svelte {#each $headerRows as headerRow (headerRow.id)} {rowProps.sub} {#each headerRow.cells as cell (cell.id)} {props.sub} {/each} {/each} ``` ## Plugin interactions - addSortBy: before => all sub-rows sorted within groups; after => only top-level sorted. - addColumnFilters: before => sub-rows are searched; after => only top-level rows searched. - addTableFilter: similarly affects whether sub-rows are searched. # addTableFilter > Filter table rows by searching all cell values **Source:** [https://table.svelte.page/docs/plugins/add-table-filter](https://table.svelte.page/docs/plugins/add-table-filter) --- `addTableFilter` filters table rows on data that may be in any column. ## Options Options passed into addTableFilter.```ts {3} const table = createTable(data, { filter: addTableFilter({ ... }), }); ``` ### `fn?: ({ filterValue, value }) => boolean` Custom filter. `filterValue` is a string; `value` is serialized to string by default. ### `initialFilterValue?: string` Default `''`. ### `includeHiddenColumns?: boolean` Whether hidden columns are included. Default `false`. ### `serverSide?: boolean` If `true`, use server-side filtering by updating `$data`. ## Column Options Options passed into column definitions.```ts {7} const columns = table.createColumns([ table.column({ header: 'Name', accessor: 'name', plugins: { filter: { ... }, }, }), ]); ``` ### `exclude?: boolean` Exclude the column from search. Default `false`. ### `getFilterValue?: (value) => string` Map a cell value to a filterable string. Default serializes value. ## Prop Set Extensions to the view model. Subscribe to .props().```svelte {#each $headerRows as headerRow (headerRow.id)} {rowProps.filter} {#each headerRow.cells as cell (cell.id)} {props.filter} {/each} {/each} ``` ### BodyCell `matches: boolean` — whether the cell matches the current filter value. ## Plugin State State provided by addTableFilter.```ts {3} const { headerRows, rows, pluginStates } = table.createViewModel(columns); const { ... } = pluginStates.filter; ``` ### `preFilteredRows: Readable[]>` ### `filterValue: Writable` ## Examples # addVirtualScroll > Virtualized table rendering for large datasets **Source:** [https://table.svelte.page/docs/plugins/add-virtual-scroll](https://table.svelte.page/docs/plugins/add-virtual-scroll) --- `addVirtualScroll` enables virtualized table rendering for large datasets (10,000+ rows). Only visible rows plus a configurable buffer are rendered in the DOM, dramatically improving performance. Subscribe to TableViewModel#pageRows instead of TableViewModel#rows.## Basic Usage ```svelte

{#if $topSpacerHeight > 0} {/if} {#each $pageRows as row (row.id)} {#each row.cells as cell (cell.id)} {/each} {/each} {#if $bottomSpacerHeight > 0} {/if}

``` The scroll container must have a fixed height and overflow-y: auto for virtualization to work.## Infinite Scroll `addVirtualScroll` supports infinite scroll with the `onLoadMore` and `hasMore` options: ```ts const hasMore = writable(true); const table = createTable(data, { virtualScroll: addVirtualScroll({ estimatedRowHeight: 48, bufferSize: 10, loadMoreThreshold: 200, hasMore, onLoadMore: async () => { const moreData = await fetchMoreItems(); data.update(d => [...d, ...moreData]); if (noMoreData) { hasMore.set(false); } } }) }); ``` ## Sparse Mode (server-paged datasets) Infinite scroll is append-only: reaching row 2,000,000 means loading every row before it. For datasets that are too large to materialize, pass `totalRows` to opt into **sparse mode**. The caller owns fetching and eviction; the plugin owns geometry. In sparse mode the table's `data` store holds only the rows currently resident, `dataOffset` says where that window starts in the full dataset, and `onRangeChange` tells you when to move it. All indices the plugin reports — `visibleRange`, `viewportRange`, `scrollToIndex`, `virtualIndex` — are absolute indices into the full dataset. ```ts const totalRows = writable(0); // filled from a cheap count query const dataOffset = writable(0); // absolute index of data[0] const data = writable([]); // only the resident window const table = createTable(data, { virtualScroll: addVirtualScroll({ estimatedRowHeight: 32, totalRows, dataOffset, onRangeChange: async ({ start, end }, { signal }) => { // Fetch just the pages intersecting the range, and drop the rest. const { rows, offset } = await fetchWindow(start, end, { signal }); // The range moves faster than a round trip. Without this check a slow // early response can land after a fast later one and republish a window // the user has already scrolled away from. if (signal.aborted) return; dataOffset.set(offset); data.set(rows); } }) }); ``` The rendered markup is identical to the basic example — spacer rows, `use:virtualScroll`, `use:measureRowAction`. The scroll container is sized from `totalRows`, so the user can drag straight to row 2,000,000 and only that page is fetched. Rows in the visible range that aren't resident yet simply don't render, and the spacers absorb their height. Widen the fetched window past visibleRange, or render skeleton rows from your own cache, to avoid a blank viewport during a fetch.### Browser scroll-height ceiling Browsers cap how tall an element can be — roughly **16,777,216px** in Chrome and Safari, with other engines varying. At 32px rows a naively-sized container would hit that wall at ~520,000 rows, and everything past it would be unreachable: the scrollbar bottoms out, and `scrollToIndex` doesn't help because the browser clamps `scrollTo` to the element's real height too. Sparse mode handles this for you. The container is sized to at most `maxScrollHeight` (default `16_000_000`), and when the dataset is larger the scroll position is mapped onto it proportionally. Rows still render at their natural height and lay out 1:1 around the viewport, so there is no drift or jitter — the mapping only decides which row anchors the top of the screen. The tradeoff is scroll *travel*. Over a 4,000,000-row dataset at 32px, the range is compressed ~8×, so one wheel notch covers ~24 rows instead of ~3. Datasets that fit under the cap are unaffected: the mapping is the identity and nothing changes. A few things to know: - **Row heights are uniform in sparse mode.** Rows outside the resident window can't be measured, so geometry uses the running average of the measured ones. Measurements still refine that average; `getRowHeight` feeds it but doesn't position individual rows. - **`onRangeChange` fires more than once during startup** as the viewport is measured. Debounce or de-duplicate in the handler if your fetch is expensive. - **Async handlers must respect `signal`.** It is aborted as soon as a newer range supersedes the one being served, and when the scroll container is destroyed. Pass it to `fetch` to cancel the request, and re-check `signal.aborted` before writing to `data` / `dataOffset` — otherwise out-of-order responses will republish a stale window. - **It is safe to update stores from `onRangeChange`.** The callback is deferred to a microtask, so it never writes to a store mid-derivation. - **Keep `dataOffset` and `data` in sync.** A stale offset shifts every rendered row. ## One instance per table Scroll position, viewport height and the measured-row-height cache live in the closure `addVirtualScroll()` returns, so they survive a view model rebuild. A component whose columns are derived rebuilds its view model on every reactive pass; without this, each rebuild would hand the mounted container to a discarded instance and the table would stop responding to scrolling. The tradeoff is that one result drives one rendered table. Construct it inline, per table: ```ts // Correct — each table gets its own geometry. const table = createTable(data, { virtualScroll: addVirtualScroll({ ... }) }); ``` Hoisting a single result to module scope and passing it to two `createTable` calls makes both tables share a scroll position and a height cache. That warns in the console. To scroll two views of the same data independently, give each its own table over the same `data` store: ```ts const data = writable(items); const left = createTable(data, { virtualScroll: addVirtualScroll({ ... }) }); const right = createTable(data, { virtualScroll: addVirtualScroll({ ... }) }); ``` Two view models built from a single table share one scroll position. A rebuild and a second concurrent view look the same from inside the plugin — both are another createViewModel call while a container is mounted — so use two tables when you need two independent viewports.## Options Options passed into addVirtualScroll.```ts {3} const table = createTable(data, { virtualScroll: addVirtualScroll({ ... }), }); ``` ### `estimatedRowHeight?: number` Default `40`. Estimated height of each row in pixels. Used for initial calculations before rows are measured. Actual heights are measured automatically. ### `bufferSize?: number` Default `10`. Number of rows to render above and below the visible area. Higher values reduce flicker during fast scrolling but render more DOM nodes. ### `onLoadMore?: () => void | Promise` Callback fired when more data should be loaded (infinite scroll). Return a promise to indicate when loading is complete. ### `hasMore?: Writable | boolean` Whether there is more data available to load. Can be a boolean or a Writable store. ### `loadMoreThreshold?: number` Default `200`. Number of pixels from the bottom to trigger `onLoadMore`. ### `getRowHeight?: (item: Item) => number` Optional function to get the exact height of a specific row. Enables precise variable row heights. ### `totalRows?: Readable | number` Total number of rows in the full dataset, independent of how many are loaded. Supplying this opts into [sparse mode](#sparse-mode-server-paged-datasets). ### `dataOffset?: Readable | number` Default `0`. Absolute index of the first row held in the table's `data` store. Sparse mode only — keep it in sync with `data` whenever the resident window moves. ### `maxScrollHeight?: number` Default `16_000_000`. Largest height, in pixels, to give the scroll container. Sparse mode only. When `totalRows × rowHeight` exceeds this, the scroll range is compressed onto it so the tail of the dataset stays reachable — see [the scroll-height ceiling](#browser-scroll-height-ceiling). ### `onRangeChange?: (range: { start: number; end: number }, context: { signal: AbortSignal }) => void` Fired whenever the visible range changes, so a caller can fetch the pages intersecting it and evict the ones that have scrolled away. In sparse mode the range is in absolute dataset indices. Invoked on a microtask, so it is safe to update stores from within it. `context.signal` is aborted as soon as a newer range supersedes this one, or when the scroll container is destroyed. Async handlers should pass it to `fetch` and re-check `signal.aborted` before publishing results. ## Plugin State State provided by addVirtualScroll.```ts {3} const { headerRows, pageRows, pluginStates } = table.createViewModel(columns); const { ... } = pluginStates.virtualScroll; ``` ### `virtualScroll: Action` Svelte action to attach to the scroll container. Handles scroll event listeners and viewport tracking. ### `topSpacerHeight: Readable` Height of the top spacer element in pixels. ### `bottomSpacerHeight: Readable` Height of the bottom spacer element in pixels. ### `measureRowAction: Action` Svelte action to attach to each row for automatic height measurement. Usage: ``. ### `scrollToIndex: (index: number, options?) => void` Scroll to a specific row index programmatically. In sparse mode the index is absolute and may point outside the resident window, and every `align` mode accounts for any scroll-range compression. ```ts // Scroll options scrollToIndex(100, { align: 'start' | 'center' | 'end' | 'auto', behavior: 'auto' | 'smooth' }); ``` ### `visibleRange: Readable<{ start: number; end: number }>` Range of currently rendered row indices, padded by `bufferSize` on both ends. Absolute dataset indices in sparse mode. Use this to decide what to fetch; use `viewportRange` to tell the user what they are looking at. ### `viewportRange: Readable<{ start: number; end: number }>` Rows actually intersecting the viewport, with no render buffer — the range a "rows N–M of T" footer, a scroll-progress readout or a "jump to row" indicator should report. Absolute dataset indices in sparse mode, with any scroll-range compression already undone, so you never re-derive that mapping yourself. `end` is exclusive. ```svelte Rows {$viewportRange.start + 1}–{$viewportRange.end} of {$totalRows} ``` Anything you render above the rows — an in-flow <thead>, a caption, a toolbar — shifts where row 0 begins inside the scroll container. The plugin measures that offset from the first rendered row, so this range tracks what's on screen with no configuration. A position: sticky header additionally covers the top of the viewport at every scroll position; add use:measureHeaderAction to it so the rows underneath are excluded too.### `measureHeaderAction: Action` Attach to content that paints over the top of the viewport — in practice a `position: sticky` ``. ```svelte ``` A sticky header keeps the space it occupies in the document, so the plugin already knows where the rows start, but it also goes on hiding the top of the viewport as you scroll. Without this, the rows behind it are still counted as visible and `viewportRange` names rows the user can't see — and `scrollToIndex` parks its target underneath the header instead of below it. You don't need it for a header that scrolls away with the rows; that case is measured automatically. Attaching it to one anyway is harmless, since it reports no overlap once it's out of view. ### `totalHeight: Readable` Total height of all rows (for scroll container sizing). ### `totalRows: Readable` Total number of rows in the dataset. In sparse mode this is the configured dataset total rather than the number of rows loaded. ### `dataOffset: Readable` Absolute index of the first row held in the table's `data` store. Always `0` outside sparse mode. ### `renderedRows: Readable` Number of rows currently rendered in the DOM. ### `scrollTop: Readable` Current scroll position of the container. ### `viewportHeight: Readable` Height of the scroll container viewport. ### `isLoading: Readable` Whether more data is currently being loaded. ### `hasMore: Readable` Whether there is more data available to load. ### `measureRow: (rowId: string, height: number) => void` Manually notify the plugin that a row has been measured. Usually not needed when using `measureRowAction`. ## How It Works 1. **Spacer Rows**: Instead of CSS transforms, the plugin uses spacer `` elements to maintain scroll position. This preserves semantic table structure and accessibility. 2. **Height Management**: Row heights are cached as they're measured. The `HeightManager` class tracks measured heights and calculates average heights for unmeasured rows. 3. **Visible Range Calculation**: Based on scroll position, viewport height, and cached row heights, the plugin calculates which rows should be rendered. 4. **Automatic Measurement**: The `measureRowAction` uses ResizeObserver to automatically measure and cache row heights as they render. ## Performance Tips - **Use `table-layout: fixed`** on your `` element. With virtual scroll, only a subset of rows is rendered at any time. The default `table-layout: auto` recalculates column widths based on visible content, causing header columns to shift as you scroll through rows with varying content lengths. `table-layout: fixed` locks column widths to the header, preventing layout jitter. - Use a reasonable `bufferSize` (10-20) to balance between smooth scrolling and DOM size - The `estimatedRowHeight` doesn't need to be exact - actual heights are measured automatically - For very large datasets (100,000+ rows), combine server-side paging with [sparse mode](#sparse-mode-server-paged-datasets) so only the pages you look at are ever held in memory - Avoid complex components in cells that cause expensive re-renders # The Plugin System > Extending the functionality of Svelte Headless Table with powerful plugins **Source:** [https://table.svelte.page/docs/plugins/overview](https://table.svelte.page/docs/plugins/overview) --- Svelte Headless Table is designed with extensibility in mind. Its complex features are powered by an extensive suite of plugins.

{pluginName}

## Defining plugins Svelte Headless Table treats each plugin as an extension to its core. Every plugin optionally defines transformations on the rows and columns of the table, and extends the functionality of column definitions, rows, and cells. For this example, we extend a basic table with `addSortBy` and `addColumnOrder`. ```ts {3-4} const table = createTable(data, { sort: addSortBy({ disableMultiSort: true }), colOrder: addColumnOrder() }) ``` Plugins are configurable via function arguments. `sort` and `colOrder` are just names to identify the plugins – they can be any name you prefer as long as they remain consistent. This lets you add multiple plugins to a table without any naming conflicts.The order in which you define plugins matters – [the order of object keys is predictable](https://www.stefanjudis.com/today-i-learned/property-order-is-predictable-in-javascript-objects-since-es2015/) and plugins are evaluated from first to last. --- # Comparisons Compare Svelte Headless Table with alternative libraries. - [TanStack Table](https://table.svelte.page/compare/vs-tanstack-table.md): https://table.svelte.page/compare/vs-tanstack-table - [svelte-table](https://table.svelte.page/compare/vs-svelte-table.md): https://table.svelte.page/compare/vs-svelte-table - [@vincjo/datatables](https://table.svelte.page/compare/vs-vincjo-datatables.md): https://table.svelte.page/compare/vs-vincjo-datatables - [Flowbite Svelte Datatable](https://table.svelte.page/compare/vs-flowbite-svelte-datatable.md): https://table.svelte.page/compare/vs-flowbite-svelte-datatable - [AG Grid](https://table.svelte.page/compare/vs-ag-grid.md): https://table.svelte.page/compare/vs-ag-grid - [Handsontable](https://table.svelte.page/compare/vs-handsontable.md): https://table.svelte.page/compare/vs-handsontable # Svelte Headless Table vs AG Grid A full enterprise grid vs a Svelte-native headless table toolkit ## Overview AG Grid is a complete, styled data-grid platform with community and paid Enterprise features, including pivoting, master/detail, range selection, charts, and a server-side row model. It has no first-party Svelte adapter; Svelte applications can mount the JavaScript grid directly or use an outdated community wrapper. @humanspeak/svelte-headless-table is a first-party Svelte 5 headless toolkit for applications that want to own the markup and do not need spreadsheet-grade enterprise features. - **Svelte Headless Table site:** https://table.svelte.page - **Svelte Headless Table npm:** https://www.npmjs.com/package/%40humanspeak%2Fsvelte-headless-table - **Svelte Headless Table slug:** svelte-headless-table - **Category:** Multi-framework enterprise grid - **Approach:** Configuration-driven `ag-grid-community` core + framework wrappers - **Website:** https://www.ag-grid.com - **GitHub:** https://github.com/ag-grid/ag-grid - **npm:** https://www.npmjs.com/package/ag-grid-community ## Feature comparison | Feature | @humanspeak/svelte-headless-table | AG Grid | Notes | | --- | --- | --- | --- | | Svelte 5 Native | Yes | No | `ag-grid-svelte@0.3.0` is an unofficial wrapper declaring `svelte: ^3` and `ag-grid-community: ^28 \|\| ^29 \|\| ^30`; current `ag-grid-community` is v36.1.0. Direct JavaScript mounting remains possible. | | First-Party Svelte Support | Yes | No | | | TypeScript Support | Yes | Yes | | | Headless Rendering | Yes | No | | | Sorting | Yes | Yes | | | Column Filters | Yes | Set / number / date filters | | | Pagination | Yes | Yes | | | Group By | addGroupBy plugin | Row + value grouping (Enterprise) | | | Pivot Tables | No | Enterprise only | | | Tree Data / Sub-Rows | Yes | Enterprise only | | | Master / Detail | No | Enterprise only | | | Row Selection | Yes | Yes | | | Column Resizing | Yes | Yes | | | Column Reordering | Yes | Yes | | | Virtual Scroll | addVirtualScroll plugin | First-class row virtualisation | | | Server-Side Row Model | BYO — store handles fetch | Enterprise only | | | Range / Cell Selection | No | Enterprise only | | | Licence | MIT | Community MIT, Enterprise commercial | | | GitHub Stars | Smaller community | ~15k | | ## Svelte Headless Table strengths - First-party Svelte 5 support via the package peer dependency — no community wrapper required - Application owns semantic table markup and can use any design system - Every shipped plugin is MIT; grouping and hierarchical rows are not paid features - Smaller conceptual and bundle surface for conventional application tables ## AG Grid strengths - Industry-leading feature set — pivot, master/detail, range selection, integrated charts - Server-Side Row Model handles infinite / large datasets through the framework, not the app - Enterprise support contracts available with SLAs - Battle-tested in financial, analytics, and BI dashboards at very large scale ## Svelte Headless Table limitations - You build all table markup, controls, and styling - Far smaller ecosystem and less evidence from very large production datasets - No pivot tables, range selection, or master/detail out of the box - No managed server-side row model — you wire data fetching yourself ## AG Grid limitations - No first-party Svelte integration; the unofficial wrapper targets Svelte 3 and AG Grid v28–30 while the current core is v36 - Pivot, tree data, master/detail, and server-side row model are gated behind the paid Enterprise licence - More package and API surface than conventional tables need - Markup and theming are controlled through AG Grid APIs rather than application-owned table elements ## Verdict Choose AG Grid when the grid is a major product surface and you need pivoting, master/detail, range selection, managed server-side data, enterprise support, or its mature ecosystem. Choose @humanspeak/svelte-headless-table for a Svelte 5 application table when first-party Svelte integration, application-owned markup, a smaller surface, and MIT grouping or hierarchical-row features matter more than enterprise-grid breadth. AG Grid Community is also MIT; licensing only differentiates features that AG Grid reserves for Enterprise. ## Keywords ag-grid svelte, ag-grid alternative, ag-grid enterprise, svelte enterprise data grid, ag-grid community # Svelte Headless Table vs Flowbite Svelte Datatable A ready-made Flowbite table vs complete markup and state control ## Overview @flowbite-svelte-plugins/datatable is a Svelte 5 and Tailwind 4 component built for the Flowbite Svelte design system. It provides styled table chrome and practical datatable controls with little setup. @humanspeak/svelte-headless-table owns table state but renders no UI, making it a better foundation when the application must own every element or use another design system. Both are TypeScript-first and MIT-licensed. - **Svelte Headless Table site:** https://table.svelte.page - **Svelte Headless Table npm:** https://www.npmjs.com/package/%40humanspeak%2Fsvelte-headless-table - **Svelte Headless Table slug:** svelte-headless-table - **Category:** Tailwind-styled datatable plugin - **Approach:** Pre-styled component bound to the Flowbite Svelte design system - **Website:** https://github.com/shinokada/flowbite-svelte-plugins - **GitHub:** https://github.com/shinokada/flowbite-svelte-plugins - **npm:** https://www.npmjs.com/package/%40flowbite-svelte-plugins%2Fdatatable ## Feature comparison | Feature | @humanspeak/svelte-headless-table | Flowbite Svelte Datatable | Notes | | --- | --- | --- | --- | | Svelte 5 Native | Yes | Yes | `@flowbite-svelte-plugins/datatable@0.4.1` peerDependencies: `svelte: ^5.0.0`, `tailwindcss: ^4.1.4`. | | TypeScript Support | Yes | Yes | | | Headless Rendering | Yes | No | Plugin renders Flowbite-styled table chrome; intended to be visually consistent with the Flowbite Svelte ecosystem. | | Design System Lock-in | None — drop into any CSS | Tied to Flowbite Svelte + Tailwind 4 | | | Sorting | Yes | Yes | | | Filtering | Yes | Yes | | | Pagination | Yes | Yes | | | Row Selection | addSelectedRows plugin | Yes | | | Prebuilt Table UI | No | Flowbite-styled component | | | Group By | addGroupBy plugin | Not documented | | | Sub-Rows / Expansion | addExpandedRows + addSubRows | Not documented | | | Column Resizing | addResizedColumns plugin | Not documented | | | Column Reordering | addColumnOrder plugin | Not documented | | | Virtual Scroll | addVirtualScroll plugin | Not documented | | | Licence | MIT | MIT | Licence is parity, not a differentiator. | ## Svelte Headless Table strengths - Application owns every table element and can use any design system or CSS strategy - Plugin set covers grouping, hierarchical rows, virtual scrolling, and column resize / reorder - Cell content can be an ordinary Svelte component rather than a string-producing render callback ## Flowbite Svelte Datatable strengths - Visually consistent with the rest of a Flowbite Svelte UI out of the box - Prebuilt pagination, search, sorting, row selection, and table controls minimise setup - Extensive simple-datatables options and render hooks for common datatable customisation - Single-component experience inside Flowbite-based apps ## Svelte Headless Table limitations - No prebuilt chrome — you write the table markup, controls, and styles - More setup than a ready-made Flowbite component - Plugin order affects row transformations ## Flowbite Svelte Datatable limitations - Requires Tailwind 4 and is designed around the Flowbite Svelte visual system - Component-owned markup offers less structural control than a headless view model - No documented grouping, hierarchical rows, column resize / reorder, or virtual scrolling ## Verdict Choose Flowbite Svelte Datatable when the application already uses Flowbite and a styled, low-setup table is the goal. Choose @humanspeak/svelte-headless-table when you need complete markup ownership, another design system, Svelte component renderers, grouping, hierarchical rows, column operations, or integrated virtual scrolling. Svelte 5, TypeScript, sorting, filtering, pagination, selection, and MIT licensing are shared capabilities. ## Keywords flowbite svelte datatable, flowbite-svelte-plugins, svelte tailwind datatable, flowbite table, svelte 5 styled datatable # Svelte Headless Table vs Handsontable A spreadsheet-grade data grid vs a Svelte-native application table ## Overview Handsontable is a spreadsheet-style JavaScript data grid with first-party React, Angular, and Vue integrations, plus a vanilla JavaScript API that Svelte applications can mount directly. It provides editing, range selection, formulas, copy/paste, merged cells, and frozen regions. @humanspeak/svelte-headless-table is a headless Svelte 5 toolkit for rendering application data tables, not a substitute for spreadsheet workflows. - **Svelte Headless Table site:** https://table.svelte.page - **Svelte Headless Table npm:** https://www.npmjs.com/package/%40humanspeak%2Fsvelte-headless-table - **Svelte Headless Table slug:** svelte-headless-table - **Category:** JavaScript spreadsheet component - **Approach:** Spreadsheet UI with Excel-compatible interactions, mounted on a DOM node - **Website:** https://handsontable.com - **GitHub:** https://github.com/handsontable/handsontable - **npm:** https://www.npmjs.com/package/handsontable ## Feature comparison | Feature | @humanspeak/svelte-headless-table | Handsontable | Notes | | --- | --- | --- | --- | | Svelte 5 Native | Yes | No | Handsontable advertises itself as a Data Grid for React, Angular, and Vue — no first-party Svelte wrapper exists on npm. | | TypeScript Support | Yes | Yes | | | Headless Rendering | Yes | No | | | Sorting | Yes | Yes | | | Filtering | Yes | Yes | | | Pagination | Yes | No | Spreadsheets scroll the full sheet; pagination is not a typical pattern. | | Inline Cell Editing | Application-owned EditableCell renderer | First-class editors and cell types | | | Cell Formulas | No | HyperFormula engine | | | Range / Cell Selection | No | Yes | | | Copy / Paste from Excel | No | Yes | | | Merged Cells | No | Yes | | | Frozen Rows + Cols | No | Yes | | | Virtual Scroll | addVirtualScroll plugin | Yes | | | Group By | addGroupBy plugin | No | | | GitHub Stars | Smaller community | ~22k | | | Licence | MIT | Non-commercial free / Commercial paid | | ## Svelte Headless Table strengths - First-party Svelte 5 API with familiar stores and Svelte component renderers - Application owns semantic table markup and can use any design system - MIT licence permits commercial use without a paid Handsontable licence - Focused table-state surface when spreadsheet interactions are unnecessary ## Handsontable strengths - Excel-like interactions out of the box — formulas, range selection, copy/paste from Excel - HyperFormula engine for spreadsheet-grade calculation - Excellent fit for data-entry-heavy admin UIs and CRUD spreadsheets - Long history (since 2012) with active commercial support ## Svelte Headless Table limitations - Not a spreadsheet — no formulas, range selection, merged cells, frozen regions, or Excel paste - Editing is an application-owned renderer pattern rather than a built-in editor system - You build all table markup, controls, and styling ## Handsontable limitations - No first-party Svelte integration — mount on a div ref like a vanilla JS widget - Commercial use requires a paid licence - Substantially more UI and API surface than a read-oriented application table needs - Handsontable owns the grid DOM and styling model rather than exposing application-owned table markup ## Verdict Choose Handsontable when users need a spreadsheet: rich editing, formulas, range selection, Excel-style copy/paste, merged cells, or frozen regions justify its grid model and commercial licence. Choose @humanspeak/svelte-headless-table when the product needs a Svelte-native application table with owned markup, composable data operations, and MIT commercial use. These tools solve different jobs more than they compete feature-for-feature. ## Keywords handsontable svelte, svelte spreadsheet, handsontable alternative, svelte data grid, svelte excel-like table # Svelte Headless Table vs svelte-table A drop-in sortable component vs a composable table toolkit ## Overview svelte-table by dasDaniel is a small, MIT-licensed component for sorting, filtering, searching, selecting, and expanding rows. Its last release was v0.6.5 in July 2025 and it declares no Svelte peer dependency. @humanspeak/svelte-headless-table requires more setup, but provides explicit Svelte 5 support, full markup ownership, and plugins for pagination, grouping, hierarchical data, column operations, and virtual scrolling. - **Svelte Headless Table site:** https://table.svelte.page - **Svelte Headless Table npm:** https://www.npmjs.com/package/%40humanspeak%2Fsvelte-headless-table - **Svelte Headless Table slug:** svelte-headless-table - **Category:** Headless table component - **Approach:** Single `` component with extensive className + render props - **Website:** https://github.com/dasDaniel/svelte-table - **GitHub:** https://github.com/dasDaniel/svelte-table - **npm:** https://www.npmjs.com/package/svelte-table ## Feature comparison | Feature | @humanspeak/svelte-headless-table | svelte-table | Notes | | --- | --- | --- | --- | | Svelte 5 Support | Yes | Not declared | `svelte-table@0.6.5` ships no `peerDependencies` field; flexibility is up to the runtime. | | TypeScript Support | Yes | Yes | | | Markup Ownership | Application owns the complete table tree | Component-owned markup with slots, renderers, and class props | | | Sorting | Yes | Yes | | | Column Filters | Yes | Yes | | | Search | addTableFilter plugin | Yes | | | Row Selection | addSelectedRows plugin | Yes | | | Row Expanding | addExpandedRows plugin | Yes | | | Pagination | addPagination plugin | No | | | Group By | addGroupBy plugin | No | | | Sub-Rows / Tree Data | addSubRows plugin | No | | | Column Resizing | addResizedColumns plugin | No | | | Column Reordering | addColumnOrder plugin | No | | | Hidden Columns | addHiddenColumns plugin | No | | | Virtual Scroll | addVirtualScroll plugin | No | | | Custom Cell Renderers | createRender(Component) | Components or functions | | | GitHub Stars | Smaller community | ~560 | | | Licence | MIT | MIT | Licence is parity, not a differentiator. | ## Svelte Headless Table strengths - Pagination, group-by, sub-rows, column resize / reorder, and virtual scroll are first-class plugins - The application owns every table element rather than styling component-owned markup through class props - Explicit Svelte 5 peer dependency and actively maintained Svelte 5 implementation ## svelte-table strengths - Single-component API — drop in a `` and pass props - Tiny bundle footprint - Built-in sorting, filters, search, selection, and expandable content cover many small tables - Components or functions can render custom cell content ## Svelte Headless Table limitations - More setup and concepts than a single component - Not the fastest path to a simple sortable-table prototype - Smaller community despite the broader feature surface ## svelte-table limitations - No pagination, group-by, sub-rows, column resize, or virtual scroll - Single-component API limits markup customisation beyond `className*` props - No declared Svelte 5 peer dependency — compatibility is implicit rather than contractual - No release since July 2025 ## Verdict Choose svelte-table when a tiny drop-in component with sorting, filtering, selection, and expandable content is enough and minimal setup matters most. Choose @humanspeak/svelte-headless-table when you need explicit Svelte 5 support, complete control of table markup, pagination, grouping, hierarchical rows, column resize or reorder, or virtual scrolling. TypeScript and MIT licensing are parity. ## Keywords svelte-table, dasDaniel svelte-table, svelte sortable table, svelte simple table, svelte minimal table component # Svelte Headless Table vs TanStack Table A focused Svelte table API vs a larger multi-framework ecosystem ## Overview Both libraries are MIT-licensed, headless, TypeScript-first, and native to Svelte 5. TanStack Table v9 provides a runes-native Svelte adapter over a high-performance core shared across ten frameworks. @humanspeak/svelte-headless-table is the narrower option: its public API, documentation, stores, plugin state, and component renderers are designed only for Svelte. The choice is focus and familiarity versus ecosystem breadth and advanced features — not Svelte 5 support or licensing. - **Svelte Headless Table site:** https://table.svelte.page - **Svelte Headless Table npm:** https://www.npmjs.com/package/%40humanspeak%2Fsvelte-headless-table - **Svelte Headless Table slug:** svelte-headless-table - **Category:** Headless table primitives (multi-framework) - **Approach:** Framework-agnostic core + per-framework adapter - **Website:** https://tanstack.com/table - **GitHub:** https://github.com/TanStack/table - **npm:** https://www.npmjs.com/package/%40tanstack%2Fsvelte-table ## Feature comparison | Feature | @humanspeak/svelte-headless-table | TanStack Table | Notes | | --- | --- | --- | --- | | Svelte 5 Support | Yes | Yes | Both packages support Svelte 5 natively. `@tanstack/svelte-table@9.1.2` declares `svelte: ^5.0.0` and uses runes with Svelte-aware atom bindings. | | TypeScript Support | Yes | Yes | | | Headless Rendering | Yes | Yes | Both libraries leave markup and styling entirely to the application. | | Sorting | Yes | Yes | | | Column Filters | Yes | Yes | | | Global Filter | addTableFilter plugin | Yes | | | Pagination | Yes | Yes | | | Group By | addGroupBy plugin | Yes | | | Expanded / Sub-Rows | addExpandedRows + addSubRows | Yes | | | Row Selection | addSelectedRows plugin | Yes | | | Column Resizing | addResizedColumns plugin | Yes | | | Column Ordering | addColumnOrder plugin | Column-order state; pair with a DnD library for drag controls | | | Column Visibility | addHiddenColumns plugin | Yes | | | Column Pinning | No | Yes | | | Row Pinning | No | Yes | | | Virtualization | addVirtualScroll plugin | Pair with TanStack Virtual or another virtualizer | | | Editable Data | createRender(EditableCell) | Documented pattern | | | API Style | Svelte stores + named plugin builders + pluginStates | TanStack Store atoms + framework adapter | | | GitHub Stars | Smaller community | 28k+ | | | Licence | MIT | MIT | Licence is parity, not a differentiator. | ## Svelte Headless Table strengths - Svelte-only public API and documentation — there is no framework-neutral guide to translate into Svelte concepts - Table behaviours are named plugins on one createTable call, with their stores grouped under pluginStates - Cell renderers are ordinary Svelte components through createRender, and the view model exposes familiar Svelte stores - Integrated addVirtualScroll plugin for semantic table virtualization without choosing and wiring a separate virtualizer ## TanStack Table strengths - Runes-native Svelte 5 adapter backed by TanStack Store atoms - Battle-tested core shared across React, Vue, Solid, Svelte, Qwik, Angular, Lit, and other adapters - Massive ecosystem (~28k GitHub stars) and rich third-party tooling - Column pinning, row pinning, and a broader set of advanced table primitives - Published large-table performance work and tree-shakable feature registration - Cross-framework knowledge transfer — same mental model in every adapter ## Svelte Headless Table limitations - Much smaller community and third-party ecosystem - No column pinning or row pinning yet — open feature requests - No published large-table benchmark suite to compare with TanStack v9 claims - Plugin order affects transformations and must be understood when composing complex tables ## TanStack Table limitations - Framework-agnostic core plus a Svelte adapter introduces more concepts and type boundaries than a Svelte-only API - Broader feature surface can mean more API to learn when you only need a focused data table - Virtualization requires choosing and integrating TanStack Virtual or another virtualizer ## Verdict TanStack Table is the stronger default when you need pinning, a large ecosystem, published performance work, or one table model across frameworks. Choose @humanspeak/svelte-headless-table when your application is Svelte-only, its focused feature set covers the job, and you prefer named plugins, pluginStates, Svelte stores, and Svelte component renderers over adopting the broader TanStack model. Both are native to Svelte 5, headless, TypeScript-first, and MIT. ## Keywords tanstack table, tanstack svelte table, tanstack table svelte 5, svelte headless table, tanstack table vs svelte headless table # Svelte Headless Table vs @vincjo/datatables Server-friendly table handlers vs a broader plugin-composed table model ## Overview Both libraries are MIT-licensed, TypeScript-first, and native to Svelte 5. @vincjo/datatables centres on a TableHandler with concise client- and server-side APIs plus optional prebuilt controls. @humanspeak/svelte-headless-table uses named plugins and a store-based view model to cover a broader set of structural table behaviours. Vincjo is the more direct fit for server-driven CRUD tables; ours is the stronger fit for grouped, hierarchical, resizable, reorderable, or virtualized tables. - **Svelte Headless Table site:** https://table.svelte.page - **Svelte Headless Table npm:** https://www.npmjs.com/package/%40humanspeak%2Fsvelte-headless-table - **Svelte Headless Table slug:** svelte-headless-table - **Category:** Headless datatable toolkit - **Approach:** Data handler + slot-driven table HTML you write yourself - **Website:** https://vincjo.fr/datatables - **GitHub:** https://github.com/vincjo/datatables - **npm:** https://www.npmjs.com/package/%40vincjo%2Fdatatables ## Feature comparison | Feature | @humanspeak/svelte-headless-table | @vincjo/datatables | Notes | | --- | --- | --- | --- | | Svelte 5 Native | Yes | Yes | `@vincjo/datatables@2.8.1` declares `svelte: ^5.56.1` — both packages target Svelte 5. | | TypeScript Support | Yes | Yes | | | Headless Rendering | Yes | Yes | | | Sorting | Yes | Yes | | | Column Filters | Yes | Yes | | | Global Filter | Yes | Yes | | | Pagination | Yes | Yes | | | Server-Side / Lazy Mode | BYO — store handles the fetch | First-class lazy-loading mode | | | Row Selection | Yes | Yes | | | Group By | addGroupBy plugin | No | | | Sub-Rows / Expansion | addExpandedRows + addSubRows | No | | | Column Resizing | addResizedColumns plugin | No | | | Column Reordering | addColumnOrder plugin | No | | | Hidden Columns | addHiddenColumns plugin | Yes | | | Virtual Scroll | addVirtualScroll plugin | No | | | GitHub Stars | Smaller community | ~585 | | | Licence | MIT | MIT | Licence is parity, not a differentiator. | ## Svelte Headless Table strengths - Group-by, expansion, column reorder / resize / hide, and virtual scroll are first-class plugins - Named plugin stores expose each behaviour through one pluginStates object - Cell renderers are ordinary Svelte components through createRender ## @vincjo/datatables strengths - First-class lazy-loading / server-driven sort + filter + paginate handler - Smaller surface to learn for common sort, filter, paginate, and select workflows - Optional Datatable, Search, RowsPerPage, RowCount, and Pagination components reduce setup - Rune-backed handler properties and concise setter methods minimise boilerplate ## Svelte Headless Table limitations - No dedicated server-side handler — you wire plugin state into data fetching yourself - More concepts and markup to learn for a conventional CRUD table - Plugin order affects row transformations ## @vincjo/datatables limitations - No documented group-by, sub-row hierarchy, column reorder / resize, or virtual scroll - Smaller plugin surface — long-tail table features need DIY implementation ## Verdict Choose @vincjo/datatables for a conventional sort, filter, paginate, and select table — especially when the server owns the data operations or its optional controls save useful setup. Choose @humanspeak/svelte-headless-table when the table needs grouping, hierarchical rows, integrated virtual scrolling, or column resize and reorder. Svelte 5, TypeScript, headless markup, hidden columns, and MIT licensing are not reasons to choose between them. ## Keywords @vincjo/datatables, vincjo datatables, svelte 5 datatable, svelte server-side datatable, svelte lazy-loading table