scrml is a language in active development.

A full-stack language for the browser. Multi-page apps, real-time channels, SQL-as-syntax, state machines as first-class. One file format. The compiler owns the wiring.

What works today

• v0.7.1 is the current cut (2026-06-28). It bundles roughly a month of fixes on top of v0.7.0, which closed the last of the high-severity bug board.
• v0.4.0 – v0.6.0 added generation from types — formFor(StructType) builds a form, its state cell, its validity surface and its submit path; schemaFor(StructType) builds the SQL DDL, and enum fields carry their variants across the database boundary. The same arc replaced the compiler's own front end with the native parser and expanded the built-in Tailwind surface.
• v0.3.0 shipped per-route per-role chunks, content-addressing, and auth as a compile-time visibility constraint (not a runtime check).
• v0.2.x laid the foundational reactive surface: V5-strict state, validators, the auto-synthesized validity surface, and the pattern-matching ladder.
• Engines are the UI centerpiece. Markup is a first-class value type (a stated pillar of the spec, not a library trick). The server boundary disappears.
• The reference in these docs is fully written — 73 of 73 pages across elements, keywords, contexts and error codes, with no stubs.

What's pending

• Self-host — the compiler written in scrml. This is in flight, not hypothetical: two implementations live in the tree, and the second one's lexer is token-complete and verified token-for-token against the first. It is a long way from a compiler, and it is no longer a someday.
• The v0.8 milestone target is open. The native-parser peg it used to carry is retired; the server-render-time and dynamic-deployment work is the current candidate.
• Depth, not coverage, in these docs. Every reference page is written; not every one of them is yet written to the depth MDN sets as the bar.

Adoption framing — honest

scrml has near-zero adoption right now. That's a known state, not a problem we're papering over. LLMs have broken the historical friction-tipping dynamic in language adoption: developers who would have switched stacks in 2018 due to framework friction now use the same stacks with LLM assistance and tolerate the rough edges. The motivation to adopt a new language has waned.

scrml's bet is that it makes LLMs more efficient too — the same compiler-owned wiring that the developer doesn't have to think about is wiring the LLM doesn't have to think about. But until the language is serious and complete enough to be un-ignorable, adoption is not the expected outcome of this decade's pattern. We're building anyway.

If that framing resonates — build something with it. If it doesn't — the existing stacks are fine and we don't begrudge anyone who stays put.