5 Jahre und 5 Millionen Dollar an Lehren: Eine neue Programmiersprache für die Webentwicklung zu bauen, war ein Fehler | Wasp

• Das aus Y Combinator hervorgegangene Full-Stack-Web-Framework Wasp hat bekannt gegeben, dass es nach 5 Jahren den Versuch aufgibt, eine eigene DSL-basierte Sprache zu entwickeln, und zu TypeScript wechselt
• Mit dem Ziel eines „Rails/Laravel für JS“ gestartet, auf React, Node.js und Prisma aufbauend und mit einer Struktur, in der App-Spezifikationen deklarativ beschrieben werden, wurden insgesamt mehr als 5 Millionen US-Dollar an Finanzierung eingesammelt
• Das Suffix „lang“ wurde als Ersatzsprache für JavaScript missverstanden, und der Aufwand für IDE-Support und den Aufbau eines Tooling-Ökosystems war deutlich größer als erwartet
• Der eigentliche Kernwert lag nicht in der neuen Sprache selbst, sondern darin, zur Compile-Zeit eine High-Level-Spezifikation der gesamten Full-Stack-App beizubehalten
• In der kommenden Launch Week soll das TypeScript SDK als Standardschnittstelle offiziell veröffentlicht werden, bei unverändertem Innenleben

---

Hintergrund: Warum wollte man eine neue Sprache bauen?

• Wasp wurde 2021 von Zwillingsbrüdern gegründet, durchlief Y Combinator und sammelte insgesamt mehr als 5 Millionen US-Dollar Finanzierung ein
• Die frühe Idee war ein „universelles Framework“, das mit jedem Stack funktionieren kann, und dafür hielt man eine neue Sprache für notwendig
• Das Ziel war, ähnlich wie Terraform für Cloud-Infrastruktur, dieselbe Abstraktion für den Web-App-Stack bereitzustellen

Ermüdung durch Stack-Wechsel und zufällige Komplexität

• Früher reichte es, sich für Spring Boot, Django oder Rails zu entscheiden, und Authentifizierung, Routing und State-Management waren als Paket gelöst
• Heute müssen React, Redux, Webpack, Express, Passport, Sequelize usw. selbst kombiniert und miteinander verbunden werden
• Dadurch fließt mehr Zeit in das Management des Stacks als in die Business-Logik; definiert wird das als „accidental complexity“

Das Konzept einer Struktur, die man „nur einmal deklarieren“ muss

• Gedacht war an eine Form, Anforderungen wie „Ich möchte Google- und GitHub-Login nutzen“, „Die Route /profile darf nur von authentifizierten Nutzern aufgerufen werden“ oder „Führe jeden Tag um 17 Uhr einen Cron-Job aus“ als implementierungsunabhängige Spezifikation (specification) auszudrücken
• Beispielhafte Form
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• Die Architektur sollte nicht den bestehenden Stack ersetzen, sondern die Logik in React und Node.js belassen und nur das zentrale Backbone separat halten
• Die Kernerkenntnis: Die Web-App-Domäne (Pages, Routen, API, Datenmodelle) ändert sich kaum, aber die Implementierungsmethoden ändern sich schnell

Warum fiel die Wahl auf eine neue Sprache statt auf eine bestehende?

• Es gab zwei Gründe, die neue Sprache von Grund auf selbst zu entwerfen
  • Vollständige Kontrolle über die Syntax, um Boilerplate zu minimieren
  • Ausrichtung auf runtime-agnostische Tools — z. B. Teile der Logik in Node.js, datenintensive Teile in Python
• Zwar gab es früh Feedback, lieber ein eingebettetes DSL auf TypeScript-Basis zu verwenden, doch das wurde damals abgelehnt, weil es wie ein Verrat an der Vision wirkte
• Die Entscheidung, Wasp als eigenständige Sprache zu veröffentlichen, erschien als stärkere Abgrenzung gegenüber sprachgebundenen Frameworks wie Rails oder Django
• Die Gründer räumen offen ein, dass sie Haskell-Fans waren und die Entwicklung von Sprache und Compiler an sich reizvoll fanden

Marktreaktion: Die Idee wurde geliebt, die Sprache musste man aushalten

• Etwa ein Jahr nach dem Alpha-Release hatte sich eine erste Nutzerschaft gebildet, dazu kamen die Aufnahme bei Y Combinator und eine Pre-Seed-Runde
• Nach der Beta zog die Adoption deutlich an, getrieben vor allem von Ermüdung durch Boilerplate und das Zusammenstecken von Stacks
• Zur selben Zeit tauchten auch Frameworks wie RedwoodJS und BlitzJS als „Rails für JS“ auf
• RedwoodJS war jedoch stark an GraphQL gebunden und BlitzJS eng an Next.js gekoppelt; dass Wasp nicht an eine bestimmte Technologie gefesselt war, erwies sich als Überlebensfaktor

• Ersetzt „wasp-lang“ JavaScript?

  • Wegen des Suffixes „lang“ nahmen Entwickler automatisch an, es handle sich um eine allgemeine Sprache wie Rust oder Java
  • Tatsächlich werden weiterhin 90 % des Codes in React und Node.js geschrieben, aber schon die Positionierung führte zu Missverständnissen
  • Das führte dazu, dass Wasp in die Kategorie „sieht cool aus, ist aber zu früh“ einsortiert wurde

• Ist es mit bestehenden IDEs und Tools kompatibel?

  • Ganz natürlich folgte die Frage, ob man auch noch ein eigenes Ökosystem aufbauen müsse
  • Entwickler wissen sehr genau, wie teuer es ist, einen neuen Standard zu schaffen und ein Ökosystem großzuziehen

