5 ans et 5 millions de dollars de leçons : créer un nouveau langage de programmation pour le développement web était une erreur | Wasp

• Wasp, framework web full stack issu de Y Combinator, a annoncé qu’après 5 ans de tentative de développement d’un langage basé sur un DSL maison, il y renonce et passe à TypeScript
• Avec l’ambition d’être le « Rails/Laravel de l’écosystème JS », le projet était parti d’une structure permettant de décrire déclarativement les spécifications d’une application au-dessus de React, Node.js et Prisma, et a levé plus de 5 millions de dollars au total
• Le suffixe « lang » a fait croire à un langage remplaçant JavaScript, et la charge liée au support IDE et à la construction d’un écosystème d’outils s’est révélée bien plus lourde que prévu
• La véritable valeur clé n’était pas le nouveau langage lui-même, mais le fait de conserver à la compilation une spécification de haut niveau sur l’ensemble de l’application full stack
• À venir via une Launch Week : sortie officielle d’un SDK TypeScript comme interface par défaut, tout en conservant le fonctionnement interne existant

---

Contexte : pourquoi vouloir créer un nouveau langage

• Wasp a été fondé en 2021 par des frères jumeaux, est passé par Y Combinator et a levé au total plus de 5 millions de dollars
• L’idée initiale était un « framework universel » capable de fonctionner avec n’importe quelle stack, et l’équipe a estimé qu’un nouveau langage était nécessaire pour y parvenir
• L’objectif était d’offrir à la stack d’applications web le même type d’abstraction que Terraform pour l’infrastructure cloud

Fatigue liée aux changements de stack et complexité accidentelle

• Autrefois, choisir Spring Boot, Django ou Rails suffisait pour régler d’un coup l’authentification, le routage et la gestion d’état
• Aujourd’hui, il faut assembler et relier soi-même React, Redux, Webpack, Express, Passport, Sequelize, etc.
• Résultat : davantage de temps passé à gérer la stack qu’à écrire la logique métier, ce que Wasp qualifie de « complexité accidentelle (accidental complexity) »

Imaginer une structure où « une seule déclaration suffit »

• L’idée était d’exprimer des besoins comme « je veux une authentification Google et GitHub », « la route /profile n’est accessible qu’aux utilisateurs authentifiés » ou « exécuter un cron job tous les jours à 17 h » sous forme de spécifications indépendantes de l’implémentation
• Exemples
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• Il ne s’agissait pas de remplacer la stack existante, mais de garder la logique dans React et Node.js tout en séparant l’ossature centrale
• L’intuition clé : le domaine d’une application web (pages, routes, API, modèles de données) change peu, tandis que les techniques d’implémentation évoluent très vite

Pourquoi choisir un nouveau langage plutôt qu’un langage existant

• Deux raisons ont motivé la conception d’un nouveau langage dès le départ
  • Un contrôle total sur la syntaxe, pour minimiser le boilerplate
  • Une approche d’outillage indépendante du runtime (runtime-agnostic) — par exemple, une partie de la logique en Node.js, des traitements intensifs en Python
• Des retours précoces recommandaient déjà un DSL embarqué basé sur TypeScript, mais l’équipe l’a refusé à l’époque, estimant que cela trahirait sa vision
• Lancer Wasp comme langage indépendant semblait aussi envoyer un message plus fort de différenciation face à des frameworks dépendants d’un langage comme Rails ou Django
• Les fondateurs reconnaissent aussi franchement être passionnés par Haskell, et que créer un langage et un compilateur était en soi un travail séduisant

Réaction du marché : l’idée plaisait, mais il fallait supporter le langage

• Environ un an après la sortie alpha, une première base d’utilisateurs s’était formée, ce qui a aidé Wasp à être accepté chez Y Combinator puis à lever un tour pre-seed
• Après la bêta, l’adoption a vraiment accéléré, portée par la lassitude du boilerplate et de l’assemblage de stack
• À la même époque, des frameworks comme RedwoodJS et BlitzJS, présentés comme des « Rails pour JS », ont aussi émergé
• RedwoodJS restait toutefois fortement lié à GraphQL et BlitzJS à Next.js, alors que Wasp a survécu grâce à son absence de dépendance à une technologie précise

• wasp-lang remplace-t-il JavaScript ?

  • À cause du suffixe « lang », les développeurs l’interprétaient automatiquement comme un langage généraliste à la Rust ou Java
  • En pratique, 90 % du code restait écrit en React et Node.js, mais le positionnement lui-même créait la confusion
  • Cela l’a rangé dans la catégorie des projets perçus comme « intéressants, mais trop en avance sur leur temps »

• Est-ce compatible avec les IDE et outils existants ?

  • La question « faut-il aussi construire tout un écosystème maison ? » revenait naturellement
  • Les développeurs connaissent bien le coût qu’implique la création d’un nouveau standard et de son écosystème

