u/tonygoodchild

We updated our grid to support a full Gantt chart could follow the hypermedia approach: the server sends HTML, and the page carries no JSON API and no new Gantt(...) call.

Demo: https://toclocoinc.github.io/lattice-grid-demo-htmx-gantt/
Code: https://github.com/toclocoinc/lattice-grid-demo-htmx-gantt

How it works:

• The server renders an ordinary task table (id, name, phase, start, end, % done) inside <div data-lattice-gantt>. With JS off you still get a readable table full of tasks. With JS on, the Lattice htmx module turns it into a task grid and timeline on htmx:load.
• Project switch: a plain hx-get returns a new table fragment, and the old Gantt is cleaned up on htmx:beforeCleanupElement before the new one is built.
• Server-side change: "Server slips one task" returns a single <tr data-lattice-row="P3.1" hx-swap-oob="true">. Only that task's bar moves, and zoom, scroll and collapsed phases stay put.
• Saving edits: dragging a bar fires a bubbling lattice:gantt-change event, so hx-trigger="lattice:gantt-change" plus hx-post is the whole save path. The server answers with a line of HTML.
• Back button: zoom, scroll and collapsed rows ride along in htmx's history snapshot.

GitHub Pages is static, so the demo uses a small in-browser stand-in that answers htmx's requests from route handlers in src/server.js. They have the same shape as Django, Rails, Go or Laravel handlers (take params, return HTML), so you can see exactly what a real backend would send.

It's plain JS with no build step, about 150 lines of wiring plus the data.

It's free for non-commercial and local dev.

https://www.latticegrid.dev/

Half a million Overture places for Greater London, queried in the browser by DuckDB-WASM directly against the remote Parquet file. No backend, no copy of the data in the repo: the first query issues HTTPS range requests and reads only the row groups covering the London bounding box, about 40 MB of the 203 MB. The KPI tiles report bytes fetched from DuckDB's own file statistics, not a client-side guess.

After that first read the London rows are copied into a local DuckDB-WASM table with an R-tree index on the geometry, and the remote engine is closed. A borough count is 40 to 50 ms locally against 0.8 to 3.6 s remote. Every pan and zoom of the map is a bounding-box query against that table, and past 20,000 rows in view the engine returns density cells that draw as hexagons instead of points.

The grid on top is Lattice Grid (commercial, free on localhost). It sits on a pushdown source with a DuckDB adapter, so every filter, sort, aggregate and pivot the user does becomes SQL DuckDB runs; the last statement is shown beside the grid. Nothing is held in JS arrays.

Live: https://toclocoinc.github.io/lattice-grid-demo-geo-places/
Source: https://github.com/toclocoinc/lattice-grid-demo-geo-places

Sibling demo, same engine: drop a 10-million-row Parquet file and the grid, charts and statistics run against it in a worker with zero bytes uploaded, proven by a Resource Timing readout on the page: https://toclocoinc.github.io/lattice-grid-demo-local-file/

One thing these two do not show: the grid has a data router for feeding several live sources into many views at once (one feed in, table, map, KPIs and charts all reading the same rows, keyed diffs on updates). The demos that show it run on live network and trade feeds rather than DuckDB.

Data: Overture Maps places, CDLA-Permissive-2.0. Tiles: OpenFreeMap.

Each month is a server-rendered <table>. A <select hx-get> swaps the month in, and a script-tag data grid hydrates the table into a sortable, filterable, groupable grid with KPI tiles and four charts bound to it. No npm, no bundler, no build step. The "server" is a set of static fragments rendered weekly from HMRC's published figures, because their API refuses cross-origin browser calls, and a verify script fails the build if the page ever tries to call it.

Live: https://toclocoinc.github.io/lattice-grid-demo-uktradeinfo-htmx/
Source: https://github.com/toclocoinc/lattice-grid-demo-uktradeinfo-htmx

Known limits are in the README

We're going to be released a combined Mac OS / iPad DynamoDB client soon and looking for beta testers - anyone interested?

We're going to be released a combined Mac OS / iPad DynamoDB client soon and looking for beta testers - anyone interested?

We're going to be released a combined Mac OS / iPad DynamoDB client soon and looking for beta testers - anyone interested?