Skip to main content
Solar is a runtime-based JavaScript UI framework built around one constraint most frameworks ignore: a significant portion of the code targeting it won’t be written by a human. Instead of relying on developer conventions and implicit patterns, Solar makes component contracts explicit, validation errors machine-readable, and project structure rigid — so that AI-generated output is predictably correct, not just probably correct.

​
Why Solar

React, Vue, and Svelte were all designed with a human developer at the center. They assume someone writes, reads, and maintains every file. They rely on conventions — naming patterns, file layout, mental models built up over months — that a developer carries in their head but a language model can only partially reconstruct from context. AI-generated code has different properties. It is often correct in isolation but inconsistent across files. It doesn’t respect conventions it can’t see. It gets regenerated wholesale rather than incrementally maintained. When something goes wrong, the error is usually a JavaScript runtime exception or a silent rendering failure — neither of which gives a model enough signal to self-correct. Solar addresses each of these problems directly:
  • Explicit contracts mean a model doesn’t need to infer prop types from usage. The schema is the ground truth, and it’s available at runtime.
  • Structured errors mean a contract violation produces a JSON object — component, prop, expected, received, fix — that a model can parse and act on without regex or string matching.
  • A component registry means a model can read a full catalog of available components before generating any composition code, instead of guessing what exists.
  • Rigid structure means one component per file, filename matches component name, default export is always the defineComponent call. Rules a model can follow without inference.

​
Core principles

Solar’s design is grounded in seven principles. Each one directly addresses a failure mode in AI-generated UI code.
Explicit contracts over conventions — Props are typed and validated at the component boundary, not inferred from usage. A component’s schema is its public interface, visible to both humans and models.
Component registry — Every component registers itself via registry.register(). Before generating composition code, a model calls registry.manifest() to read the full catalog of available components and their schemas.
Structured errors — Validation failures throw a ContractError with a .toJSON() method that returns a parseable object. An agent can inspect the error and self-correct without needing to parse an error message string.
Declared side effects — Effects state what they depend on and what they touch. Solar provides three explicit primitives — useResource, useSubscription, and onMount/onUnmount — instead of a general useEffect that hides its dependencies.
Typed composition — Slot props enforce which component type can fill them at runtime. Passing a raw DOM node where a Button is expected throws a ContractError immediately.
Runtime-based — Solar requires no compiler, no transpiler, and no build step. Components run directly in the browser as standard ES modules and are fully debuggable without source maps.
Small surface area — Fewer primitives means fewer ways to generate something wrong. Solar’s public API is intentionally narrow: defineComponent, createElement, mountComponent, unmountComponent, useState, useMemo, three effect hooks, registry, h, ContractError, and Types.

​
What Solar is not

Solar is a focused tool. Before adopting it, make sure it fits your needs. Not a meta-framework. Solar has no routing, no server-side rendering, no data layer, and no build pipeline. It renders components to the DOM. Everything else is outside its scope. Not a React replacement. React is a mature, general-purpose framework optimized for developer experience at scale. Solar is a narrower tool optimized for a different constraint — predictable correctness when the author is a model, not a person. The two are not in competition. Not optimized for hand-authoring at scale. Solar works perfectly well when you write components by hand, and the examples throughout this documentation do exactly that. But its design choices — rigid structure, explicit schemas, no conventions — are made to benefit AI-generated code, not to minimize boilerplate for human developers.

Installation

Set up a new Solar project in one command, or import Solar via CDN in any HTML file.

Quickstart

Build your first component with props, state, and contract validation in five minutes.