Nothing here was invented.

TakenSpec-driven, batteries-included, explicit whole-app declaration. Nearest thesis twin.

Stops atDropped its custom DSL for a TypeScript spec in June 2026 after 5 years. Read the post-mortem before touching .lite.

The FrontierJS wayLooked at and left The whole-app declaration is the shared thesis and was taken gladly. The retreat from a custom DSL was not — knowingly, and with the post-mortem read. The bet is that a DSL only earns its cost if it is the seed of more than one realm: .lite feeds the migration, the API's validation and the browser's field rules from one file. If it were only feeding the ORM, Wasp would be right and this would be a TypeScript object.

Takenschema.ts to reactive queries to real-time by default. Live-by-default is core, not bolt-on.

Stops atPush-from-query rather than push-from-mutation-event. Costlier than FJS, correct more often.

The FrontierJS wayThe idea, not the mechanism Took the expectation — that live is the default state of an application, not a feature you bolt on — and refused the mechanism. Convex tracks what each query read and re-runs it; FJS announces the mutation and lets the client decide. That is cheaper and simpler, and it is honestly worse: a derived view nobody announced goes stale here and cannot there. Filed as a known trade, not a win.

TakenPrisma schema plus access policies declared in the schema. Literally gates. Record-level auth reference.

Stops atPolicy language grew a full expression grammar — schema overreach.

The FrontierJS wayTaken further The idea is taken whole — access declared on the model, compiled into the query, beneath every caller — and then pushed one realm further: the same declaration crosses the wire, so `resource.can()` answers in the browser from the rule the migration came from. Its overreach is taken as the warning: the policy language here stays deliberately small, and anything wanting a service call is a hook instead. A grammar in the schema is how a schema stops being readable.

Takenschema to SDL to cells to UI, Prisma-rooted. Source of the Cell pattern.

Stops atRedwood GraphQL wound down; CedarJS is the maintained fork. The Redwood name now means RedwoodSDK (Cloudflare/RSC), unrelated.

The FrontierJS wayThe idea, not the mechanism The Cell — a component that declares its own loading, empty and failure states alongside its query — is the shape `createResource` is reaching for, without GraphQL underneath it or a code generator between the two. The SDL layer was the part declined: it is a second description of data that already had one, and every layer like that is a place for the two to disagree.

TakenOriginal live-by-default and isomorphic stack.

Stops atDied of coupling. Read as autopsy — what happens when intentional gaps get closed too.

The FrontierJS wayStudied as a failure Read as an autopsy, and it is the direct reason the realms here are named and separable rather than fused. Mesa is a true leaf with zero workspace dependencies; the API realm survives even where it could be dissolved; every package is meant to be usable alone. Meteor proved that closing every seam feels wonderful for two years and then cannot be escaped. The gaps in FJS are deliberate, and this is who taught that.

TakenSource of the Channel vocabulary. Contexts map closely to realms.

Stops atEcto changesets — validation as a value that travels, not a hook side-effect. Not yet adopted in FJS.

The FrontierJS wayA debt not yet paid The Channel vocabulary was taken as-is, and Contexts are the closest prior art for the realms. The changeset is the outstanding debt and the most interesting idea on this page: validation as a value you can pass around, inspect and combine, rather than a hook that throws on the way past. FJS validates in a hook today. That is not a decision — it is just what has been built so far.

TakenTS entity as single source of truth to REST plus frontend client plus admin. Same thesis, tiny surface.

Stops atNot yet studied. Closest thing to a control experiment for the FJS thesis.

The FrontierJS wayA debt not yet paid Nothing has been taken, and that is the entry. It reaches the same conclusion — one declaration, radiating to server and client — from a TypeScript entity rather than a schema file, on a fraction of the surface area. Either it shows the DSL is unnecessary, or it shows exactly what a DSL buys. Both answers are worth having and neither has been earned yet.

TakenClosest Node analog for structure, CLI, and conventions. fli should feel like ace.

Stops atSchema is not the seed — models are classes.

The FrontierJS wayThe idea, not the mechanism The ergonomics were taken and the model layer was not. fli is measured against ace, the directory conventions against Adonis's, and the general principle that a Node framework may have opinions is largely its example. But a model that is a class is a second description of the table; here the table and the class are both readings of one file.

Takenschema to API plus realtime plus RLS, generated. RLS is the gate system in Postgres form.

Stops atProof that declared access scales. No application realm above it.

The FrontierJS wayThe idea, not the mechanism It supplies the evidence rather than the code: declared row-level access works at real scale, which is the load-bearing assumption under `@@allow`. What FJS builds on top is the part Supabase leaves to you — an application realm with services, hooks and jobs, in the same vocabulary rather than in whatever you brought. And no company in the middle: the same idea over a SQLite file you own.

