By Wasp, the Y Combinator-backed full-stack React/Node.js/Prisma framework, published something rare in tech this week: an honest postmortem. After five years of development and over $5M raised, the founders are scrapping their custom configuration language entirely and replacing it with TypeScript. The reason is straightforward — the custom language was always a mistake, and the team knew it for a while before finally pulling the trigger.
What Wasp Is (and Why It Mattered)
Wasp is best described as “Laravel for JavaScript” — a batteries-included framework that handles the full stack: auth, background jobs, RPC, email sending, end-to-end type safety, and single-command deployment, all built on top of React, Node.js, and Prisma. The framework compiles a declarative config into a working application, sparing developers from wiring up the same boilerplate across every project.
It’s not a small project. Wasp has 18,000+ GitHub stars, a growing community, and an associated open-source SaaS starter (OpenSaaS) with nearly 10,000 stars of its own. The framework is in production at real companies. The concept works.
The Custom Language That Seemed Like a Good Idea
The original thesis was reasonable: build a declarative language that describes a web application at a high level, and let a compiler handle the rest. Developers write a .wasp file specifying routes, pages, database models, auth configuration, and background jobs. Wasp generates the entire React + Node.js + Prisma project from that description.
It worked technically. The problem was everything surrounding it.
Where the Custom Language Fell Apart
The Wasp team underestimated one thing: how unforgiving the modern JavaScript developer experience has become. Developers expect 100% IDE integration — instant autocomplete, inline type errors, go-to-definition across the entire project. That bar is set by TypeScript and its tooling, and it is extremely high.
Wasp built its own language server and VS Code extension. After years of work, they reached 80% of their target. That gap — the remaining 20% — came from structural limitations that couldn’t be patched away. Wasp embedded Prisma’s own schema DSL as a sub-language. It referenced React and Node.js files across language boundaries. The language server couldn’t bridge those seams cleanly, and no amount of additional engineering was going to fix the fundamental mismatch.
The ecosystem friction compounded this. Every JavaScript tool — formatters, linters, AI coding assistants, build pipelines — is built for standard JS/TS. Custom languages hit walls fast. What looked expressive in a demo became daily friction: the formatter doesn’t understand .wasp files, the AI assistant can’t autocomplete them, the linter has no idea what’s happening.
And then there was the question that never stopped coming from developers evaluating the framework: “Why a custom language?” Not “this is broken” — just “why?” Developers who liked the concept kept bouncing off the prerequisite of learning proprietary syntax before they’d gotten any value from the framework. The cognitive tax arrived before the payoff.
The TypeScript Pivot
Wasp has already shipped a TypeScript SDK as an experimental preview. The response confirmed what the team suspected: some new users tried it and never touched the custom language at all. Launch Week — coming soon — will make the TypeScript SDK the primary way to use Wasp.
Crucially, the framework itself doesn’t change. The compilation pipeline, the feature set, the React/Node.js/Prisma stack underneath — all unchanged. This is an interface swap. “Wasp itself stays the same under the hood.” What changes is that you now configure your application in TypeScript, with full IDE support, type checking, and autocomplete that works the same way it does everywhere else in your codebase.
The Actual Lesson Here
Wasp’s story isn’t about one framework’s mistake. It’s about the persistent temptation in developer tooling to invent your own syntax. The reasoning always sounds compelling: a purpose-built language can be more expressive, more constrained, more “correct” than adapting an existing one. Technically, that’s often true.
But ecosystems win. The “embedded DSL in TypeScript” pattern — used by Effect.ts, Zod, and Drizzle ORM — has proven this. You get most of the expressiveness of a custom language with zero tooling overhead, because TypeScript’s type system is powerful enough to enforce your constraints without a custom parser. Wasp is now joining that pattern rather than fighting it.
If you looked at Wasp before and dismissed it because of the custom language, that objection is gone. The framework offers a compelling middle ground for JavaScript teams: more structure than Next.js or Remix, less lock-in than a PaaS, and a genuine reduction in the boilerplate that makes full-stack JS projects painful to start. It took five years and $5M to get here. The destination was worth it.
