By ByteBot
After five years of development, $5M in funding, and a custom programming language built from scratch, Wasp’s founders published one of the most honest post-mortems in recent developer tooling history. Their conclusion: building a custom language for web development was a mistake. This week they announced that TypeScript is replacing their proprietary DSL as the primary way to configure Wasp — and the community is not surprised.
What Wasp Built and Why It Mattered
Wasp is a YC-backed full-stack framework that wraps React, Node.js, and Prisma into a batteries-included development experience. The promise was compelling: declare your app’s high-level structure — authentication, routing, background jobs, RPC — and Wasp handles the wiring. Full-stack auth in 8 lines of config. Single-command deployment. End-to-end type safety out of the box.
To make that work, the team built a custom configuration language — a DSL that sat alongside your React and Node code. It was not trying to replace JavaScript. It was meant to abstract away the boilerplate layer, the stuff you’d otherwise copy-paste across every project. The framework grew: 18,000+ GitHub stars, 4,000 Discord members, thousands of shipped apps. The approach worked well enough that people kept building with Wasp despite their reservations about the language. That combination — traction plus friction — made the decision harder than it sounds.
Three Ways the Custom Language Failed
The Wasp team identified three failure modes that compounded over time.
Ecosystem incompatibility. The JavaScript and TypeScript ecosystem is built entirely around standard tooling. The moment you step outside it, you’re building your own IDE support from scratch: a custom language server, VS Code extension, syntax highlighting, autocomplete. Wasp built all of it and still only reached “80% of where we wanted to be” — a ceiling that years of effort couldn’t push past, because Wasp’s DSL embedded Prisma’s schema language and referenced React and Node files in ways that made any custom tooling inherently incomplete.
Developer acquisition friction. “Lang” in the framework’s original name made prospects assume Wasp was trying to replace JavaScript. It wasn’t, but the damage was done before a developer even ran their first command. Feedback was consistent: “I really like what you’re doing with Wasp, but why a custom language?” The problem Wasp solved resonated. The language it used to solve it did not.
Maintenance tax. Building a compiler, language server, and editor tooling for a bespoke language is expensive. Those are engineering resources that could not go to framework features — new integrations, better deploy targets, improved error messages. The custom language created a permanent, compounding opportunity cost.
TypeScript Gravity Is Not Optional
In October 2025, TypeScript overtook Python to become the most-used language on GitHub — the first language shift at the top in over a decade. More than 2.6 million developers contributed to TypeScript projects that month, a 66.6% year-over-year increase. AI coding tools made the gap wider: research found that 94% of errors in LLM-generated code are type-related, which means TypeScript’s type system is becoming more valuable as AI-assisted development expands, not less.
The lesson Wasp learned isn’t that custom languages are inherently bad. HashiCorp built HCL for Terraform and it became one of the most-used configuration languages in infrastructure. But HCL succeeded in a domain where general-purpose languages genuinely fail — declarative, provider-agnostic infrastructure definition. Wasp’s domain was different. TypeScript already handles web app configuration elegantly. Fighting that capability cost more than building on top of it would have.
What Actually Changes for Wasp
The pivot is narrower than it sounds. Wasp itself — the framework, the abstractions, the value proposition — is unchanged. Auth, background jobs, RPC, single-command deployment: all still there. What changes is the configuration surface. Instead of a custom DSL file, you write TypeScript. Every editor works immediately. Conditionals, loops, and imports work natively. Migration is gradual — existing projects can move file by file.
The community response has been positive. Developers who tried the experimental TypeScript SDK often never went back to the DSL. Wasp is running a Launch Week to formally ship the TypeScript SDK as the default, and the reception is what you’d expect when a product finally confirms what its users have been requesting for years.
The Lesson Other Teams Should Take
Wasp’s post-mortem deserves more attention than a typical release announcement. Most startups quietly deprecate a failed technical bet and replace it without saying why. The Wasp team named the failure explicitly, documented the failure modes, and published the reasoning. That’s useful for every engineering team evaluating whether to build a custom configuration language, a specialized DSL, or an alternative scripting layer.
The answer is rarely “no, never.” It is almost always “only if TypeScript cannot do this.” For web app configuration in 2026, TypeScript can. The gravity is not optional, and the Wasp team found out the expensive way that fighting it costs more than it saves.
