La lección de 5 años y 5 millones de dólares: fue un error crear un nuevo lenguaje de programación para desarrollo web | Wasp

• Wasp, el framework full-stack web surgido de Y Combinator, anunció que después de 5 años intentando desarrollar un lenguaje propio basado en DSL, abandonará ese enfoque y cambiará a TypeScript
• Nació con la meta de ser el "Rails/Laravel de JS", sobre React, Node.js y Prisma, con una estructura para describir declarativamente la especificación de la app, y consiguió más de 5 millones de dólares en inversión
• El sufijo "lang" hizo que se entendiera erróneamente como un lenguaje que reemplaza JavaScript, y la carga de construir soporte de IDE y un ecosistema de herramientas fue mucho mayor de lo esperado
• El valor central real no estaba en el nuevo lenguaje en sí, sino en mantener en tiempo de compilación una especificación de alto nivel de toda la app full-stack
• Próximamente, mediante un Launch Week, lanzará oficialmente el SDK de TypeScript como interfaz principal, manteniendo intacto el funcionamiento interno

---

Contexto: por qué intentaron crear un nuevo lenguaje

• Wasp fue fundada en 2021 por dos hermanos gemelos, pasó por Y Combinator y levantó más de 5 millones de dólares en inversión
• La idea inicial era un "framework universal" que pudiera funcionar con cualquier stack, y concluyeron que para eso necesitaban un nuevo lenguaje
• El objetivo era ofrecer para el stack de apps web la misma abstracción que Terraform ofrece para la infraestructura en la nube

Fatiga por cambiar de stack y complejidad accidental

• Antes, elegir Spring Boot, Django o Rails resolvía de una vez autenticación, routing y manejo de estado
• Hoy hay que combinar y conectar manualmente React, Redux, Webpack, Express, Passport, Sequelize y más
• Eso hace que se invierta más tiempo en administrar el stack que en la lógica de negocio, algo que definieron como "complejidad accidental (accidental complexity)"

La idea de una estructura de "declararlo una sola vez"

• Imaginaron una forma de expresar requisitos como "quiero usar autenticación con Google y GitHub", "la ruta /profile solo debe ser accesible para usuarios autenticados" o "ejecutar un cron job todos los días a las 5pm" como una especificación independiente de la implementación
• Formato de ejemplo
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• La idea no era reemplazar el stack existente, sino dejar la lógica en React y Node.js y separar solo la columna vertebral central
• La intuición clave: el dominio de una app web (páginas, rutas, API, modelos de datos) casi no cambia, pero las técnicas de implementación evolucionan muy rápido

Por qué eligieron un lenguaje nuevo en vez de uno existente

• Hubo dos razones para diseñar un lenguaje desde cero
  • Control total sobre la sintaxis, minimizando el boilerplate
  • Enfoque en herramientas agnósticas del runtime; por ejemplo, parte de la lógica en Node.js y componentes intensivos en datos en Python
• Al principio recibieron comentarios sugiriendo usar un DSL embebido en TypeScript, pero en ese momento lo rechazaron porque sentían que traicionaba la visión
• Consideraron que lanzar Wasp como lenguaje independiente daba un mensaje más fuerte de diferenciación frente a frameworks dependientes de un lenguaje como Rails o Django
• Los fundadores también reconocen con honestidad que eran entusiastas de Haskell, y que construir lenguajes y compiladores les resultaba atractivo por sí mismo

Reacción del mercado: la idea gustó, pero el lenguaje fue una carga

• Aproximadamente un año después del lanzamiento alpha se formó una base inicial de usuarios, lograron entrar a Y Combinator y levantar una ronda pre-semilla
• Tras la beta, la adopción empezó a crecer de verdad, impulsada por el cansancio del boilerplate y de armar stacks por piezas
• En esa misma época también aparecieron frameworks tipo "Rails para JS" como RedwoodJS y BlitzJS
• Pero RedwoodJS estaba fuertemente acoplado a GraphQL y BlitzJS a Next.js; Wasp sobrevivió en parte por no depender de una tecnología específica

• ¿"wasp-lang" reemplaza a JavaScript?

  • Por el sufijo "lang", muchos desarrolladores lo interpretaban automáticamente como un lenguaje de propósito general al estilo Rust o Java
  • En realidad, el 90% del código seguía escribiéndose en React y Node.js, pero el posicionamiento mismo generaba confusión
  • Eso terminó metiéndolo en la categoría de cosas que "se ven interesantes, pero todavía son prematuras"

• ¿Es compatible con los IDE y herramientas existentes?

  • Naturalmente surgía la duda de si también tendrían que construir un ecosistema propio
  • Los desarrolladores conocen bien el costo de crear un nuevo estándar y hacer crecer su ecosistema