TakenConfig-as-code collections to REST/GraphQL/admin, with hooks and per-operation access functions. Near-identical shape to Model plus Service plus Gate.

Stops atAccess is imperative functions, not declared attributes.

The FrontierJS wayTaken further The shape arrived at independently and matches almost line for line — collection, hooks, per-operation access — which is the best evidence that the shape is right. The difference is one word: access there is a function you write, access here is an attribute you declare. A function can only run where someone calls it; an attribute compiles into the query and holds for callers written later.

TakenThe zero-API thesis. Mostly dead.

Stops atRemoving the API realm entirely was the wrong cut. FJS kept it as an intentional gap — that was right.

The FrontierJS wayLooked at and left The lesson taken is negative and it is one of the most valuable on the page: the API realm is not ceremony to be abolished. It is where authorization, validation and the wire contract live, and an app that dissolves it has not removed the work — it has scattered it. FJS keeps the boundary and spends its effort making it cost almost nothing to declare.

TakenBlueprint routes auto-generated from models, realtime blueprints over sockets. The 2014 version of this idea.

Stops atLost because the ORM had no schema authority. Study the failure directly.

The FrontierJS wayStudied as a failure This is the derived API, twelve years early, and it is worth being humble about that. It lost because the ORM was permissive: the model was a suggestion, so the routes derived from it were a suggestion too. The single non-negotiable in FJS is the answer to exactly that — the .lite file is the authority, the database is migrated to match it, and the ORM reads it rather than defining it.

TakenModel to API automatically, with ACLs declared on the model. Same gate instinct.

Stops atDrowned in decorators. Cautionary case for declaration ergonomics.

The FrontierJS wayStudied as a failure Same instinct, opposite ergonomics, and the reason declarations here are attributes rather than decorators. `@@gate(0.4.4.5)` on the model is one line you can read at a glance; the equivalent in decorator form is a paragraph of imports and generics wrapped around the thing it describes. Being declarative is not enough — the declaration has to stay smaller than what it replaces.

TakenInfrastructure declared in code, provisioned from the declaration. Best available model for the Manifest to Release pattern.

Stops atNobody else does declaration to realization this cleanly at the infra level. Under-studied.

The FrontierJS wayA debt not yet paid It is the model for the realm FJS has built least of. Release exists as a noun and a deploy pipeline; declaration-to-provisioned-infrastructure is still aspiration. Encore has done it more cleanly than anyone and has been read too little. When the Manifest becomes something an operator acts on rather than something a page renders, it will be walking a path this project already mapped.

TakenDatabase to GraphQL API to role permissions, with no controllers in between. Row filters keyed on session variables are a gate by another name.

Stops atPermissions live in metadata beside the schema, not in it. A separate engine in front of the database; no application realm of its own.

The FrontierJS wayLooked at and left Little was taken from it — it is here as corroboration, not as a source. The shape it proves is the one ZenStack and Supabase already taught: schema to API to permissions with nothing hand-written in between. Where FJS parts company is where the rules live: Hasura keeps them in a metadata layer you edit through a console, while `@@gate` and `@@allow` sit in the `.lite` file next to the fields they protect, and the API is your own process rather than an engine in front of it.

TakenA data model becomes a whole app surface: REST/GraphQL API, role permissions, an admin studio and forms.

Stops atThe surface it reaches is an admin panel, and the model is configured through the studio and stored in the database rather than written in a file.

The FrontierJS wayLooked at and left Barely an influence. It proves a data model can carry permissions, an API and forms at once, but the UI it reaches is the back office. FJS points the same derivation at the product: a Resource takes its form, field options and validation from the model, inside the app your users see. And the model is a checked-in `.lite` file you diff and review, not rows in a system table a studio wrote. Litestone Studio exists, but as a developer tool, not as the product.

TakenOne request DTO yields a query API, CRUD, an auto UI (Locode) and typed clients in a dozen languages.

Stops at.NET, and query operators are inferred from property-name suffixes (`AgeOlderThan`, `NameStartsWith`), so the vocabulary is spelled into every field name.

The FrontierJS wayLooked at and left A parallel arrival rather than a source: the one-declaration-many-surfaces idea came here by way of Feathers and Prisma, not .NET. The concrete difference is the query grammar. AutoQuery reads the operator out of the property name; FJS keeps the field name a field name and puts the operator in the query, `{ age: { gt: 30 } }`, one vocabulary every transport shares. Typed clients are the part it does better today — `ServiceTypes` covers TypeScript only.

Taken"The schema is the application": REST API, cell-level security, content rendering, messaging, audit trail with rollback and a scheduler, all from the schema.

Stops atHosted, invite-only and closed. Security is records you configure rather than declarations you read, over MySQL or SQL Server.

