Uniweb is an open-source React framework and a connected visual authoring platform.

Developers build real React components, schemas, and content structures in a normal codebase. Those definitions become the vocabulary authors use to create pages, manage content, and work with structured data.

Developers define the vocabulary. Authors compose with it. Uniweb keeps both sides in sync.

Traditional

developer builds → hands off → CMS users edit

Uniweb

developer project ⇄ Uniweb ⇄ author workspace
       ↑                         ↑
       └──── both keep working ──┘

Start with a normal project. Connect the authoring environment when you want it.

# Create a project
npx uniweb create

# Sign in when you want visual authoring
pnpm uniweb login

# Sync the project with the author workspace
pnpm uniweb sync

A component can have two interfaces.

For a developer:

<Hero />
<FeatureGrid />
<PublicationList />
<Team />

For an author, those same components become meaningful building blocks:

The author doesn't manipulate JSX, HTML, or arbitrary layout primitives. The developer doesn't build a separate editing UI for every section of the site.

You build the components. Uniweb builds the authoring experience.

Developers and authors can keep working at the same time, in the tools each side prefers.

Authors never need to think about synchronization. They work in the visual app, where changes appear live. Developers keep their editor, terminal, Git history, and deployment workflow.

flowchart LR
    D["Git project<br/>React · schemas"]
    C["Uniweb CLI"]
    A["Uniweb App<br/>visual authoring · CMS"]
    S["Hosted dynamic site"]
    H["Any static web host"]

    D <--> C
    C <-->|"push · pull · sync"| A
    C -->|"publish"| S
    A -->|"publish"| S
    C -->|"deploy"| H

The CLI is the bridge between the two workflows.

Connecting the Uniweb App doesn't mean moving the project into the app.

The framework can be used on its own. When a team needs visual authoring, the CLI connects the same project to the app instead of replacing the developer workflow with a proprietary builder.

The codebase remains the developer environment. The app becomes the author environment.

The same idea extends beyond page composition.

A site may need structured content for people, publications, events, courses, products, projects, or something specific to the organization.

Developers define those structures as part of the project. Uniweb presents them to authors as interfaces for creating and managing records.

export default {
  data: {
    people: '@std/person',
    events: '@/schemas/event.json',
    products: '@/schemas/product.json'
  }
}

The developer thinks in terms of schemas, relationships, and components. The author sees fields, records, choices, and content.

No separate admin application is required just to make the data editable.

A person isn't fundamentally a block on a department homepage. A publication doesn't belong to whichever website entered it first. Neither does an event, course, project, product, or organization.

Those are entities.

Uniweb can model structured content independently from the pages and components that present it, so the same content can appear in different contexts and across different sites.

Content can belong to the organization. Websites become views over it.

That matters most when many sites need to share the same people, publications, projects, events, courses, or other organizational knowledge without copying it into separate CMS silos.

Once content is independent from presentation, the rendered website is only one possible output.

content
  ├── rendered site
  ├── llms.txt
  ├── route-level Markdown
  ├── search index
  └── localized variants

These outputs can be derived from the same underlying content rather than scraped back out of rendered HTML or maintained separately.

Redesign the site and the content remains the same. Add a language and the derived outputs can follow it. The website, search index, and agent-readable representations stay aligned because they derive from the same source.

Store the content once. Project it into the forms different consumers need.

A real website rarely wants an agent inventing arbitrary HTML and CSS every time it makes a change.

It already has components, schemas, design rules, content structures, languages, and conventions.

A Uniweb project gives agents that existing system to work within. An agent can operate in the same file-based environment as a developer: create or modify components, define schemas, work with structured content, and use the CLI.

Once synchronized, those new capabilities become available to authors in the visual app.

What should the substrate for AI-created websites be?

A constrained, semantic component system is one answer worth exploring.

These ideas are part of an architectural model we call Component Content Architecture (CCA).

CCA keeps content, components, and composition distinct while making their relationships explicit. That separation is what allows the same content and component system to support code-based development, visual authoring, structured data, multiple sites, derived outputs, and agent workflows without creating separate versions of the website.

The point isn't another CMS abstraction. It is a cleaner boundary between content, presentation, and the interfaces through which people and software work with them.

The uniweb/cli repository is the developer entry point.

The full framework spans 20+ focused repositories covering runtime, builds, content architecture, schemas, presentation, developer tooling, and other parts of the ecosystem.

Website · Uniweb App · Discord · X / Twitter

Uniweb is open source under the Apache 2.0 license.

_{Uniweb is a trademark of Proximify Inc.}