Jantt: a Gantt chart engine that takes JSON, not an imperative API

Timeline data as a document rather than a set of API calls

Jantt is a Gantt chart engine written in TypeScript, and its central idea is that a timeline is a JSON document rather than the result of a sequence of imperative calls. The README contrasts this with suites that require setup and task-creation calls, and with DSLs such as Mermaid that render static images which cannot be dragged, edited or recalculated. Jantt's claim is that the chart is a pure function of the document, and that the document can be edited, synchronised back and fed to a model.

The engine lives in the @jantt/core package, described as pure zero-dependency TypeScript under 14KB gzipped, with the README badge showing zero runtime dependencies and a TypeScript 5.4 target. Around it sit a React binding, a standalone build, a Node CLI, and a playground application, all organised as npm workspaces.

That JSON-first framing is the reason the project claims to suit autonomous agents. The README argues that a declarative schema contract removes the chance of a model hallucinating UI, and that generating timeline data costs far fewer tokens than generating JSX. That comparison is a claim in the README rather than a measurement we can repeat, but the underlying design choice is visible in the repository: there is a schema/ directory and a docs/schema-spec.md, so the contract is a checked artefact rather than a convention.

Reading the comparison matrix without the marketing

The README puts Jantt next to DHTMLX Gantt, Frappe Gantt and Mermaid.js in a table, and the table is more informative than the surrounding prose. On runtime dependencies Jantt is listed at zero, the other three at multiple. On state paradigm, Jantt is declarative JSON, the two commercial or open suites are imperative JavaScript APIs, and Mermaid is a text-based DSL. Bundle size is given as under 14KB gzipped for Jantt, roughly 200KB for DHTMLX Gantt, about 35KB for Frappe Gantt and about 800KB for Mermaid.

Two rows are worth taking seriously. Critical path analysis is listed as built into Jantt, as a commercial tier for DHTMLX Gantt and unsupported in the other two. Milestones and baselines are listed as native in the Jantt schema, and commercial tier for DHTMLX Gantt. Those are the capabilities that decide whether a project management tool can sit on a programme schedule rather than a personal checklist.

The same table shows where Jantt is behind. Interactive drag-to-link is listed as a 90 degree orthogonal step for Jantt against supported for DHTMLX, and inline progress dragging is an interactive handle for Jantt against read-only for Frappe Gantt. The README's own framing is a Swiss modernism aesthetic with 90 degree routing and a Swiss Noir dark mode, so the routing style is a deliberate choice rather than a limitation of the layout code.

Operations research features: DAG solver, critical path, EVM and DCMA-14

Beyond rendering, the engine carries what the README calls defense-grade operations research tooling. There is a topological DAG solver, so dependencies between tasks can be ordered rather than trusted as written, and a Critical Path Method implementation on top of it. Earned Value Management is supported, referenced against ANSI/EIA-748, and the DCMA-14 schedule health audit is available for checking a plan against the standard used in government and defence programme management.

The zoom range is five scales from day to year, and the JSON schema has native support for milestones and baselines. The README also mentions multi-user CRDT cloud rooms with role-based permissions, and the repository backs that with a firebase.json and a database.rules.json at the root, which is where the permissions rules for a hosted collaboration room would live.

The caveat is the same one that applies to the rest of the AI-native story. The repository documents the capabilities, and the examples directory shows what a finished document looks like, but the README does not publish the algorithm details, so an engineer evaluating the critical path implementation for a real programme schedule would be reading the source under the MIT licence rather than trusting a table.

Installing the React package and running the monorepo

The quickstart begins with a workspace install of the React binding and the core engine:

npm install @jantt/react @jantt/core

The React package is used through a Jantt component, and the README also documents a standalone build usable from a plain script tag and a Node CLI for bidirectional synchronisation between a chart and JSON on disk.

