DEV Community: Bryan MacLee

The server boundary disappears

Bryan MacLee — Tue, 28 Apr 2026 16:50:19 +0000

authored by claude, rubber stamped by Bryan MacLee

TL;DR: Stop writing API routes. The compiler does it.

Every framework dev has shipped a bug where they thought a function ran on the server but it didn't, or thought it ran on the client but it didn't. I am not an experienced framework developer. I can hobble through React if I HAVE TO. But across about twenty compiler attempts the same shape kept showing up: the compiler should know which side of the wire each function is on, because the wire is part of the program.

I'm obsessed with performance. I'm also a believer in "do it right, the first time, even if it takes more time." The server boundary is a place where most languages do neither, and the runtime pays for both. So this is the second of six features the browser-language overview piece promised to unpack later. The boundary, in detail.

What "shipping a typed POST endpoint" actually costs

Pick a framework. Next, Remix, Express plus a React frontend, doesn't matter. The minimum table-stakes for a single server endpoint that takes some data, validates it, persists it, and returns a typed response looks like this:

On the server:

// app/api/orders/route.ts
import { z } from "zod";
import { auth } from "@/lib/auth";
import { db } from "@/lib/db";

const SubmitOrderInput = z.object({
  items: z.array(z.object({
    productId: z.string().uuid(),
    qty: z.number().int().min(1).max(99),
  })),
});

const SubmitOrderOutput = z.object({
  orderId: z.string().uuid(),
  total: z.number(),
});
type SubmitOrderOutput = z.infer<typeof SubmitOrderOutput>;

export async function POST(req: Request) {
  const session = await auth(req);
  if (!session) return new Response("Unauthorized", { status: 401 });

  let body: unknown;
  try { body = await req.json(); }
  catch { return new Response("Bad JSON", { status: 400 }); }

  const parsed = SubmitOrderInput.safeParse(body);
  if (!parsed.success) {
    return new Response(JSON.stringify(parsed.error), { status: 400 });
  }

  // ... actual business logic finally starts here ...
  const order = await db.orders.insert(...);
  return Response.json({ orderId: order.id, total: order.total });
}

On the client:

// app/cart/page.tsx
type SubmitOrderInput = { items: { productId: string; qty: number }[] };
type SubmitOrderOutput = { orderId: string; total: number };

async function submitOrder(input: SubmitOrderInput): Promise<SubmitOrderOutput> {
  const res = await fetch("/api/orders", {
    method: "POST",
    headers: { "content-type": "application/json", "x-csrf-token": getToken() },
    body: JSON.stringify(input),
  });
  if (!res.ok) throw new Error(await res.text());
  return res.json() as Promise<SubmitOrderOutput>;
}

That's the minimum. No retry. No timeout. No proper error type. No loading state. The shapes are typed twice, once with zod and once with hand-written TS. The CSRF token plumbing is manual. If you change the input shape on the server and forget to update the client TS type, nothing fails until production traffic hits it.

This is the seam. It is the most expensive seam in the application. It is also the seam that no framework can close, because the framework doesn't own both sides of it.

The same feature in scrml

< db src="./app.db" tables="orders,order_items">

server fn submitOrder(items: List<Item>(@length > 0 && @length < 100)) -> OrderResult {
    let total = items.sum(it => it.price * it.qty)
    let orderId = ?{`INSERT INTO orders (total) VALUES (${total}) RETURNING id`}.get().id
    items.forEach(it => {
        ?{`INSERT INTO order_items (order_id, product_id, qty) VALUES (${orderId}, ${it.productId}, ${it.qty})`}.run()
    })
    return OrderResult { orderId: orderId, total: total }
}
</>

And the call site, anywhere in the same file or another .scrml file in the project:

let result = submitOrder(@cart.items)

That's the entire feature. Both halves.

What the compiler did with server fn:

Generated a server-side route handler. Route name is compiler-internal; you don't reference it.
Generated the client-side fetch call that invokes the route, with arg serialization, response deserialization, and await insertion. The developer SHALL NOT write JSON.stringify, JSON.parse, or fetch to consume server function return values (§12.5).
Type-checked the call site. submitOrder(@cart.items) checks the argument shape against the server fn signature in the same compile pass. There is no client-side type SubmitOrderInput declaration to drift.
Emitted the function body to the server output only. The client gets a fetch stub.
Enforced the predicate at the server boundary. (@length > 0 && @length < 100) is checked at function entry, on the server, before any database write. The check runs even if the client already validated (§53.9.4).

What the compiler refuses

Six refusals, every one of them a real diagnostic with an E-code you can look up.

1. Reading a server-only field on the client. (E-PROTECT-001)
If < db> declares protect="passwordHash", then passwordHash does not exist on the client type. A client-side function trying to read it is a compile error, not a runtime exposure.

2. Code that accesses a protected field but might run client-side. (E-PROTECT-002)
The compiler verifies at compile time that no function accessing protected fields executes on the client. Any code path that could route to the client and touches a protected field fails compile.

3. A server fn calling a client-only fn. (E-ROUTE-002)
If a server fn transitively calls a function that touches the DOM or reads a client-only derived value, compile fails with the call chain printed. The error message names the server function, the client-only callee, and the path between them, then suggests three resolutions: extract a pure function, duplicate the logic, or re-evaluate the classification.

4. A non-serializable return type from a server fn. (E-ROUTE-003)
Try to return a function, a DOM node, or a class instance from server fn and the compile fails. The wire is JSON; the type system enforces it.

5. A client-local @var used as a bound parameter in INSERT, UPDATE, or DELETE outside a server fn. (E-AUTH-001)
The compiler refuses to silently persist client-local state. The error message tells the developer to pass the value to a server function first.

6. A predicate violation at the boundary. (E-CONTRACT-001 at compile time, E-CONTRACT-001-RT at the boundary.)
If the compiler can prove a literal violates a predicate, the build fails. If the value is only known at runtime, a server-side boundary check fires before any business logic runs and rejects the request.

That's six refusals. Every one of them is a type-system answer to a question that, in framework land, is "hope your tests catch it."

What gets generated for free

Beyond refusing the wrong things, the compiler also generates the things you would have written by hand:

The fetch stub. Argument serialization, response deserialization, automatic await. No JSON.stringify. No JSON.parse. No manual await.
The route handler. With its name as a compiler-internal detail you never see.
CSRF plumbing, when <program csrf="on"> is set. A token-mint server fn, a <meta name="csrf-token"> injection in the generated HTML, a request interceptor that adds the X-CSRF-Token header to every state-mutating request, and a server-side validator that returns 403 if the token is missing or invalid (§39.2.3).
Predicate validation at the boundary. Inline predicate constraints on server function parameters are enforced server-side, before any database write or business logic, independently of any client-side check. A server function's parameter constraint cannot be bypassed by raw HTTP requests (§53.9.4).
Async parallelization. Independent server calls in the same function body are parallelized in generated code; dependent ones are sequenced. The developer writes flat synchronous-looking code; the compiler emits Promise.all and await correctly (§13.2).

The compiler is the dev's best friend. That phrase comes up a lot in my notes. This is what it means in practice. Every line of the framework boilerplate above is moved into the compiler, where it cannot drift, cannot be skipped under deadline pressure, and cannot be wrong without the build failing.

What this kills

The app/api/ directory. There aren't any route files. There are functions.
Hand-written fetch wrappers. There is no apiClient.ts.
tRPC and OpenAPI codegen steps. The type goes through the boundary natively because the compiler owns both sides.
Zod-on-the-wire. Inline predicates are the type. A schema file isn't a separate artifact. Why would anyone bring zod into a scrml project?
Type-drift bugs that ship to prod. The client and server agree on the shape because there is one declaration.

What is still real

Server-side concerns don't disappear. They just stop being plumbing.

Auth. Still your job. The server annotation is described in the spec as a security escape hatch precisely because compile-time inference of "what touches protected data" is not always sufficient on its own (§11.4). Annotate auth-touching functions with server explicitly.
Rate limiting. A <program ratelimit="100/min"> attribute generates a sliding-window limiter (§39.2.4). Tune the rate to your business; the mechanism is built in.
Input validation against business rules. Predicates handle shape and range. Business rules ("this user can submit at most 3 of these per day") are still business logic. They live inside the server fn. They benefit from running where the data lives.

