By ByteBot
A Y Combinator-backed startup spent five years and $5 million building a custom programming language for web development — then published a blog post admitting it was a mistake. Wasp’s detailed postmortem, published May 13, drops a rare admission from a funded team: the language was never the product. The TypeScript pivot fixes the wrapper, not the framework.
What Wasp Actually Built
Wasp targets a real problem: accidental complexity in full-stack web development. Authentication, routing, background jobs, email — every app needs all of it, and every team scatters the implementation across dozens of files using slightly different patterns. Wasp’s answer was a .wasp configuration file that declared the entire app’s structure in one place. The framework generates the glue code. The 90 percent of user code that remains is still standard React and Node.js.
The framework now has 18,300+ GitHub stars and is shipping production apps. The custom language was supposed to enforce the specification. It turned out to be the wrong vehicle.
Three Things That Went Wrong
The first mistake was naming. Calling the repo wasp-lang made developers assume Wasp wanted to replace JavaScript. It did not — but “new language” signals “new ecosystem, new tooling risk, new learning curve.” Developers who bailed before trying it were not wrong to be cautious. They had the wrong mental model, and the name put it there.
The second mistake was underestimating tooling debt. Every custom language needs a language server, IDE integration, syntax highlighting, and autocomplete. After years of effort, Wasp achieved roughly 80 percent of the IDE experience developers expected. The embedded Prisma DSL made full IDE support even harder. TypeScript comes with world-class tooling baked into every editor — for free.
The third mistake was ecosystem isolation. Framework configuration has converged on TypeScript. Vite, ESLint, Tailwind v4, Next.js, SvelteKit — all use TypeScript config files. A .wasp file required developers to explain Wasp before Wasp could do anything useful. That friction compounds at every adoption touchpoint.
The Core Insight
“Language was never the moat. It’s having a high-level understanding of your entire app at compile time.”
Wasp team, May 2026 postmortem
The compiler that understands your routes, authentication configuration, background jobs, and data entities — and generates consistent, safe code from that understanding — is the actual product. The DSL syntax was just the front door. They built the wrong front door. The house is fine.
What Changes With the TypeScript SDK
The pivot is a single interface change. The compilation pipeline and full-stack architecture are untouched. Config moves from .wasp to .wasp.ts:
const loginPage = app.page('LoginPage', {
component: { importDefault: 'Login', from: '@src/pages/auth/Login' }
});
app.query('getTasks', {
fn: { import: 'getTasks', from: '@src/queries' },
entities: ['Task']
});Immediate benefits: zero editor setup, full TypeScript language features, trivial multi-file splitting, and conditionals and loops without workarounds. Existing Wasp users need to migrate; new developers skip the language-learning step entirely. The TypeScript SDK ships as the default during Wasp’s upcoming Launch Week.
Why This Matters for AI-Assisted Development
The Rails renaissance is not nostalgia. AI coding tools generate more accurate Rails code because the framework has strong conventions — there is usually one right place to put something, and LLMs have internalized those patterns. Wasp is attempting the same thing for the JavaScript world.
A framework where an AI agent reads a .wasp.ts file and immediately understands your authentication providers, routes, data model, and background jobs — without crawling dozens of directories — is a meaningfully better target for agentic coding. Encore.ts built declarative TypeScript infrastructure-as-code from day one and validates this direction. The TypeScript SDK removes the last significant barrier for AI tools working with Wasp projects.
What the Broader Lesson Actually Is
The easy read here is “custom DSLs are always a mistake.” That is not the lesson. SQL, CSS, GraphQL SDL, and Prisma’s schema language are DSLs that succeeded because they own their domain completely and offer no TypeScript-based alternative that covers the same ground. Wasp’s DSL failed not because DSLs are bad but because it did not own enough of the developer’s world to justify the tooling investment — and TypeScript was right there, already doing 90 percent of what the DSL needed to do.
Before reaching for a custom language, the question to ask is not “would a DSL be elegant here?” but “would a TypeScript API be expressive enough?” For web framework configuration in 2026, the answer is almost certainly yes. The Lobsters thread has sharper takes if you want the unfiltered version.
Five years is a significant investment to publicly reckon with. Most startups do not do it. The framework that investment built is still standing — with 18,300 stars, a production user base, and a cleaner interface than it had yesterday.
