Modern frontends are fast.
CMS are powerful.
But they don’t speak the same language.
Astro components speak in props. CMS speak in data models.
The real problem is not content management.
The real problem is where content modeling happens.
The classic workflow destroys frontend quality
Most CMS workflows force developers to rebuild structure inside a backoffice:
- layouts get reimplemented as “templates”
- components become “blocks”
- designers hand off, and quality drops
- editors can accidentally break structure
You end up maintaining two systems that drift apart.
Astro exposes a better contract
In Astro, a component already defines an implicit contract:
- exported props define what is configurable
- pages define routes and composition
- datasets exist as structured inputs
The structure is already there — in code.
Build-time is the only place this can be clean
Runtime integrations are expensive:
- extra dependencies
- runtime performance costs
- more failure modes
- lock-in to a specific CMS API
A better approach is build-time only:
- scan the project
- extract the structure
- output a stable data contract (JSON)
A build-time translation step
The problem is not rendering.
The problem is where translation happens.
Frontmatter introduces a build-time translation step between your frontend code and any CMS.
What the IR actually looks like
The output of this build-time step is not content.
It’s structure, expressed as data.
Pages become routes with typed fields.
Datasets become explicit collections.
This is the kind of output Frontmatter produces:
This JSON is a contract.
It can be consumed by:
- a flat-file CMS
- a headless CMS
- a custom backend
- or just checked into git
Once structure becomes data, CMS become interchangeable.
What this is not
This approach is not for everyone.
It is not:
- a CMS
- a site builder
- a visual editor
- a runtime framework
- a solution for highly dynamic, user-generated content
It assumes:
- a code-first workflow
- a static or build-time oriented frontend
- a clear separation between structure and content
If your CMS needs to control layout, this is the wrong tool.
A data contract makes CMS interchangeable
Once structure becomes data, the CMS becomes a tool to edit content — not a place to rebuild your design.
Developers keep layout in code.
Editors touch structured content.
Modern frontends don’t need “better CMS features”.
They need a clearer contract.