JavaScript grid and pivot library built for coding agents

Details

External ID

49643496

Source

HN

Company

—

Product

—

Website domain

—

Launched

Sept. 10, 2026

Cohort

—

Upvotes

9

Upvotes percentile

0.5422647527910686

Tags

—

Fetched at

Sept. 14, 2026, 5:28 p.m.

Updated at

Sept. 14, 2026, 5:28 p.m.

Description

Hi, I am building a js library for grids (and pivot tables) so that coding agents can use our primitives to deliver a grid based on your specifications.I started working on this problem because data displays like grids / pivot tables are tricky to get right as more and more features pile up (features like: pagination of data, virtualization, pivots, grouped views, custom renderers, filters, sort, etc)Pre llm and coding agents, I built https://github.com/chartshq/muze (that later got acquired by mode analytics) with grammar of graphics for developers. But I have always felt a library built for agents would have a fundamentally different philosophy than the one built for devs.What does an agent first js grid library mean?The library comes up with few primitives and mental models that agents can use reliably (https://www.superplot.dev/grid/our-approach/#principles/tabl...) alongside the design and architecture of the grid (open closed system + data flow + relinquishing right control to agents). Thus enforcing enough abstraction for agents that produce fewer bugs in a single shot (https://www.superplot.dev/grid/our-approach/#principles/head...).How is it different from a lib built for devs?Unlike a lib built for devs where the abstaction layer is much closer to humans (config driven like highcharts / aggrid), I belive having a different layer of abstraction from carefully defined building blocks and stable contracts help agents build reliable and stable outputs.For majority of the usecases, a user can ask an agent to build a particular representation of the grid (without waiting for the library to support it internally) to their liking. The agent would then go and build the grid with given constructs acting as guardrails. (Ofcourse there is a limit to that, for example if you want to do something which is outside the scope of mental model)What does it support?- Headless grid with virtualization - Local in browser datasource via duckdbwasm (supports pivot / tree / grouped data ops) - External datasource connection via our IR (codegen to db / semantic model should be easy given llm like structures) - Pivot + tree view + grouped data view - Table algebra support (that gets translated to IR for external datasource, for which agent can do codegen) - Pagination / data evictions for billions of row handling - Metadata plumbing (for usecases like complex cells where data needs to be generated from multiple differnet parameters) - Usage patterns / documentations (we are working on this)Some demos: https://www.superplot.dev/grid/#demos Github: https://github.com/superplothq/gridWould love to get your feedback on the approach as I continue to build the library.

• Source listing
• Website (no URL on record)