The line between "plumbing the framework forced you to write" and "actual business logic" gets a lot brighter when one side of it is gone.

The deeper claim

A reactive system that wires its dependencies at compile time does no work at runtime to figure out what to update. A query that batches itself at compile time doesn't need a DataLoader. A boundary that is enforced at compile time doesn't need a validator on the wire.

The runtime does less because the compiler did more. The seam between client and server stops being a place where bugs live and starts being a place where the type system has the most leverage. That is the design. A little short of perfect is still pretty awesome.

What npm package do you actually need in scrml?

Bryan MacLee — Tue, 28 Apr 2026 16:48:02 +0000

authored by claude, rubber stamped by Bryan MacLee

TL;DR: The npm package list you'd actually need in scrml is short. The critique is mostly cargo-culted muscle memory.

I am a truck driver by trade. I program because I love solving puzzles. So I have always been much more the "roll your own" type. I mean, why should I let someone else have all the fun.

Every time I ever had to actually involve Node into anything I was working on, I cringed, and would try desperately not to have to fall down that rabbit hole. Because, axiomatically, the only way out is through.

But no matter how much I dreaded typing "node", what truly got my blood boiling was what I always have, and always will, consider the world's most cancerous leaky abstraction. NPM.

What npm package do you actually need in scrml?

The obvious "weakness" someone could point at is that scrml doesn't have an easy npm-install path yet. That isn't a weakness. That's the whole point. I built scrml in part because I was sick of pulling in 200 packages to do what one well-designed language should do natively.

Now to be fair, there is a real version of this critique, and I'm going to address it head-on. A scrml vendor add <url> CLI is on the roadmap. Until it ships, ingestion of arbitrary client-side bundles is rougher than it should be. Fine. I'll concede that.

But the invalid version of the critique would be the implication that there's some long, essential list of npm packages a scrml app would want and can't have. So let's actually enumerate them. Because when you do, the list is comically short.

Here's the punchline up front: the npm-interop critique is mostly cargo-culted muscle memory from the React/Node era. Modern Bun + scrml's stdlib + scrml's language features collapse the whole package list down to about five categories, and only one of those (heavyweight client-side widgets like CodeMirror, three.js, and Leaflet) is a real story problem worth solving with vendor ingestion. The rest is a rounding error.

What npm typically supplies, and where each goes in a scrml app

Replaced by the language itself

These categories account for most of a typical Node project's package.json. None of them have a place in a scrml app, because scrml is this layer.

Framework + state + routing + forms. React, Vue, Svelte, Redux, Zustand, Pinia, react-router, vue-router, Formik, react-hook-form. scrml's reactive primitives (@var, derived, effects), components, file-based routing, and bindings replace the entire stack.
ORM / query builder. Prisma, Drizzle, Kysely, TypeORM, Sequelize. scrml's ?{} SQL block writes parameterized queries directly against Bun.SQL, with compile-time schema introspection (§39) and protected-field enforcement (§11), and ?{} itself is specified at §44.
CSS-in-JS / scoping. styled-components, emotion, vanilla-extract. scrml's #{} scoped CSS uses native @scope (§9.1, §25.6).
HTTP client. axios, got, ky. Server fns can call fetch directly. Markup-side fetches use <request> and lift.
Build / bundle / dev server. Vite, Webpack, esbuild, Parcel. scrml dev, scrml build, scrml serve. Done.
Test runner. vitest, jest, mocha. bun test, plus the scrml:test stdlib for assertions.
WebSocket plumbing. socket.io, ws. scrml's <channel> (§38).
Auth / CSRF middleware. passport, csurf, express-session. Boundary security is enforced by the compiler. CSRF mint-on-403 is built in.
Validation (the zod case). zod, yup, joi, ajv, superstruct. I have two answers here, and both of them are stronger than zod:
1. §53 inline type predicates are compile-time-enforced refinement types: let x: number(>0 && <10000), fn process(amount: number(>0 && <10000)), type Invoice:struct = { amount: number(>0 && <10000) }. Named shapes like email, url, uuid, phone are first-class (and so are date, time, color). Violations are compile errors (E-CONTRACT-001), not runtime exceptions you find out about when production blows up. Zod can't fail your build. This can. 
2. scrml:data/validate stdlib for runtime form validation when the data shape is genuinely unknown until runtime: validate(data, schema) returns { field: errors[] }, with rule builders for required, email, minLength, maxLength, pattern, min/max, numeric, integer, matches, oneOf, url, plus domain composites (emailField, passwordField, passwordConfirmField).

If you've ever installed all of the above into a single React app, you've installed roughly 60-80% of the average package.json line count. None of it belongs in a scrml app. Ever.

Replaced by Bun

Bun is the runtime, and Bun's stdlib has steadily absorbed the rest of the lower-level Node ecosystem. Every one of these used to be an npm package. Now they're built in:

bcrypt becomes Bun.password
jsonwebtoken / jose become web crypto + Bun.password
pg, mysql2, better-sqlite3 become Bun.SQL
ioredis, redis become Bun.redis
sharp (some cases) becomes Bun.spawn to imagemagick, or vendor when you really need to
nodemailer becomes Bun.spawn to system MTA, or REST-call a transactional email API
dotenv is built into Bun
fs-extra is just Bun's fs ergonomics

This is what I mean when I say "roll your own": Bun's authors did. Now nobody has to npm-install bcrypt and pray the maintainer doesn't get bored.

Already in scrml's stdlib

The 13-module stdlib already covers most of the "I'd npm install a small utility" reflex. I built it intentionally small but not so small that you have to leave the language for the basics:

stdlib module	replaces
`data/validate` (+ §53)	zod, yup, joi
`data/transform`	lodash (`pick`, `omit`, `groupBy`, `sortBy`, `unique`, `flatten`, ...)
`auth`	bcrypt, jsonwebtoken, speakeasy (TOTP), express-rate-limit
`crypto`	crypto-js, bcryptjs, hashing helpers
`http`	axios, got, node-fetch (typed wrapper with timeout + retry)
`time`	date-fns / dayjs (basic format), lodash.debounce/throttle
`format`	slugify, change-case, pluralize, currency/number formatting
`store`	KV store, session store, counter (replaces `connect-sqlite3` and basic redis use)
`router`	path-to-regexp, qs
`test`	chai, parts of jest/expect
`fs`, `path`, `process`	Node compat layer

The stdlib isn't trying to be everything. It covers the high-frequency reaches. Specialty libraries get vendored. That's the deal.

Trivially vendored or rewritten

Things that are honestly small enough to copy straight into your project:

