By Wasp just published an unusual blog post — an honest post-mortem admitting that inventing a custom programming language for web development was a mistake. After five years and $5M, the team behind the full-stack React + Node.js + Prisma framework is replacing its bespoke .wasp DSL with a TypeScript SDK. Launch Week that ships the TypeScript SDK as the default is imminent. Here is what changes, what does not, and whether Wasp deserves a place in your 2026 stack.
Why the Custom Language Failed
The honest answer, from the founders themselves: developers kept saying “I really like what you’re doing with Wasp, but why a custom language?” That objection never went away, no matter what the team tried. The custom DSL meant the entire JavaScript and TypeScript ecosystem — every editor, every plugin, every AI coding tool — treated Wasp projects as second-class citizens.
The technical debt was worse. To get autocomplete and live error reporting in .wasp files, Wasp had to build and maintain its own language server and IDE plugin. TypeScript gives you all of that for free. The founders put it plainly: “Creating a new language makes sense for certain problems and domains, but in this case, it wasn’t a fit and brought more trouble than it was worth.”
This kind of honesty is rare. Most teams quietly pivot and call it a “v2 redesign.” Publishing a detailed post-mortem is a signal worth paying attention to.
What the TypeScript SDK Looks Like
The surface change is a file rename and a new import. Your main.wasp becomes main.wasp.ts. The new API uses a constructor from the wasp-config package:
// Old DSL (main.wasp)
app myApp {
wasp: { version: "^0.23.0" },
title: "My App",
auth: {
userEntity: User,
methods: { google: {} }
}
}
route HomeRoute { path: "/", to: HomePage }
page HomePage {
component: import { Home } from "@src/pages/Home"
}// New TypeScript SDK (main.wasp.ts)
import { App } from 'wasp-config'
const app = new App('myApp', {
title: 'My App',
wasp: { version: '^0.23' }
})
app.auth({
userEntity: 'User',
methods: { google: {} }
})
app.route('HomeRoute', { path: '/', to: 'HomePage' })
app.page('HomePage', {
component: { import: 'Home', from: '@src/pages/Home' }
})
export default appWasp’s internals are unchanged. The compiler still outputs standard React + Node.js + Prisma. Every existing feature — authentication, typesafe RPC, background jobs, email sending, one-command deployment — remains intact. Only the configuration surface changes, and that surface is now TypeScript that every editor understands from day one.
Why This Matters More in 2026
The timing of this shift is not accidental. AI coding agents changed the calculus for framework choice.
Wasp ran a direct comparison: the same feature prompt, built with Claude Code in a Next.js SaaS app and in a Wasp app. The Wasp version cost 44% less and used 38% fewer tokens. Cache reads alone were $1.71 with Next.js versus $1.09 with Wasp. The reason is structural — when authentication, routing, database management, and server functions are all declared in a config file, the AI agent reads less boilerplate and spends its context budget on actual logic.
Wasp introduced a metric they call “context efficiency”: the ratio of meaningful signal to infrastructure boilerplate in a codebase. The custom DSL was a liability here. AI coding tools do not know Wasp’s DSL syntax; they know TypeScript. Switching to a TypeScript SDK means Cursor, Claude Code, and GitHub Copilot all understand your config file and can generate it without hallucinating bespoke syntax.
What Wasp Actually Is
For developers unfamiliar with it: Wasp is a full-stack framework that compiles to React + Node.js + Prisma. Think of it as the “glue layer” that replaces hundreds of lines of boilerplate — auth wiring, route definitions, database schema setup, server function registration. You declare your app structure in one config file; Wasp generates and manages the scaffolding.
Built-in features include social and email authentication (Google, GitHub, Slack, Microsoft), typesafe RPC between client and server with auto-generated types, background jobs, email sending, and one-command deployment to most major platforms. You bring your components and business logic; Wasp handles the infrastructure.
Open SaaS: Production Evidence
The real test of any framework is whether production apps run on it. Open SaaS, Wasp’s free SaaS boilerplate, has crossed 14,000 GitHub stars. It ships with Stripe and Polar.sh payment integration, PostHog analytics, ShadCN UI, S3 file upload, an admin panel, email sending, and full authentication. It is also AI-ready — it ships with an AGENTS.md, Claude Code plugin, and predefined agent skills. No paid tier. That combination of star count and feature completeness suggests a growing number of teams are treating Wasp as production infrastructure, not just a demo toy.
When to Use Wasp
Wasp is not a Next.js replacement for every project. If you need granular control over your API structure, complex SSR/RSC patterns, or access to the full Next.js ecosystem, stay with Next.js. Wasp’s value proposition is for solo developers and small teams building SaaS products quickly — where the value of not writing auth infrastructure from scratch outweighs the constraint of Wasp’s opinions.
The TypeScript SDK move removes the last serious objection. Previously, you had to weigh whether Wasp’s features justified learning a niche language. Now you do not. The config is TypeScript, the output is TypeScript, and your AI coding tools will understand both. For an opinionated full-stack SaaS framework in the JS ecosystem, that is a meaningful upgrade.
Wasp’s TypeScript SDK is available now as an early preview via the official docs. The Launch Week that makes it the default is expected in the coming weeks — watch wasp.sh for the announcement.