The FrontierJS wayLooked at and left Little was taken from it; it is listed because the thesis matches almost word for word, and the batteries line up too — audit trail, mail, jobs. The split is ownership. dbo.io is a platform you build inside; FJS is a file tree and a SQLite file you own, with the access rules in a schema you can read in a diff rather than in security records behind a login. Assessed from its own marketing page, not from using it.

TakenOne schema file with `@primary`, `@unique`, `@refs()`, `@default()` attributes generates a server, REST API, browser UI, MCP tools and OpenAPI docs.

Stops atA generator over many databases at once; the AI tools are a generated layer, and access rules are not visible in the schema it shows.

The FrontierJS wayLooked at and left Not a source — found alongside rather than before — but the nearest in surface: the attribute syntax could almost be pasted into a `.lite` file. The difference is the agent. Schema2AI generates AI tools from the schema; FJS mounts the MCP endpoint inside the API that is already serving, so an agent goes through the same gate as a browser and there is no second path to keep in step. Assessed from its own page, not from running it.

TakenConvention over configuration. Kamal 2 is already the FJS deploy model.

Stops atMigrations, not schema-as-seed. Schema is the output, not the input.

The FrontierJS wayThe idea, not the mechanism The disposition is inherited almost entirely: conventions over configuration, one blessed layout, a framework with opinions and a CLI that acts on them. Kamal is the deploy model more or less as-is. The one place FJS turns the other way is the important one — in Rails the schema is the output of the migrations, here the migration is the output of the schema. Everything else on this page follows from that inversion.

TakenForge and Vapor are the Basecamp precedent. Ecosystem-as-product.

Stops atSame schema-as-output problem as Rails.

The FrontierJS wayThe idea, not the mechanism The standard for what 'complete' means: a queue, a scheduler, mail, notifications, policies and a CLI that all know about each other. app.notify is Laravel's notification design nearly unchanged, and the tooling story around Basecamp is Forge's precedent. What is taken further is reach — those batteries stop at the response here they keep going, so the browser gets the field rules and the gate rather than a client SDK and a fresh start.

TakenThe assembled alternative FJS argues against. The honest comparison.

Stops atType safety across the wire, but no runtime coherence. Types are not gates.

The FrontierJS wayTaken further .lite deliberately wears Prisma's syntax — `model`, scalar then attributes — so nobody has to learn a new shape to read it, and that debt should be stated more often than it is. What is refused is stopping at compile time. Types vanish at runtime: they cannot filter a query by owner, reject a 60-character title, or tell a button it is not allowed. The schema here is read while the program runs, which is the whole argument.

TakenTS schema to data plus auth plus API in one declaration. Same radiation.

Stops atWorse ergonomics, vendor-locked. Radiation without coherence.

The FrontierJS wayStudied as a failure Proof that the radiation is not the hard part. One declaration producing data, auth and an API is achievable and has been achieved — and it still is not pleasant to use, because the pieces it produces do not share a vocabulary or a place to stand. Coherence is the product. It is also the argument for staying self-hostable: the same derivation with a vendor underneath it is a different deal entirely.

TakenSierra's direct model. File-system routing, load(), prefetch, layouts. .mesa maps to .svelte, script module maps to Svelte's module context block.

Stops atNo Data or API realm. Sierra inherits the shape but not the seed.

The FrontierJS wayTaken as it is Taken about as directly as anything here: file-tree routing, layout chains, load-then-render, the single-file component with a module block. Someone who knows SvelteKit can read Sierra without being taught it, and that is the intent rather than an accident. The one thing added is what the route binds to — a Resource that already carries the schema's field rules and its gate, instead of a fetch you write.

TakenMesa's reactivity model. Fine-grained signals, compile-away components, no virtual DOM. createSignal maps directly to Mesa's runtime primitives.

Stops atLibrary, not framework. Mesa takes the runtime, Sierra supplies everything above it.

The FrontierJS wayTaken as it is The reactivity model is taken wholesale — fine-grained signals, components that run once, no virtual DOM, ownership scopes for anything with a lifetime. Mesa's runtime primitives are recognizably the same primitives. What sits on top is a compiler that owns the template, which is what lets one component render to a live DOM, to static HTML with islands, or to table-based markup for an email.

TakenRust multi-model content database: YAML NodeTypes at hierarchical paths, graph edges, vector and full-text search, realtime subscriptions, git-like branches of schema and content.

Stops atA database, not an application framework — the frontend maps nodes to components on its own. BSL-licensed.

The FrontierJS wayLooked at and left No influence. It shares one instinct — a schema can say how content should be presented, not only how it is stored — and it is multi-tenant and realtime by design. FJS reaches that through relational models in a `.lite` file and Resources in the UI realm, over plain SQLite, rather than typed nodes in a document-graph store. Its branch-and-merge of schema with content has no FJS counterpart.