uuid, nanoid. One-liners against crypto.randomUUID() or web crypto. Why are these npm packages?
More date math beyond the stdlib. Vendor a single function from date-fns. Don't drag in the whole library.
Markdown rendering for short content. marked is small and CDN-vendorable.
Most of the @types/* ecosystem. Irrelevant. scrml has its own type system.

If your "I need this from npm" instinct fires for one of these, the cost-benefit of vendoring a 40-line helper vs. wiring up a package manager flow isn't even close. Just write the function. Have the fun.

Service SDKs are mostly thin REST wrappers

This is the category most often invoked as a counterexample, and it's the one that drives me up a wall, because it's mostly a misconception:

Stripe, OpenAI, Anthropic, Resend, SendGrid, Twilio, Slack, GitHub. These are REST APIs. Their official SDKs are typed wrappers around fetch. Calling the REST endpoint directly from a server fn is a 10-line fetch call. Yes, the SDK convenience is real (typed responses, retry logic, pagination helpers). No, it isn't load-bearing.
AWS SDK. Somewhat heavier (SigV4 request signing), but you can either vendor the v3 modular packages or write a small SigV4 helper. People sign requests in 30 lines of bash. You can do it in scrml.

A scrml convention of "here's the canonical pattern for hitting Stripe / OpenAI / AWS from a server fn" docs page closes most of this gap. The capability already exists. The recipe doesn't, yet. That's a docs problem, not a language problem.

Where npm interop actually bites

Here's the honest list. The places where I'll grant you the criticism has teeth. These are heavyweight client-side libraries that you cannot reasonably re-implement, no matter how much I love rolling my own:

Code editors. CodeMirror 6, Monaco, ProseMirror, TipTap, Lexical. 100k+ LOC each. (6nz already vendors CM6 via dynamic import + a __cmMod global bridge. It's a working pattern.)
3D. three.js, babylon.js
Maps. Leaflet, mapbox-gl, MapLibre
Charts beyond stdlib. Chart.js, ECharts, D3, Plotly, Highcharts (scrml has chart-utils.js for the lighter end)
PDF generation. pdf-lib, jspdf
Animation beyond CSS. Framer Motion, GSAP, anime.js
Real-time collab CRDTs. Yjs, Automerge
Rich graph viz. dagre, vis-network, cytoscape

Every one of these is the same pattern: a heavyweight bundle that needs to load on the client, get a JS handle, and be called from app code. One mechanism solves the whole class: scrml vendor add <url> ingests a UMD or ES bundle from a CDN, generates a type shim, and wires it into the boundary security model. The 6nz CM6 integration is a working proof-of-concept already.

That's the entire honest list. About ten categories of widget. Not "an open-ended ecosystem of two million packages."

So what's the strategic gap?

The critique stops landing once I ship three things:

scrml vendor add <url> CLI. Flat-file ingestion of a CDN bundle, type-shim generation, manifest tracking. On the roadmap and on me to land.
A type-shim story for vendored bundles. The moment an adopter does vendor add chart.js, they hit "untyped global." A canonical pattern (declare-only .d.scrml or equivalent) closes this. I'm building it.
A "calling external REST SDKs" recipes doc. Five examples (Stripe, OpenAI, AWS S3, Resend, Slack webhook) showing the fetch-from-server-fn pattern with auth headers and typed responses. Docs work. I'll write it.

Once those three are in, the npm critique loses about 90% of its bite. The remaining 10% is the heavy widget category, and the answer there is "vendor the bundle. We will never npm-install three.js, and that's fine."

The deeper point

The npm ecosystem is enormous because the JavaScript language and the browser platform are minimal. Most of those packages exist to paper over missing primitives. A state library to give you reactivity, a router to give you routing, a CSS-in-JS library to give you scoped styles, an ORM to give you queries, a validation library to give you types at the boundary. When the language and runtime supply those primitives natively, the package list collapses.

That's the bet I'm making with scrml. A first-principles, full-stack language with a real type system, a real reactive model, real boundary security, real query syntax, and a small focused stdlib is a smaller surface to learn and a smaller surface to maintain than a Node project that wires together 200 packages to recreate the same capabilities. The npm-interop critique reads as a weakness only if you assume the package list is a fixed cost. It isn't. It's the symptom.

The one package you actually need is vendor add chart.js. I'm shipping it. Once it lands, the conversation is over.

And me? I'll be back in the cab, thinking about the next puzzle.

What scrml's LSP can do that no other LSP can, and why giti follows from the same principle

Bryan MacLee — Tue, 28 Apr 2026 16:45:52 +0000

authored by claude, rubber stamped by Bryan MacLee

TL;DR: mainstream LSPs are unions of partial language services. scrml's LSP is a single service that knows every context. giti is the same idea applied to version control.

The LSP and giti both sit downstream of one integrated compiler that owns markup, logic, SQL, components, and reactivity in one AST. That single fact is what this piece is about, because it is what lets both of them ship features that piecewise alternatives in mainstream stacks literally cannot.

That structural difference unlocks features the union model literally cannot ship. Giti is a parallel structural argument: a version control surface designed for the median developer, with the scrml compiler as its review gate. The same "single integrated thing knows everything" pattern is what makes it possible.

Part 1: The LSP

Why mainstream LSPs hit a ceiling

Take Vue. A .vue file has three contexts: <template> (HTML), <style> (CSS), <script> (TypeScript). Volar (Vue's LSP) solves this with a thin LSP shell that delegates each region to a dedicated language service: HTML service, CSS service, TS service. To get TS-level features inside the template, Volar transforms the SFC to virtual TypeScript (svelte2tsx-style) and asks tsserver. It works, and it's a real engineering achievement. But the union approach has a hard ceiling: each per-context service knows only its own context.

The thing every Vue dev has hit: you can't get column completion in a SQL string inside a Vue script setup, because no Vue language service knows your SQL schema. The Volar architecture can't know. Neither the TS service nor the CSS service nor the HTML service was designed to understand a SQL DSL embedded inside a string literal. You'd have to write a new "SQL inside JS string templates" plugin, plumb it into Volar's per-context dispatch, and then teach it about your specific schema source. Nobody does this.

dbt has a SQL LSP. It does column completion against a schema. But dbt's LSP knows only SQL: your application code is invisible to it.

That's the union-of-services ceiling. Each service is good at its one context, but the interesting completions are at the boundaries between contexts.

Why scrml doesn't hit it

scrml's compiler owns every context in one AST. A .scrml file's markup, logic, components, SQL, CSS, and reactive declarations are all parsed by the same pipeline (PP, BS, TAB, MOD, CE, PA, RI, TS, META, DG, BP, CG). The PA (protect= Analyzer) pass already builds a views map keyed by < db> block, and each entry carries every table's full schema. That data is sitting in memory the moment the LSP runs analysis on a buffer.

So when you type:

< db src="./app.db" tables="users,posts">

server fn list_recent() {
    return ?{`
        SELECT u.|     -- cursor here
        FROM users u
    `}.all()
}

the LSP can:

Detect the cursor is in a SQL context.
Parse the partial SQL to find table alias u resolves to users.
Pull the column list for users from the PA result (protectAnalysis.views.get(stateBlockId).tables.get("users").fullSchema).
Return those columns as completions, each labeled with its SQL type, primary-key/index status, and protected-field status.

This is a feature zero competitor LSPs offer, because no competitor LSP owns both your application code AND your database schema in the same analysis pass. dbt's LSP knows your SQL but not your application. tsserver knows your application but not your SQL strings. Volar knows your Vue template but not your SQL strings. The union model can't get there from here.

The same structural argument extends to:

Cross-file component prop completion

// components/card.scrml
export const Card = <article props={ title: string, body: string, publishedAt: Date }>
    <h2>${title}</>
    <p>${body}</>
    <span class=date>${publishedAt}</>
</article>

// pages/index.scrml
import { Card } from "../components/card.scrml"

<Card title="Hi" |    -- cursor here

The LSP suggests body=, publishedAt=. Cross-file. Driven by a derived prop registry built from ComponentDefNode.raw parsed at workspace-bootstrap time. The L3 phase of the LSP roadmap landed this in S40. It works against export.raw synthesized component-defs, not just same-file components.

A React or Vue dev reading this is thinking "my IDE has done this for years". Yes, for components written in JSX or SFCs that tsserver / Volar can analyze. scrml's version works for components defined in markup-first source that tsserver and Volar would never touch. And it works because <Card title="Hi" and <article props={...}> are nodes in the same AST pass.

Cross-file go-to-definition that's actually accurate

This is the table-stakes feature TypeScript devs ship by default. scrml shipped it in L2 (S40) via a workspace cache that holds:

exportRegistry: Map<filePath, Map<exportName, ExportInfo>>
fileASTMap
importGraph

The cache rebuilds on didChange / didOpen. If the touched file's export shape changed, ALL open buffers re-analyze. F12 on a cross-file Card jumps to the ComponentDefNode.span in components/card.scrml. F12 on an imported function jumps to the export-decl span. Same file or other file: same code path.

This is unremarkable in mature LSPs. It is remarkable that scrml (a young language) has it working today, because the alternative was the route most young languages take: same-file go-to-def, "cross-file is a future feature", and the dev experience suffers for years. The structural reason scrml could ship it early is the same one that makes SQL completion possible: one compiler owns everything, so wiring MOD output (the export graph) into the LSP is one cache layer, not one cache layer per language service.

Code actions that quick-fix scrml-specific errors

L4 (S40) shipped codeActionProvider quick-fixes for:

E-IMPORT-004: Levenshtein-rank closest exported name from the imported module's actual exports. ("Cardd not exported from ./card.scrml. Did you mean Card?")
E-IMPORT-005: bare specifier missing ./ prefix. (Auto-prefix.)
E-LIN-001: unconsumed linear value. (Auto-prefix the binding with _ to silence.)
E-PA-007: column not in table schema. Levenshtein-ranks the closest column from PA's views. ("name not in users. Did you mean username?")
E-SQL-006: .prepare() removed in §44 Bun.SQL migration. (Strip the call.)

Notice E-PA-007. The quick-fix is "did you mean username?" pulled from the schema introspection that PA already did. This requires the LSP to have your DB schema in the same analysis pass as your error diagnosis. Other tooling stacks have to either ship a separate "schema linter" tool that doesn't know your application code, or skip the suggestion. scrml's LSP suggests it inline.

Signature help that crosses files

L4 also shipped signatureHelpProvider triggered on ( and ,. For cross-file imported functions, the LSP synthesizes the function shape from the export's raw source (parsed at workspace-bootstrap). So:

import { computeTotal } from "./billing.scrml"

const total = computeTotal(|    -- cursor here, signature popup shows:
                                --   computeTotal(items: List<Item>, taxRate: Number)
                                --                ↑ active param

works without the called function's source being open in the editor.

Hover with reactive/tilde badges and state field types

Same-file or cross-file, hover shows:

function signature plus boundary (server vs. client)
reactive variable badges (@count is reactive; ~tmp is tilde-decl)
struct field types from <state> blocks
enum variant payload shape

This isn't novel by itself. Every LSP does hover. The differentiator is what's in the hover. The "boundary" badge is impossible in TypeScript LSP, because TS doesn't have a server/client boundary concept. That's a scrml compile-time invariant the compiler enforces (SPEC §11 protected fields, §12 route inference). Showing it in hover means a dev never has to wonder "is this function safe to call from client code?". The LSP tells them on mouse-over.

Document symbols with semantic meaning

The outline panel (L1, S40) populates with: <state> blocks, components, server/client functions, machines, <db> blocks. Each gets a symbol kind (Variable / Class / Function / Module) appropriate to scrml's mental model, not JS's. A scrml dev sees their state blocks as first-class entities in the outline. A TS dev with a similar Zustand store sees a generic function. The LSP can show the structure the dev actually thinks in.

What's deliberately NOT shipped (and why)

Semantic tokens (L5): formally dropped from the active roadmap per a 6nz consultation. 6nz is the editor in the scrml ecosystem and is moving toward spatial annotation panels, where coloring is a side channel, not the primary signal carrier. TextMate handles broad-strokes coloring fine. Semantic tokens would be sunk cost.
Find-references: pending. Will use the workspace cache (already built for L2/L3).
Rename-symbol: pending. Same dependency.
Workspace-symbol search: pending. Cheap on top of the existing export registry.

The deferral pattern is informative. Every L1-L4 capability either uses a single-file AST walk or the workspace cache. Nothing scrml's LSP is shipping today is built on top of speculative architecture. Everything is downstream of pipeline stages that already exist for the compiler to do its main job.

Summary

The LSP capabilities you can ship are gated by what the compiler can tell you. mainstream LSPs ship a union of per-context services because mainstream languages are unions of per-context tools. scrml's compiler owns every context, so the LSP can ask one analysis pass for everything: markup, logic, SQL schemas, component prop registries, cross-file imports, error-fix suggestions. And surface it without per-context plumbing.

That's why SQL column completion against your live schema is a 50-line LSP feature for scrml and an open research project for everyone else.

Part 2: Why giti follows from the same principle

scrml's LSP works because one compiler owns every context. Giti works because one platform owns the entire collaboration surface, and uses the scrml compiler as its review gate.

Git's mental-model problem

The numbers (giti-spec-v1.md §1.2):

52% of all developers struggle with git at least once a month
75% of self-described "confident" git users still struggle monthly
87% have hit merge conflicts they didn't know how to resolve
65% have lost commits or changes
55% find rebase error-prone
45% have been negatively affected by a colleague's force push

The standard response to these numbers is "users need more git education". giti's design rejects this. The mental model itself is the defect. Anything that requires understanding git internals (staging vs. working tree, detached HEAD, fast-forward vs. merge commits, the interaction between local and remote refs, what git reset --soft vs. --mixed vs. --hard actually does) is a defect in giti's surface, not a user education gap.

The 5-function surface

giti save     : snapshot working state (no staging area; everything is included)
giti switch   : move to a different point in history
giti merge    : bring another line of work in
giti undo     : reverse the last operation
giti history  : show what happened

That's the entire daily-development vocabulary. There is no add. No stash (working copy IS a commit, courtesy of jj-lib's storage model). No reset family with three flavors. No detached HEAD. No rebase --interactive. No cherry-pick. No reflog to recover from a destructive operation, because no destructive operation exists at the surface.

The 5-function design wasn't pulled from the air. It was derived from actual usage data of the project that built giti:

767 saves
705 context switches
206 merges
146 undos
44 stashes (all orphaned. Nobody recovered work from them. The stash model is broken.)

5 operations cover what people do. The rest of git's surface is what people learn to avoid.

The scrml compiler is the reviewer

86% of pull request lead time is waiting for human review. For solo developers and small teams, that's pure friction with no information gain. A human reviewer reads a 30-line diff and approves it because the change is obvious. The bottleneck doesn't add quality. It adds latency.

giti land runs the scrml compiler over the changed files and the test suite. If both pass, the change lands. If either fails, the dev gets the same error their LSP would show: same diagnostic, same E-code, same span. There's no "the CI is broken but my local works" because the LSP and the gate share the compiler.

For teams that DO need human review, giti supports it as a layered primitive (Landing, Stack, TypedChange in §5 of the spec). Human review still happens. It just isn't the only gate.

The structural argument is identical to the LSP argument: when one tool owns the whole pipeline, you can use it as the review surface. You can't do this with git plus GitHub plus CircleCI plus Codecov plus Sonar. Those are independent services that have to negotiate. You can do it with giti plus scrmlTS, because they share an in-process compiler.

Conflict-as-data instead of conflict-as-disaster

jj-lib (giti's underlying engine) treats conflicts as first-class data in the working copy, not as an error state that halts work. A merge with conflicts produces a working state that contains the conflict explicitly. You can keep editing. You can switch away and come back. You can run tests against the conflicted state. The "you can't do anything until you resolve the conflict" failure mode that everyone has hit in git doesn't exist at giti's surface.

The longer-term play (spec §3.7, "engine independence milestone") is that scrml's compiler can do AST-level conflict resolution that text-merge tools can't. When two devs renamed the same function in different ways, the compiler knows which references resolve to which definition, and the merge proposes a coherent answer instead of "here are conflict markers, you sort it out".

Private scopes instead of `.gitignore` plus private repos

scrml apps frequently have files that are local-dev-only: secrets, machine-specific config, private notes. The git answer is "keep two repos" or "abuse .gitignore and pray". giti has private scopes (§12): a .giti/private manifest, glob-based, with engine-level routing that keeps private commits on a _private bookmark and refuses to push private content to public remotes.

Slices 1-5 have shipped (private add/remove/list, remote scope config, save-time scope classification, push safety, automatic split for mixed working copies). The mechanism is part of the platform, not a workaround over it.

Crash recovery built in

Because jj's working-copy-is-a-commit model continuously tracks the working directory, unsaved edits are recoverable after a crash. A process kill between saves doesn't destroy work. giti undo or giti history --ops shows the last working state. There is no equivalent to "I forgot to commit and lost three hours of work".

The shared structural argument

Both LSP and giti make the same bet: when one piece of software owns the whole surface, you can ship features that piecewise alternatives cannot. The LSP knows your DB schema and your application code in the same analysis pass, so it can suggest "did you mean username?" for an unknown SQL column. giti knows your compiler and your test suite as in-process libraries, so it can use them as the review gate without a CI round-trip.

The Volar/dbt/tsserver world cannot get to scrml's LSP capabilities by adding more services. The integration cost grows quadratically with the number of contexts. The git/GitHub/CI world cannot get to giti's land workflow by adding more bots. The negotiation cost grows quadratically with the number of integrations.

Vertical integration of a thoughtful design is the only path through this. scrml plus giti is what that path looks like.

Why programming for the browser needs a different kind of language

Bryan MacLee — Tue, 28 Apr 2026 01:44:49 +0000

authored by claude, rubber stamped by Bryan MacLee

TL;DR: JavaScript wasn't built for today's browser. scrml is.

I am part owner of a small trucking outfit based in northeastern Utah, mostly oil and gas. I drive one of the trucks. I also program. Never professionally, but I love solving puzzles. Not an experienced framework developer. I can hobble through React if I HAVE TO. I've spent quite some time thinking about what a language designed for the browser would actually look like. First in my head, then on paper and whiteboards, then through about twenty compiler attempts before the current one started landing.

The browser has shape

When you sit down to write a browser app, you commit to a specific set of things. Reactive state. A server boundary. SQL. Scoped styles. Forms. WebSocket. Workers. Routing. Authentication. Validation.

JavaScript was not designed for any of these. JavaScript was a scripting language for a 1995 page-with-a-form. The browser grew up. The language did not.

So the ecosystem grew up around the language instead. React for components. Redux or Zustand for state. React-router for routing. Prisma or Drizzle for SQL. Zod for validation. Styled-components or Tailwind for styling. Socket.IO for sockets. Vite for the build. Each one is a library that retrofits a piece of the browser's shape onto a language that does not model it. The seams between those libraries are where most of the bugs live. The compiler does not own the whole picture, because the language does not model the whole picture.

That is the gap. Everything else in this article is what closes when the language does model the picture.

Six things a browser-language should own

1. State as a type

In most frameworks, state lives in a hook or a binding (useState, ref, createSignal), each with rules you have to follow: call it the same way every render, do not put it in a conditional, follow the dependency-tracking conventions. The rules are not enforced by the language. You learn them by hitting them.

What if state were a type? An <input> is already a state. It has a value, it changes over time, the user interacts with it. Make user-defined state work the same way. < Card> declares a state type. <Card> instantiates one. @count is reactive; the compiler tracks reactivity through fn signatures, through match arms, across the server boundary. Errors that frameworks catch at runtime, or never, become compile errors here. There is no conceptual gap between "the input element is a state" and "the user-defined Card is a state."

2. The server boundary as a type-system question

In framework land, where-this-runs is your problem to remember. The compiler cannot help.

Mark a function server fn and the compiler does the rest. It partitions everything that function touches as server-only, generates the route, generates the fetch stub on the client, and fails compile if you try to read a server-only @var on the client. You stop writing API routes. You stop writing fetch wrappers. You stop having to remember which file runs where.

3. SQL as a primitive

ORMs are tempting because the noise around SQL strings in JS is real. But ORMs trade one kind of noise for another: query DSLs that approximate SQL but never are SQL, schema files that drift from your database, runtime errors when the generated query does not match the live schema.

If the compiler owns the SQL block, you do not need an ORM. ?{SELECT * FROM users WHERE id = ${@id}}.get() writes a parameterized query. The compiler reads your schema. When it sees a query inside a loop, it pre-fetches with WHERE id IN (...) and rebinds the loop body to a Map lookup. No DataLoader. No manual batching. The loop body looks like the loop body should look.

4. CSS without a build step

Native CSS shipped @scope while we were not looking. A browser-language designed today should compile its scoped styles to that, not to a runtime mangler. One spec change in the browser closed a feature most frameworks still ship as a library.

5. Validation as the type

Zod is genuinely impressive engineering. But what Zod cannot do (what no library can do, because it is structurally outside the language) is fail your build.

If the type system supports inline predicates (let amount: number(>0 && <10000)), then validation IS the type. Violations are E-CONTRACT-001 at compile time. Named shapes (email, url, uuid) are first-class. There is no schema file separate from the type. There is no validate-on-the-edge boilerplate.

This is what I mean by "mutability contracts." Value predicates are the contract on every write. Presence life-cycle (not, is some, lin) is the contract on read order. State machine transitions are the contract on what comes next. Layer them as you need them. Leave them off where you do not. When you do declare one, a fn can mutate through it and remain provably pure.

6. Realtime and workers as syntax

A <channel> declares a WebSocket endpoint. The compiler generates the upgrade route, the client connection manager, auto-reconnect, and pub/sub topic routing. @shared variables inside a channel sync across every connected client.

A nested <program> compiles to a Web Worker, a WASM module, or a foreign-language sidecar, with typed RPC, supervised restarts, and when message from <#name> event hooks on the parent side. No new WebSocket(). No postMessage plumbing. No worker-loader config. Almost every nontrivial browser app reaches for sockets and workers eventually; the language can either treat them as primitives or watch you write the same plumbing every time.

What you give up

A language without npm cannot pretend to have npm's ecosystem on day one. I am still convinced npm is evil, but "npm is evil" is a position about ecosystem dynamics, not a feature parity claim. The vendoring story is rough. The scrml vendor add <url> CLI is on the roadmap and not shipped. Until it ships, ingesting an arbitrary client-side bundle is more work than it should be. That is real. I would rather you know than find out the hard way.

When you enumerate the npm packages a typical scrml app would actually want, the list collapses. The framework tier, the routing tier, the styling tier, the validation tier, the SQL tier, the realtime tier: all of them are subsumed by the language. What is left is heavyweight client-side widgets (CodeMirror, three.js, Leaflet) and the rounding error of small utility libraries the stdlib will absorb over time.

What you gain

The biggest single win is not a faster runtime. It is moving the work the runtime is doing into the compiler. A reactive system that wires its dependencies at compile time does no work at runtime to figure out what to update. A query that batches itself at compile time does not need a DataLoader. A boundary that is enforced at compile time does not need a validator on the wire. The runtime does less because the compiler did more.

That is the design. It is not anti-framework; frameworks are solving the problems available to libraries. It is not framework fatigue. It is just that when a language is shaped for the problem the browser actually poses, the resulting code is shorter, faster, and provably correct in places where the framework path is "hope your tests catch it."

I am sure I am wrong about plenty. But the more I build, the more it feels like the shape was always there waiting for someone to build the language for it. A little short of perfect is still pretty awesome.

Null was a billion-dollar mistake. Falsy was the second.

Bryan MacLee — Sun, 19 Apr 2026 21:10:21 +0000

Null was a billion-dollar mistake. Falsy was the second.

"I call it my billion-dollar mistake. It was the invention of the null reference in 1965."
— Tony Hoare, 2009

Tony Hoare gets to call it a billion-dollar mistake because he invented null and watched the industry pay for it for forty years. Most of us inherited that mistake and added our own contributions on top. JavaScript, in particular, made two design choices in the 1990s that we are still paying for in 2026 and will keep paying for in any new codebase that ships tomorrow.

The first is having null and undefined as two distinct values for the same thing.

The second is "falsy."

I built scrml — a single-file, full-stack reactive web language — partly because I got tired of paying. The intro post is over here; this post is about the absence-and-truthiness fix that scrml makes possible because it is its own language with its own rules. It's also a rant, because some design decisions deserve one.

Mistake 1: two values for "no value"

JavaScript decided in 1995 that there should be both null and undefined. They mean almost the same thing. They are not interchangeable. They behave subtly differently across operators, methods, JSON, equality, and type coercion.

typeof null         // "object"     ← yes, really
typeof undefined    // "undefined"

null == undefined   // true   (loose equality treats them as the same)
null === undefined  // false  (strict equality does not)

JSON.stringify({a: null, b: undefined})
// '{"a":null}'      ← undefined is silently dropped

Where does each one come from? You can't predict it. null shows up wherever a developer typed it. undefined shows up:

when a variable is declared but not initialized (let x;)
when an object property doesn't exist (obj.missing)
when an array index is out of bounds (arr[999])
when a function returns nothing (function f() {})
when optional chaining short-circuits (a?.b?.c)
when destructuring a missing key (const { x } = {})
when a function parameter is omitted (f() where f(x))

Some libraries normalize on null. Some normalize on undefined. Most do whatever the original author thought was right that day. You do not get to know in advance which one any given codepath will hand you.

So we write defensive code:

if (x !== null && x !== undefined) { ... }

Or the clever version:

if (x != null) { ... }   // != catches both null and undefined

The clever version works because of loose equality. So now your "safe" check requires the operator your linter has spent five years trying to get rid of. Every codebase has both forms. Every code review is a small argument about which to use. None of this is solving a problem; it is mopping up a design choice from 1995.

Mistake 2: falsy

The second mistake is bigger. JavaScript decided that in any boolean context — if, while, &&, ||, the ternary — six values should evaluate as false:

0
""
false
null
undefined
NaN

This is called falsy. It is the most dangerous abstraction in the language.

The danger is that falsy conflates absence with valid-but-zero/empty. Those are different things, and "different things" is the entire reason types exist.

A counter at 0 is not absent. An empty string is a valid string. NaN is a real result in the number domain. false is the boolean answer to a question, not a missing one. null and undefined mean something else entirely.

function showCount(count) {
  if (count) {                    // ← bug
    document.body.append(`Total: ${count}`)
  } else {
    document.body.append("No items")
  }
}

showCount(0)   // "No items"  ← wrong, there are 0 items, that IS a count

Every JavaScript developer has shipped this bug. It comes back in different shapes:

if (user.name)            // fails on legit empty name
if (config.timeout)       // fails on legit 0 timeout
if (response.body)        // fails on legit empty-string body
if (array.length)         // works (kind of) but only by coincidence

The fix is to write the actual question you meant:

if (count != null)             // "is this absent?"
if (count > 0)                 // "is this positive?"
if (count !== 0)               // "is this nonzero?"
if (typeof count === "number") // "is this a number at all?"

Each of those is a different question. if (count) answered all four at once and produced one answer for all four. That's not a feature; that's a category error baked into the language.

What strict TypeScript does fix, and what it doesn't

TypeScript's strictNullChecks is genuinely good. It forces you to type optionality explicitly (T | null, T | undefined) and rejects code that doesn't handle the absence case. It also gives you ?? (nullish coalescing) and ?. (optional chaining), which treat null and undefined together — an implicit acknowledgement from the language designers that distinguishing them was a mistake.

What strict TS does NOT fix:

null and undefined are still two distinct values. The type system tracks them; the runtime still has both.
The falsy rule is unchanged. TS does not touch JavaScript's runtime semantics. if (count) still silently fails on 0. The compiler will not warn you. Your linter might, if you've configured it. Most people have not.

TS strict is the best you can do without designing a new language. It is also not enough.

What scrml does

scrml is a new language, so it has the privilege of fixing both mistakes at the source.

There is one value for absence. It is called not. The keywords null and undefined are not valid identifiers in scrml source. Writing them is a compile error.

let x = not                    // ok
let x = null                   // E-SYNTAX-042
let x = undefined              // E-SYNTAX-042

There is one way to check for absence. It is is not.

if (x is not) { handleAbsence() }
if (x is some) { handlePresence(x) }

There is no falsy rule. Boolean contexts accept booleans. The only false thing is false. The only absent thing is not. 0 is a number. "" is a string. They are not "false-ish" or "absent-ish" — they are zero and empty, respectively, and you have to ask the question you actually meant.

if (count is not) { ... }      // "no value"
if (count == 0) { ... }        // "zero"
if (count > 0) { ... }         // "positive"

Three different questions. Three different answers. The language refuses to let you confuse them.

Narrowing is enforced by the type system. When a variable is T | not, you can't use it as T until you've handled the absence case. The way you do that is given:

${
    given x => {
        // x is T here, not T | not
        // the | not has been narrowed away
        use(x)
    }
}

The given block runs only when x is some, and inside it the compiler narrows x to its non-absent type. Forgetting to handle absence is not "best practice"; it is a compile error.

For pattern matching:

${
    match x {
        not       => handleAbsence()
        given x   => handlePresence(x)
    }
}

Match on a T | not without a not arm? Compile error (E-MATCH-012). Exhaustiveness for absence is forced.

What about the JS interop?

The compiler emits plain JavaScript. JavaScript libraries hand back null and undefined indiscriminately. Doesn't this all fall apart at the boundary?

No. is not compiles to a check that catches both:

x is not       →    (x === null || x === undefined)
x is some      →    (x !== null && x !== undefined)
given x        →    if (x !== null && x !== undefined) { ... }

The chaos stays in the runtime. The source stays clean. When a JS library returns either, the absence check still works correctly. You write one form; the compiler emits the safe form for you.

The same applies to SQL results (?{}.get() returns T | not, not T | null), to optional fields, to function returns. Everywhere absence might come from, the language gives you one way to express it and one way to handle it.

"But this is more keystrokes than `if (x)`"

Yes. Eight characters more, in fact: if (x is some) vs if (x).

It is also a category of bug that does not exist in scrml programs. The line where you wrote if (count) and thought you handled zero correctly is the line that cost your team a day of debugging. The line where you wrote if (user) and the API returned null once for one user is the line that put a 500 in front of one customer for a week.

Languages do not have a moral obligation to be terse. They have a moral obligation to make wrong programs hard to write. JavaScript, by treating absence as identical to zero and empty and false in boolean contexts, made a particular class of wrong program very easy to write. We have been paying for that ever since with sentry alerts, post-mortems, and "I swear it worked locally."

The trade is a few extra characters for one fewer category of recurring bug. It is the most obvious trade in language design and it is the trade JavaScript could not make in 1995, because it had a ten-day deadline and was trying not to break the web.

We don't have that excuse anymore.

Try it / follow along

Site: https://scrml.dev
Repo + spec: https://github.com/bryanmaclee/scrmlTS — see compiler/SPEC.md §42 for the full not semantics
Intro post: Introducing scrml
The living compiler post: It's Alive — A Living Compiler
X / Twitter: @BryanMaclee — there's a thread version of this argument up there if you prefer the rant in 14 tweets.

If null vs undefined has bitten you in the last month, I want to hear the story. If you think falsy is fine and I'm overreacting, I want to hear that too — there's a defence of the design choice and I haven't heard one that holds up under load yet.

scrml's Living Compiler

Bryan MacLee — Sun, 19 Apr 2026 16:06:01 +0000

It's Alive

"It's alive! It's alive!" — Henry Frankenstein, 1931

If you read the intro post, you saw scrml's headline pitch: one file, full stack, compiler does everything.

This post is about the design choice that scares me the most. The one where, every time I describe it, somebody pauses and says wait, you're doing **what?

scrml has a living compiler (in phase 4 of impl). The codegen layer isn't fixed. Community-contributed transformations compete for usage, the population decides which graduate to canonical, and the compiler evolves with the ecosystem instead of with a release cycle.

That's the monster. Let me explain how it's stitched together.

The frozen compiler is convenient until it isn't

Compilers, in the normal world, are frozen things. A standards committee meets. RFCs are drafted. Implementations follow. New patterns wait years. The codegen layer, in particular, is sacred; it's where the language's identity lives.

That model has good reasons behind it. Stability. Reproducibility. A clear blame surface when something breaks. You know what your compiler does because someone with merge rights decided what it does.

The cost of that model is everything that doesn't fit committee timelines. A new browser API ships and you wait three years for the codegen to adopt it. A pattern emerges in real apps that would compile to better output, but the maintainers can't justify the risk to existing users. A specific domain (games, dashboards, embedded) has codegen needs that the general-purpose path will never optimise for.

In the JavaScript world, we route around this with userland libraries. We npm install the new pattern, write a runtime adapter, and pay the cost in bundle size, indirection, and supply-chain risk. The compiler stays frozen and the ecosystem grows messy around it.

scrml does the opposite. The compiler stays alive and the package layer goes away.

The argument I'm extending

This is not my argument. It's an argument gingerBill has been making for years with Odin, and I'm pushing it one step further.

gingerBill's case — in talks, blog posts, and the Odin language itself — is that the package layer is the problem. Central registries, transitive dependencies, opaque update cadences aren't solving a problem; they are the problem, restated. Odin's answer is radical and consistent: no package manager, no registry, vendor everything, dependencies-as-liabilities.

scrml inherits that premise completely. Every time you read "no npm, no transitive trust, vendor-everything" in this post, that's gingerBill's argument, and it's worth reading him directly before reading the rest of what I'm about to say.

The living compiler, is scrml taking his rejection seriously. Then going one step further. Odin rejects package management. scrml rejects it too, and then notices that even if you vendor every library, the compiler itself is still a frozen dependency — and freezing the compiler has its own costs. So we keep the registry idea, but make it distribute compiler transformations instead of runtime code, and let the population drive what graduates.

That's the moon-shot. It only exists because gingerBill already made (proved, IMO) the first half of the argument.

What "living" means

Inside the compiler, a scrml program decomposes into a graph of transformation signatures — typed shapes that say "this construct, in this context, with this type, becomes this output." A signature is the unit of codegen. The compiler ships with one canonical transformation per signature in the box, and that's what your code compiles down to today.

Now imagine the next part:

A developer writes an alternative transformation for one of those signatures. Maybe their version emits faster code for hot paths. Maybe it produces smaller output for a specific browser target. Maybe it specializes for an architecture pattern the canonical path didn't anticipate. They publish it.

Other developers can opt in to that alternative — explicitly, by use-ing it, the same way you'd use a syntax extension or a stdlib module. The compiler picks it up, runs it through a verification pass, and starts emitting that codegen for matching signatures in projects that opted in.

The interesting part isn't that alternatives can exist. It's what happens next.

The compiler observes which alternatives are getting used. Population-level signals — adoption, regression rate, performance deltas, error counts — feed a quality gate. Alternatives that stay green and grow adoption past a threshold graduate to canonical. Alternatives that regress get demoted. The canonical transformation for a given signature is whatever the population, through actual use, has converged on.

The compiler evolves with the ecosystem. Not with a release cycle. Not with a committee. But with the people writing apps in it.

This isn't a package registry. It's a registry of transformations.

npm distributes runtime code. Every dependency you install becomes JavaScript that runs in your app. Transitive dependencies pull more JavaScript. The blast radius of a single bad package is everything downstream that runs your code, including code you didn't write and didn't read.

scrml's living-compiler registry distributes compile-time codegen patterns. A transformation alternative isn't a runtime library — it's a function that takes an AST node and emits compiled output. It runs once, at build time, in the compiler's process. Its output is the same kind of plain JS the canonical transformation would have emitted. There's no transitive dependency tree because compiled output isn't a dependency. Your app links against the compiler, not against the alternatives the compiler considered.

That changes the threat model in ways that matter:

No transitive runtime exposure. A bad transformation can emit bad code, but it can't pull in 47 sub-dependencies that each get to run on your users' devices.
Output is verifiable. The compiler runs a verification pass over emitted code (sandboxed evaluation, type-shape check, regression suite). A transformation that emits something the verifier rejects never ships.
The blast radius is the signature, not the app. A bad transformation affects the codegen for one signature, in projects that explicitly opted in to that alternative. It doesn't get to touch unrelated parts of your code.

npm's problem isn't packages. It's the runtime trust model around packages. The living-compiler registry has a different trust model because it distributes a different thing.

Yes, you're allowed to be suspicious — there's a trust gradient

Three tiers, named at project creation. Pick the one that matches your paranoia level:

scrml init (default — the living compiler in full). Quality-gated alternatives are pulled in based on signatures in your code. Audit log committed to your repo so you can see exactly which transformations the build used. Fast, evolves with the ecosystem, takes the population's word for what's canonical.

scrml init --stable (lock-file mode). Same registry, but pinned. Your project locks the transformation set at init time and only updates when you say so. You get the population's choices but on your release cadence, not theirs. This is the closest analogue to a typical "lockfile + versioned deps" workflow.

scrml init --secure (vendor-everything). No registry trust. All transformations live in your repo, copied in as source, audited by you. The compiler never reaches out at build time. The population's signals don't touch your build. This is the gingerBill / Odin philosophy: dependencies are liabilities; vendor everything.

The default is the bold one. The other two exist because not every project wants to be on the bleeding edge of the ecosystem's collective opinion, and that's fine.

The objections, plus what we're doing about them

"You're going to need telemetry to make this work." Yes — opt-in, anonymised, signature-shaped (no source code, no project identifiers). Population signals are aggregate counts: how many projects use this transformation, what fraction green-build with it, what their build-time and bundle-size deltas are. Projects on --secure participate in nothing. Projects on --stable opt in to whichever surface they want. The default tier is opt-in by default to a minimal surface; the consent prompt at scrml init is concrete about what's measured.

"The supply-chain attack surface is enormous." It's a real surface, and it's the reason the verification pass and signing exist. Every transformation runs in a sandbox at build time. Output is verified against a regression suite before it can graduate. Transformations are cryptographically signed by their authors. Compromised authors get revoked at the registry layer. The threat model is documented and the mitigations are first-class concerns, not afterthoughts.

"Who decides when an alternative graduates?" The population does, against quality gates the compiler enforces. Humans confirm. The graduation step is git-committable to the registry repo, which is itself open. This is closer to the canary-test model used in big distributed systems than to a maintainer-pick or vote. The system recommends, humans decide, the recommendation is auditable.

"This sounds like it could go very wrong." It could. The closing argument for it is also the closing argument against it: the compiler grows with its users. If the ecosystem produces bad transformations, the ecosystem owns that. There is no maintainer-of-last-resort to blame. The compiler's identity is whatever the people writing apps in it have collectively converged on. That's either the most exciting governance story in language design or a slow-motion catastrophe, and honestly the difference depends on what we build now to make verification, signing, and graduation work as well as the verification of the language itself.

Where it is today

scrml is pre-1.0. The full living-compiler vision — the registry, the graduation pipeline, the telemetry surface — is Phase 4 work. The foundations are landing now: the use keyword that lets you opt in to vendored extensions, the vendor/ model that makes copy-everything trivial, the ^{} meta layer that lets local code override compiler behaviour today. Those are the rails the registry rolls onto.

What that means for you, today:

The use vendor:my-extension import path works — you can write a transformation alternative as a vendored module and use it in your project right now. It just doesn't graduate anywhere.
The compiler is open and watchable. You can read the canonical transformations, write your own, and see what the registry will eventually distribute.
The threat model and verification design are in the open. The deep-dives are in the scrml-support repo under docs/deep-dives/.

If the idea sounds interesting, the most useful thing is to write a couple of vendor: transformations now and see how it feels. The shape of those is the shape of what the registry will distribute later.

It's alive

Henry Frankenstein doesn't get to keep his monster. The story is about hubris, the cost of stitching things together you didn't fully understand, and the obligations you take on when you give something its own life.

I think about that a lot. The living compiler is the part of scrml's design that makes me, the maintainer, least comfortable — and the part I'm most certain about. Frozen compilers are conservative for good reasons. Frozen compilers also calcify. The web ecosystem already has one of those, and we paid for it with node_modules.

The bet here is that giving the codegen layer its own life, with verification and signing and population-level quality gates around it, lets the ecosystem grow without needing a kingmaker — and that the obligations that come with that are obligations worth taking on.

It's alive. Now we have to keep it that way.

Try it / follow along

Landing + quick start: https://scrml.dev
Repo + spec: https://github.com/bryanmaclee/scrmlTS
X / Twitter: @BryanMaclee
Living-compiler design notes: look in scrml-support/docs/deep-dives/ for transformation-registry-design-2026-04-08.md and debate-transformation-registry-2026-04-08.md — the architecture is open-source, including the arguments against it.

If this design choice seems sketchy. Thats because it is. I am building this language to push the envelope into the future, or off a cliff. Either way, should be a fun ride.

Reply here, on X (@BryanMaclee), or open an issue on the repo.

Introducing scrml: a single-file, full-stack reactive web language

Bryan MacLee — Sat, 18 Apr 2026 21:28:46 +0000

Introducing scrml

scrml is a compiled language that puts your markup, reactive state, scoped CSS, SQL, server functions, WebSocket channels, and tests in the same file — and lets the compiler handle everything in between. The compiler splits server from client, wires reactivity, routes HTTP, types your database schema, and emits plain HTML/CSS/JS. No build config, no separate route files, no state-management library, no node_modules mountain.

This post is an introduction. scrml is pre-1.0 and not production-ready — the language surface will still shift, some diagnostics are rough, and I'm sharing it now mainly to get design feedback before things calcify.

Why another language?

A typical modern web app spreads across five or more tools and files. You have React on the client, Node or Next on the server, a state library (Redux, Zustand, Jotai...), a separate router config, an API layer keeping client and server types in sync, a CSS system, a build toolchain, and your ORM. Each of those tools makes reasonable local choices, and collectively they produce the sprawl everyone complains about but nobody quite knows how to fix.

What if the compiler owned the whole stack?

That's the bet. Same file, same language, one compile pass. The compiler knows which functions are reachable from the client and which stay on the server, because it parses both. It knows which @var is read in which DOM node, because it builds a dependency graph. It knows your SQL schema, because it ran the schema extraction. So it can enforce things across those boundaries instead of leaving them to runtime coordination.

A counter in one file

Here's the entire program:

<program>

${
  @count = 0
  @step = 1

  function increment() { @count = @count + @step }
  function decrement() { @count = @count - @step }
  function reset()     { @count = 0 }
}

<div class="flex flex-col items-center gap-6 p-8 min-h-screen bg-gray-50">
  <h1 class="text-3xl font-bold text-gray-800">Counter</h1>
  <p class="text-6xl font-bold text-blue-600">${@count}</p>

  <div class="flex gap-2">
    <button class="px-5 py-2 text-lg bg-red-500 text-white rounded-lg cursor-pointer hover:bg-red-600" onclick=decrement()>−</button>
    <button class="px-5 py-2 text-lg bg-gray-200 rounded-lg cursor-pointer hover:bg-gray-300" onclick=reset()>Reset</button>
    <button class="px-5 py-2 text-lg bg-green-500 text-white rounded-lg cursor-pointer hover:bg-green-600" onclick=increment()>+</button>
  </div>

  <label class="flex items-center gap-2 text-sm text-gray-600">
    Step:
    <input type="number" class="w-16 p-1 text-center border border-gray-300 rounded" bind:value=@step min="1" max="100">
  </label>
</div>

</program>

@count and @step are reactive variables — language primitives, not library wrappers. bind:value is two-way binding. onclick=increment() wires the handler. The compiler emits direct DOM updates (no vdom, no diffing) for every site that reads @count. The Tailwind utility classes above compile via a built-in Tailwind engine — no tailwind.config.js, no postcss, no content scan — so utility CSS works out of the box and you can still drop into a scoped #{} block when utilities aren't enough.

Three things that are different

1. State is a first-class type

< Card> declares a state type; <Card> instantiates one. HTML elements like <input> and <form> are state types — the language treats them uniformly with your own types. Every state value flows through match, through fn signatures, and across the server/client boundary with static checks. The compiler knows what shape a Contact is, which fields are protected (server-only), and which routes need to serialize what. You write Types once; they hold across the stack.

2. Any variable can carry a compile-time contract

Contracts come in three flavours.

Value predicate — reject out-of-range writes:

@price: number(>0 && <10000) = 1

Presence lifecycle (lin) — must be consumed exactly once; the compiler refuses a double-use or a silent drop:

lin token = fetchCsrfToken()
submitForm(token)    // consumed — compile error if you used it twice or not at all

State transitions — only legal moves allowed:

type DoorState:enum = { Locked, Unlocked }

< machine name=DoorMachine for=DoorState>
    .Locked   => .Unlocked
    .Unlocked => .Locked
</>

@door: DoorMachine = DoorState.Locked
@door = .Unlocked    // ok
@door = .Locked      // ok — Unlocked => Locked is declared

The < machine> rejects illegal transitions at both compile time and runtime. If the compiler can prove the destination is unreachable from the current state, it errors then and there. If something dynamic sneaks through (a network response, user input routed into a transition), the runtime enforces the same table. One source of truth, two layers of enforcement.

3. N+1 gets rewritten automatically

A pattern like this:

for (let user of users) {
  let orders = ?{`SELECT * FROM orders WHERE user_id = ${user.id}`}.all()
  ...
}

becomes a single WHERE user_id IN (...) pre-fetch plus a keyed Map lookup. Because the compiler owns both the query context and the loop context, it can see that the per-iteration query is a safe batching candidate. When it isn't safe, you get a D-BATCH-001 diagnostic with the exact disqualifier and a ?{...}.nobatch() escape hatch.

Measured on on-disk WAL bun:sqlite (median of 50 iterations after 5 warmups, table size 1000, full results in benchmarks/sql-batching/RESULTS.md):

N	Baseline (ms)	Optimized (ms)	Speedup
10	0.0111	0.0057	1.95×
100	0.1068	0.0410	2.60×
500	0.5124	0.1654	3.10×
1000	1.0490	0.2625	4.00×

Upper bound is SQLITE_MAX_VARIABLE_NUMBER (32,766). Network-attached storage would widen the gap further.

There's more that didn't fit here

To keep this post focused, I left out:

WebSocket channels (<channel>) — auto-generated upgrade routes, auto-reconnect, and @shared vars that sync across connected clients
Web Workers as nested <program>s — heavy work compiles to a worker with typed RPC and supervised restarts
Scoped CSS (#{}) that applies only inside the component it's declared in
Typed SQL where the schema extraction feeds back into type checking
Inline tests as language constructs

Each is worth its own writeup. I'll do follow-up posts if there's interest.

Where it is today

Pre-1.0 — breaking changes likely, rough edges, not production-ready
MIT — compiler is fully public
6,800+ tests passing — every language feature is test-covered
~45 ms — full compile for a TodoMVC-sized app on a 2021 laptop
Bun today — Node/Deno ports are possible but not priorities

Try it / follow along

Landing + quick start: https://scrml.dev
Repo + spec: https://github.com/bryanmaclee/scrmlTS
X / Twitter: @BryanMaclee
The spec (if you want the depth): compiler/SPEC.md in the repo — sections 14 (types), 18 (match), 42 (lifecycle), 51 (machines), 52 (server authority) are the meatiest.

Feedback on the design is the thing I'm actually optimising for right now. If something looks wrong, looks over-engineered, looks like it'll trip on a real app — I want to hear about it here, on X (@BryanMaclee), or as an issue on the repo. Happy to chase threads before the language surface calcifies.

DEV Community: Bryan MacLee

The server boundary disappears

What "shipping a typed POST endpoint" actually costs

The same feature in scrml

What the compiler refuses

What gets generated for free

What this kills

What is still real

The deeper claim

Further reading

What npm package do you actually need in scrml?

What npm package do you actually need in scrml?

What npm typically supplies, and where each goes in a scrml app

Replaced by the language itself

Replaced by Bun

Already in scrml's stdlib

Trivially vendored or rewritten

Service SDKs are mostly thin REST wrappers

Where npm interop actually bites

So what's the strategic gap?

The deeper point

Further reading

What scrml's LSP can do that no other LSP can, and why giti follows from the same principle

Part 1: The LSP

Why mainstream LSPs hit a ceiling

Why scrml doesn't hit it

Cross-file component prop completion

Cross-file go-to-definition that's actually accurate

Code actions that quick-fix scrml-specific errors

Signature help that crosses files

Hover with reactive/tilde badges and state field types

Document symbols with semantic meaning

What's deliberately NOT shipped (and why)

Summary

Part 2: Why giti follows from the same principle

Git's mental-model problem

The 5-function surface

The scrml compiler is the reviewer

Conflict-as-data instead of conflict-as-disaster

Private scopes instead of .gitignore plus private repos

Crash recovery built in

The shared structural argument

Further reading

Why programming for the browser needs a different kind of language

The browser has shape

Six things a browser-language should own

1. State as a type

2. The server boundary as a type-system question

3. SQL as a primitive

4. CSS without a build step

5. Validation as the type

6. Realtime and workers as syntax

What you give up

What you gain

Further reading

Null was a billion-dollar mistake. Falsy was the second.

Null was a billion-dollar mistake. Falsy was the second.

Mistake 1: two values for "no value"

Mistake 2: falsy

What strict TypeScript does fix, and what it doesn't

What scrml does

What about the JS interop?

"But this is more keystrokes than if (x)"

Try it / follow along

scrml's Living Compiler

It's Alive

The frozen compiler is convenient until it isn't

The argument I'm extending

What "living" means

This isn't a package registry. It's a registry of transformations.

Yes, you're allowed to be suspicious — there's a trust gradient

The objections, plus what we're doing about them

Where it is today

It's alive

Try it / follow along

Introducing scrml: a single-file, full-stack reactive web language

Introducing scrml

Why another language?

A counter in one file

Three things that are different

Private scopes instead of `.gitignore` plus private repos

"But this is more keystrokes than `if (x)`"