• La réaction « je n’ai pas envie d’apprendre Haskell »

  • Le compilateur interne est écrit en Haskell, mais l’utilisateur final n’emploie que TypeScript
    • C’est la même logique que Prisma Core en Rust ou le HCL de Terraform écrit en Go
  • Le marketing auprès de la communauté Haskell a trop bien marché, au point que Wasp a été perçu à tort comme un « langage basé sur Haskell »
  • Le fait que la barre « Languages » du dépôt GitHub affiche « Haskell: 90% » a encore renforcé ce mauvais positionnement

• Le problème du packaging

  • Les développeurs qui l’essayaient en étaient majoritairement satisfaits, constatant qu’il permettait de sortir plus vite sans abandonner React ni Node.js
  • Mais l’étape la plus difficile était de faire passer les gens de « je ne comprends pas ce que c’est » à « je vais l’essayer »
  • Pour réduire cette friction, l’équipe a construit au-dessus de Wasp des produits open source de plus haut niveau, comme un starter SaaS boilerplate ou une première forme de Lovable
    • Cela a aidé à attirer des utilisateurs, sans résoudre le problème de fond

• Le coup décisif : la difficulté de mettre en place le support IDE

• La limite a été atteinte non pas chez les utilisateurs, mais dans le processus de développement interne
• Dans l’écosystème JS, le niveau d’expérience IDE attendu est très élevé, et la frontière entre IDE et compilateur devient floue
• Comme tout l’écosystème d’outillage repose sur les frameworks JS/TS standard, tout autre langage atteint immédiatement ses limites
• Wasp a bien développé son propre language server et une extension VS Code, mais l’objectif n’a été atteint qu’à environ 80 %, notamment à cause du couplage avec le DSL de Prisma et les références croisées vers des fichiers React et Node.js

Dire adieu au langage maison et passer à TypeScript

• L’adoption continuait de progresser, mais la question « pourquoi un langage maison ? » ne disparaissait jamais, ce que l’équipe compare à conduire avec le frein à main serré
• Au final, les avantages syntaxiques du langage n’étaient pas aussi décisifs que prévu, et les développeurs acceptent volontiers quelques parenthèses de plus dans un TypeScript familier

• Le vrai moat n’est pas le langage, mais la compréhension globale de l’application à la compilation

  • Au début, les fondateurs assimilaient « language » et « specification », mais ce que les utilisateurs appréciaient vraiment, c’était la vision d’ensemble de l’application grâce à une spécification de haut niveau (main.wasp, devenu main.wasp.ts)
  • La commande wasp studio permet de visualiser comment Wasp comprend la structure de l’application au moment de la compilation
  • Avec la montée des outils d’IA et de la génération de code, cette aide structurelle gagne encore en valeur pour une génération de « vibe-coders » sans formation technique
  • Cette transition remplace uniquement le « front-end » du compilateur (la manière de définir la spécification), tout en conservant à l’identique le fonctionnement interne

• SDK TypeScript — d’expérimentation à produit officiel

  • Introduit sous forme de preview expérimentale, le SDK TypeScript a été adopté immédiatement par une grande partie des nouveaux utilisateurs, certains n’ayant jamais utilisé le langage Wasp
  • Exemples de code
    • app.page, app.route pour définir pages et routes
    • app.query pour définir des requêtes, avec possibilité de préciser les entités
    • app.job pour définir des jobs asynchrones, avec exécuteur PgBoss et options de retry
  • Bénéfices concrets de la transition
    • Fonctionne dans tous les éditeurs sans configuration supplémentaire
    • Possibilité d’utiliser conditions, boucles et imports — par exemple pour implémenter son propre file-based routing
    • Il devient facile de découper la spécification en plusieurs fichiers
    • Cela pose les bases de fonctions avancées comme les Full Stack Modules

Retour d’expérience sur le DSL

• L’équipe reconnaît que sans cette approche DSL, Wasp lui-même n’aurait probablement jamais existé
• L’approche DSL a forcé le projet à rester fidèle à sa vision de « séparer spécification et implémentation »
• L’intérêt demeure pour une prise en charge future d’autres langages et runtimes, comme Python ou Rust, ainsi que pour les possibilités de diversification et d’optimisation architecturales fondées sur cette compréhension globale de l’application à la compilation

Compatibilité avec les agents IA

• À mesure que l’IA prend une place plus importante dans l’écriture du code, les développeurs tendent à préférer des outils à la structure claire et aux opinions affirmées
• Wasp, qui couvre l’ensemble du full stack et garantit en permanence la cohérence, est bien adapté à cette tendance
• C’est le même mouvement qui remet en lumière des frameworks monolithiques « à l’ancienne » comme Django, Rails ou Laravel ; Wasp veut apporter cela à l’écosystème JS
• Il existe d’ailleurs des cas de développeurs ayant essayé 10 stacks avant de choisir Wasp

Annonce du lancement d’un Wasp orienté TypeScript

• Dans les prochaines semaines, une Launch Week doit officialiser le SDK TypeScript comme mode d’utilisation par défaut de Wasp
• Les nouveaux utilisateurs pourront exploiter toutes les fonctionnalités de Wasp uniquement avec TypeScript, sans avoir à apprendre un nouveau langage