For working on the project itself, the root package.json defines the workspaces as packages/*, cli and apps/*, and the scripts are the usual monorepo set. Two of them are worth knowing because the Docker build runs them:

npm run dev --workspace=@jantt/playground
npm run build --workspaces --if-present
npm test

The typecheck script runs tsc --noEmit across packages/core, packages/react and apps/playground, which tells you the three TypeScript projects the maintainers consider the core of the product. The root manifest also declares an engines field of node >=20.0.0, which is stricter than the Node >=18.0.0 shown in the README badge; if you are pinning a runtime for CI, follow package.json rather than the badge.

Docker images, the playground port and the feature flags

The repository ships a multi-stage Dockerfile. The builder stage runs on node:20-alpine, copies the workspace manifests, runs npm ci, copies the source, runs npm test and then npm run build. The runner stage is nginx:alpine, and it copies the compiled playground output into the nginx web root, exposes port 80 and defines a healthcheck that spiders the local URL with wget.

The compose file builds the same playground image from the root Dockerfile and maps a host port to container port 80:

services:
  playground:
    build:
      context: .
      dockerfile: Dockerfile
    image: jantt-playground:latest
    container_name: jantt-playground
    restart: unless-stopped
    ports:
      - "${VITE_PLAYGROUND_PORT:-5173}:80"

Port settings and feature switches live in the .env.example template, which lists VITE_PLAYGROUND_PORT=5173, JANTT_CLI_PORT=4173, HOST bound to localhost by default, NODE_ENV, and two flags: VITE_ENABLE_ANALYTICS defaults to false, while VITE_ENABLE_AI_PROMPTING defaults to true. That last default is worth a look if you intend to run the playground on a shared machine, since it enables the built-in AI prompting path by default while analytics stays opt-in.

Examples that include broken documents on purpose

The examples directory is the most unusual part of the repository layout, because three of its files are broken on purpose: broken-bad-date.json, broken-dangling-dependency.json and broken-missing-id.json. Alongside them sit basic.json, academic-roadmap.json, cheatsheet-default.json, construction-enterprise.json and master-template.json.

Having a broken-date case, a dangling-dependency case and a missing-id case in the shipped examples tells you the validation path is a first-class feature, not an afterthought. It also gives a new user a way to see what the schema rejects: those three files are the negative test set a team can copy when wiring the validator into its own pipeline.

The rest of the tree supports that reading. There is a schema/ directory, a cli/ workspace, a worker/ directory, an apps/ directory holding the playground, docs/ with a JSON cheatsheet, an architecture document, a schema specification and an API reference, plus ROADMAP.md, CHANGELOG.md, SECURITY.md, SUPPORT.md and CONTRIBUTING.md. The badge in the README reports 339 of 339 tests passing.

Limits: no tagged release and a monorepo root that is private

Two gaps are worth stating plainly. The repository has no GitHub releases, so npm is where a version actually comes from, and the root package.json is marked private with version 1.0.0, which describes the monorepo rather than the published packages. Anyone pinning this in production needs to pin @jantt/core and the adapter separately rather than trusting the root version.

The second gap is scope. The README documents React, a standalone script tag and a Node CLI, and the comparison table positions Jantt against charting libraries rather than against project management platforms. There is no account system, no server component and no collaboration backend in the core package: the CRDT rooms the README mentions depend on the Firebase configuration sitting in the repository, which is a deployment decision the reader has to make rather than a default.

Set against that, the licence is MIT, the last push to the repository was on 2026-10-16, and the source is complete enough to read.

Editorial conclusion

Jantt suits a team that wants timeline state to live in a JSON document it can diff, validate and generate, and that needs the critical path solver and schedule health audit in the same package as the renderer. It is a poor fit for a project that wants a stable published version today, since the repository has no GitHub releases, and a poor fit for anyone who needs React and Vue adapters, since the README covers React, a script tag and a Node CLI only. Verify first that the JSON schema matches the timeline you already keep, that your Node version satisfies the engines field of package.json, and that the three deliberately broken example files fail validation the way you expect.

Frequently asked questions

Official sources

1. AhmadHassan-BTed/Jantt on GitHub
2. Issues
3. License: MIT
4. Project website
5. README