New Project Idea: gora

[ata-sesli]

Gora

I’m considering building Gora.

The idea is to create a persistent, declarative UI document format and local native preview studio designed around an agent’s iterative design workflow.

Instead of asking an agent to scaffold a complete web, mobile, or desktop application for every interface idea, Gora would let the agent create and modify a .gora document, render it immediately, inspect the result, and apply precise corrections.

The core workflow would be:

Prompt
  ↓
.gora document
  ↓
Render
  ↓
Inspect
  ↓
Targeted patch
  ↓
Improved preview

The main product goal would be:

Can an agent create a convincing interface preview, inspect what is visually wrong, make a small targeted correction, and converge faster than it could by generating and editing a conventional application project?

Gora would initially be implemented in Go using Gio for native layout, rendering, input, and window management.

The .gora format itself would remain independent from Gio-specific concepts. Gio would be the first runtime backend rather than part of the document specification.

A Gora document could describe:

• layout structure
• text, images, surfaces, and spacing
• reusable components
• responsive behavior
• local preview state
• screen navigation
• overlays
• editable text
• simple declarative interactions

The format would likely use a strict subset of YAML as its human-readable persistence representation.

For example:

gora: 1

kind: app
name: Settings Preview

viewport:
  width: 390
  height: 844

root:
  id: settings-root
  type: stack
  direction: vertical
  padding: 24
  gap: 16

  children:
    - id: settings-title
      type: text
      content: Settings

    - id: dark-mode-toggle
      type: instance
      use: std/toggle
      properties:
        label: Dark mode
        value: true

YAML would not be the primary mutation interface for agents.

The runtime would parse documents into a canonical node model, and the MCP would let agents manipulate that model through stable IDs.

Possible MCP operations could include:

• creating and opening documents
• inserting, moving, patching, and removing nodes
• creating and importing components
• validating documents
• inspecting the component tree
• inspecting resolved layout bounds
• identifying the rendered node at a coordinate
• changing viewport dimensions
• rendering screenshots
• simulating preview interactions

Applications and components would use the same .gora document model.

For example:

app.gora
button.gora
dialog.gora
navigation-bar.gora

A component would be independently previewable and could be imported into other Gora documents.

This would allow agents to create reusable component libraries entirely in Gora, similar in spirit to shadcn/ui.

The runtime would expose a small set of intrinsic visual primitives, such as:

• stack
• grid
• overlay
• scroll
• spacer
• surface
• text
• image
• divider

It would also provide interaction capabilities that cannot be reproduced reliably through visual composition alone, such as:

• pointer hit regions
• focus handling
• keyboard input
• editable text
• scrolling and clipping
• hit testing

Recognizable controls such as buttons, toggles, tabs, cards, dialogs, sidebars, and navigation bars would mostly be implemented as reusable .gora components rather than hard-coded runtime widgets.

This would keep the runtime small while still allowing agents to create visually original components without writing Go code.

Gora would support finite declarative preview state rather than general computation.

For example:

state:
  sidebar_open: false
  selected_tab: overview

Supported actions could include:

• set
• toggle
• select
• navigate

Conditions would remain deliberately limited, such as checking whether a state value equals a specific value.

Gora would not initially support:

• arbitrary expressions
• loops
• callbacks
• functions
• networking
• authentication
• databases
• background tasks
• device APIs
• production application logic

The goal is to prevent .gora documents from gradually becoming code files disguised as YAML.

Gora v1 would focus on three polished benchmark interfaces:

• a responsive web dashboard
• a mobile settings flow
• a desktop inspector-style tool

These would serve as both demonstrations and a visual conformance suite.

The first version would prioritize:

• persistent .gora artifacts
• stable node IDs
• strict validation
• Gio-based native previews
• screenshot capture
• component previews
• responsive layout
• local preview interactions
• tree inspection
• resolved layout inspection
• point inspection
• targeted MCP patches

Features such as multiple renderers, HTML translation, production application packaging, generalized animation, vector illustration tools, plugin systems, and broader application-runtime capabilities would be deferred until the preview and correction loop is proven useful.

The long-term direction could eventually include language-agnostic runtime implementations.

The .gora document specification could theoretically be implemented by:

• Go and Gio
• Rust and a native renderer
• TypeScript and a web renderer
• Swift
• Kotlin

However, Go and Gio would remain the initial reference implementation, and Gora v1 would not be designed around hypothetical future runtimes.

The project’s central idea is not merely “YAML translated into Gio.”

It is:

A persistent, editable, visually expressive UI artifact and local native studio optimized for an agent’s iterative design loop.

I’d like to hear thoughts about:

• the boundary between runtime primitives and document-defined components
• the smallest useful declarative interaction model
• the design of stable component and instance IDs
• useful MCP inspection tools
• the initial YAML schema
• Gio layout and rendering architecture
• component library design
• the three benchmark interfaces
• where the boundary should remain between preview behavior and production application logic

All contributions are welcome.