• La reacción de "no quiero aprender Haskell"

  • Aunque el compilador está escrito en Haskell, el usuario final solo usa TypeScript
    • Es la misma estructura que Prisma Core escrito en Rust o Terraform HCL implementado en Go
  • El marketing hacia la comunidad de Haskell funcionó tan bien que Wasp terminó quedando mal etiquetado como un "lenguaje basado en Haskell"
  • Incluso la barra de "Languages" del repositorio en GitHub mostrando "Haskell: 90%" reforzó ese posicionamiento equivocado

• El problema del empaquetado

  • La mayoría de quienes realmente lo probaron quedaron satisfechos al comprobar que podían lanzar rápido sin dejar React ni Node.js
  • Pero el paso más difícil fue lograr que alguien pasara de "no entiendo qué es esto" a "lo voy a probar"
  • Para bajar la barrera de entrada, construyeron sobre Wasp productos superiores como un starter open source de boilerplate SaaS y algo parecido a una versión temprana de Lovable
    • Eso ayudó con la adquisición de usuarios, pero el problema central seguía ahí

• El golpe decisivo: la dificultad de implementar soporte de IDE

• El límite no llegó del lado de los usuarios, sino del proceso interno de desarrollo
• En el ecosistema JS, el nivel de experiencia de IDE que se espera es muy alto, y la frontera entre IDE y compilador se volvió difusa
• Todo el ecosistema de herramientas está construido alrededor de frameworks estándar de JS/TS, así que cualquier otro lenguaje choca enseguida con límites
• Desarrollaron su propio language server y una extensión para VS Code, pero al combinar además el DSL de Prisma y referencias a archivos de React y Node.js, solo lograron alrededor del 80% de lo que buscaban

Despedida del lenguaje propio y cambio a TypeScript

• Aunque la adopción seguía creciendo, la pregunta de "por qué un lenguaje propio" nunca desapareció; lo comparan con "manejar con el freno de mano puesto"
• Al final, las ventajas sintácticas del lenguaje no eran tan decisivas como pensaban, y los desarrolladores aceptan sin problema unas cuantas llaves extra si pueden quedarse en TypeScript, que ya conocen

• El verdadero moat no era el lenguaje, sino la comprensión de toda la app en compilación

  • Al principio de la empresa veían "language" y "specification" como sinónimos, pero lo que realmente les gustaba a los usuarios era poder entender toda la app a través de una especificación de alto nivel (main.wasp, ahora main.wasp.ts)
  • Con el comando wasp studio se puede visualizar cómo Wasp entiende la estructura de la app en tiempo de compilación
  • A medida que crecen las herramientas de IA y la generación automática de código, este tipo de soporte estructural gana más valor para una generación de "vibe-coders" sin formación técnica tradicional
  • En esta transición solo cambia el "frontend" del compilador, es decir, la forma de definir la especificación; el funcionamiento interno se mantiene igual

• TypeScript SDK: de experimento a producto oficial

  • El SDK de TypeScript, introducido como preview experimental, fue adoptado de inmediato por muchos usuarios nuevos, incluso algunos que nunca usaron el lenguaje Wasp
  • Ejemplos de código
    • app.page, app.route para definir páginas y rutas
    • app.query para definir queries, con posibilidad de especificar entities
    • app.job para definir jobs asíncronos, con soporte para PgBoss executor y opciones de retry
  • Ventajas prácticas del cambio
    • Funciona en todos los editores sin configuración adicional
    • Permite usar condicionales, bucles e imports; por ejemplo, implementar su propio file-based routing
    • Facilita dividir la especificación en varios archivos
    • Sienta las bases para funciones avanzadas como Full Stack Modules

Reflexión sobre el DSL

• Reconocen que sin el enfoque DSL, probablemente Wasp ni siquiera habría existido
• El enfoque DSL los obligó a mantenerse fieles a la visión de "separar especificación e implementación"
• Siguen interesados en soportar otros lenguajes y runtimes como Python o Rust, y en aprovechar la comprensión completa de la app en compilación para diversificar y optimizar arquitecturas

Encaje con agentes de IA

• A medida que la IA escribe una mayor parte del código, aumenta la preferencia por herramientas con estructura clara y opiniones definidas
• Wasp, al abarcar todo el full-stack y garantizar consistencia constante, encaja bien con esa tendencia
• Es el mismo contexto en el que frameworks monolíticos "anticuados" como Django, Rails y Laravel están siendo revalorizados; Wasp busca ofrecer eso dentro del ecosistema JS
• De hecho, existe el caso de un desarrollador que terminó eligiendo Wasp después de probar 10 stacks distintos

Anuncio del lanzamiento de Wasp con enfoque TypeScript-first

• En las próximas semanas, mediante un Launch Week, lanzarán oficialmente el SDK de TypeScript como la forma predeterminada de usar Wasp
• Los nuevos usuarios podrán aprovechar todas las funciones de Wasp usando solo TypeScript, sin necesidad de aprender un nuevo lenguaje