• Die Reaktion „Ich will kein Haskell lernen“

  • Der Compiler ist intern zwar in Haskell geschrieben, aber Endnutzer verwenden nur TypeScript
    • Das entspricht derselben Struktur wie bei Prisma, dessen Core in Rust geschrieben ist, oder Terraform HCL, das in Go implementiert ist
  • Das Marketing in die Haskell-Community funktionierte zu gut, wodurch Wasp fälschlich als „Haskell-basierte Sprache“ wahrgenommen wurde
  • Auch die Anzeige „Haskell: 90 %“ in der GitHub-Sprachleiste verstärkte diese falsche Positionierung

• Das Problem des Packaging

  • Entwickler, die es tatsächlich ausprobierten, waren meist zufrieden und bestätigten, dass sich mit React und Node.js schnell ausliefern lässt
  • Am schwierigsten war aber der Schritt von „Ich verstehe nicht, was das ist“ zu „Ich probiere es mal aus“
  • Um die Einstiegshürde zu senken, wurden auf Wasp Open-Source-SaaS-Boilerplate-Starter und darüberliegende Produkte wie ein frühes Lovable aufgebaut
    • Das half bei der Nutzergewinnung, löste aber das Kernproblem nicht

• Der entscheidende Schlag: die Schwierigkeit, IDE-Support zu implementieren

• Die Grenzen zeigten sich nicht bei den Nutzern, sondern im internen Entwicklungsprozess
• Im JS-Ökosystem ist das erwartete Niveau der IDE-Erfahrung sehr hoch, und die Grenze zwischen IDE und Compiler wird immer unschärfer
• Das gesamte Tooling-Ökosystem ist auf Standard-JS-/TS-Frameworks ausgerichtet, weshalb jede andere Sprache sofort an Grenzen stößt
• Zwar wurden ein eigener Language Server und eine VS-Code-Erweiterung entwickelt, doch in Verbindung mit dem Prisma-DSL sowie Referenzen auf React- und Node.js-Dateien blieb man nur bei etwa 80 % des Ziels

Abschied von der eigenen Sprache, Wechsel zu TypeScript

• Die Adoption stieg zwar weiter, doch die Frage „Warum überhaupt eine eigene Sprache?“ verschwand nie; beschrieben wurde das wie Fahren mit angezogener Handbremse
• Am Ende waren die syntaktischen Vorteile der Sprache nicht so entscheidend wie gedacht, und Entwickler akzeptieren bei vertrautem TypeScript gern ein paar zusätzliche Klammern

• Der echte Burggraben (moat) ist nicht die Sprache, sondern das Verständnis der gesamten App zur Compile-Zeit

  • Zu Beginn des Startups wurden „language“ und „specification“ als Synonyme betrachtet, doch was Nutzer wirklich mochten, war der Überblick über die gesamte App über eine High-Level-Spezifikation (main.wasp, jetzt main.wasp.ts)
  • Mit dem Befehl wasp studio lässt sich visualisieren, wie Wasp die App-Struktur zur Compile-Zeit versteht
  • Da AI-Tools und automatische Codegenerierung zunehmen, wird der Wert solcher strukturellen Unterstützung für eine Generation nichttechnischer „vibe-coders“ noch größer
  • Bei diesem Wechsel wird nur das „Frontend“ des Compilers ausgetauscht, also die Art, wie die Spezifikation definiert wird; das Innenleben bleibt gleich

• TypeScript SDK — vom Experiment zum offiziellen Produkt

  • Das experimentelle Preview des TypeScript SDK wurde von vielen neuen Nutzern direkt übernommen; manche haben die Wasp-Sprache nie verwendet
  • Codebeispiele
    • app.page, app.route zum Definieren von Pages und Routen
    • app.query zum Definieren von Queries, inklusive Angabe von Entities
    • app.job zum Definieren asynchroner Jobs, mit PgBoss-Executor und Retry-Optionen
  • Praktische Vorteile des Wechsels
    • Funktioniert in allen Editoren ohne separate Konfiguration
    • Bedingungen, Schleifen und Imports sind möglich — etwa um eigenes file-based routing zu implementieren
    • Die Spezifikation lässt sich leicht auf mehrere Dateien aufteilen
    • Schafft die Grundlage für fortgeschrittene Funktionen wie Full Stack Modules

Rückblick auf das DSL

• Es wird eingeräumt, dass Wasp ohne den DSL-Ansatz selbst wohl nie entstanden wäre
• Der DSL-Ansatz zwang dazu, der Vision einer „Trennung von Spezifikation und Implementierung“ treu zu bleiben
• Das Interesse an möglicher Unterstützung weiterer Sprachen und Runtimes wie Python oder Rust sowie an Architekturdiversifizierung und Optimierung auf Basis eines Compile-Time-Verständnisses der gesamten App bleibt bestehen

Passung zu AI-Agenten

• Während AI einen immer größeren Anteil am Schreiben von Code übernimmt, bevorzugen Entwickler zunehmend Tools mit klarer Struktur und klarer Meinung (opinion)
• Wasp, das den gesamten Full Stack abdeckt und stets Konsistenz garantiert, passt gut zu diesem Trend
• Das steht im selben Kontext wie die Wiederentdeckung „altmodischer“ monolithischer Frameworks wie Django, Rails oder Laravel; Wasp will das dem JS-Ökosystem bieten
• Tatsächlich gibt es Fälle von Entwicklern, die sich nach dem Ausprobieren von 10 Stacks schließlich für Wasp entschieden

Ankündigung des TypeScript-First-Wasp-Launchs

• In den kommenden Wochen soll im Rahmen einer Launch Week das TypeScript SDK als Standardweg zur Nutzung von Wasp offiziell veröffentlicht werden
• Neue Nutzer sollen alle Funktionen von Wasp allein mit TypeScript verwenden können, ohne eine neue Sprache lernen zu müssen