5 anos e US$ 5 milhões em lições: criar uma nova linguagem de programação para desenvolvimento web foi um erro | Wasp

• A Wasp, framework full-stack para web surgido da Y Combinator, revelou a decisão de abandonar após 5 anos a tentativa de desenvolver uma linguagem própria baseada em DSL e migrar para TypeScript
• Com a ambição de ser um "Rails/Laravel do JS", começou com uma estrutura que descreve declarativamente a especificação do app sobre React, Node.js e Prisma, levantando mais de US$ 5 milhões em investimentos
• O sufixo "lang" fazia parecer uma linguagem substituta de JavaScript, e o custo de suporte a IDE e construção de um ecossistema de ferramentas foi muito maior do que o previsto
• O valor central real não estava na nova linguagem em si, mas em manter em tempo de compilação uma especificação de alto nível de todo o app full-stack
• Nas próximas semanas, por meio de uma Launch Week, pretende lançar oficialmente o SDK em TypeScript como interface padrão, mantendo o funcionamento interno como está

---

Contexto: por que tentar criar uma nova linguagem

• A Wasp foi fundada em 2021 por irmãos gêmeos, passou pela Y Combinator e captou ao todo mais de US$ 5 milhões
• A ideia inicial era um "framework universal" que pudesse funcionar com qualquer stack, e por isso concluíram que precisariam de uma nova linguagem
• O objetivo era oferecer para a stack de aplicações web a mesma abstração que o Terraform oferece para infraestrutura em nuvem

Fadiga com trocas de stack e complexidade acidental

• No passado, bastava escolher entre Spring Boot, Django ou Rails para resolver de uma vez autenticação, roteamento e gerenciamento de estado
• Hoje é preciso combinar e integrar manualmente React, Redux, Webpack, Express, Passport, Sequelize etc.
• Com isso, gasta-se mais tempo administrando a stack do que escrevendo lógica de negócio, algo que definem como "complexidade acidental (accidental complexity)"

A ideia de uma estrutura em que "basta declarar uma vez"

• Conceberam uma forma de expressar requisitos como "quero usar autenticação do Google e GitHub", "a rota /profile só pode ser acessada por usuários autenticados" e "executar um cron job todos os dias às 17h" como especificações independentes de implementação
• Formato de exemplo
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• Em vez de substituir a stack existente, a proposta era manter a lógica em React e Node.js, e separar apenas a espinha dorsal central
• Insight central: o domínio de apps web (páginas, rotas, APIs, modelos de dados) quase não muda, mas as técnicas de implementação mudam rapidamente

Por que escolher uma nova linguagem em vez de uma existente

• Havia dois motivos para projetar uma nova linguagem do zero
  • Controle total da sintaxe, minimizando boilerplate
  • Orientação a ferramentas agnósticas de runtime — por exemplo, parte da lógica em Node.js e partes intensivas em dados em Python
• Já havia feedback inicial sugerindo um DSL embarcado em TypeScript, mas na época rejeitaram a ideia por parecer uma traição à visão original
• Entenderam que lançar a Wasp como linguagem independente transmitiria uma mensagem mais forte de diferenciação em relação a frameworks dependentes de linguagem, como Rails e Django
• Os fundadores também admitem com sinceridade que eram entusiastas de Haskell, e que criar uma linguagem e um compilador era um trabalho atraente por si só

Reação do mercado: a ideia era amada, mas a linguagem precisava ser suportada

• Cerca de um ano após o lançamento alfa, já havia uma base inicial de usuários, além da aprovação na Y Combinator e da rodada pre-seed
• Depois do beta, a adoção começou a subir de fato, impulsionada pelo cansaço com boilerplate e com a combinação manual de stacks
• No mesmo período, também surgiram frameworks no estilo "Rails do JS" como RedwoodJS e BlitzJS
• Porém, o RedwoodJS era fortemente acoplado a GraphQL e o BlitzJS ao Next.js, o que limitava ambos; no caso da Wasp, o fato de não depender de uma tecnologia específica ajudou na sobrevivência

• O "wasp-lang" substitui o JavaScript?

  • Por causa do sufixo "lang", desenvolvedores automaticamente o percebiam como uma linguagem de propósito geral, como Rust ou Java
  • Na prática, 90% do código ainda era escrito em React e Node.js, mas o posicionamento em si gerava mal-entendidos
  • O resultado foi cair na categoria mental de algo que "parece legal, mas é cedo demais"

• É compatível com IDEs e ferramentas existentes?

  • Naturalmente surgia a dúvida: "preciso construir também um ecossistema próprio?"
  • Desenvolvedores conhecem bem o custo de criar um novo padrão e fazer um ecossistema crescer

• A reação de "não quero aprender Haskell"

  • Embora o compilador interno seja escrito em Haskell, o usuário final só usa TypeScript
    • É a mesma estrutura de o core do Prisma ser escrito em Rust ou o HCL do Terraform em Go
  • O marketing voltado à comunidade Haskell funcionou tão bem que a Wasp acabou sendo equivocadamente percebida como uma "linguagem baseada em Haskell"
  • O fato de a barra "Languages" do repositório no GitHub mostrar "Haskell: 90%" também reforçou esse posicionamento incorreto

• O problema da embalagem

  • A maioria dos desenvolvedores que realmente testou ficou satisfeita e confirmou ser possível lançar rápido mantendo React e Node.js
  • Mas o passo mais difícil era fazer alguém sair do "não entendi o que é isso" para o "vou testar"
  • Para reduzir a barreira de entrada, criaram sobre a Wasp produtos de nível superior, como um starter open source de boilerplate SaaS e algo semelhante a um Lovable inicial
    • Isso ajudou na entrada de usuários, mas o problema central permaneceu

• O golpe decisivo: a dificuldade de implementar suporte a IDE

• O limite foi atingido não do lado dos usuários, mas no processo interno de desenvolvimento
• O nível de experiência com IDE exigido no ecossistema JS é muito alto, e a fronteira entre IDE e compilador está ficando difusa
• Como todo o ecossistema de ferramentas é construído com base em frameworks padrão de JS/TS, qualquer outra linguagem encontra limites imediatamente
• Eles chegaram a desenvolver um language server próprio e uma extensão para VS Code, mas, ao combinar isso com o DSL do Prisma e referências a arquivos React e Node.js, atingiram apenas cerca de 80% do objetivo

Adeus à linguagem própria, transição para TypeScript

• A adoção continuava crescendo, mas a pergunta "por que uma linguagem própria?" nunca desaparecia; eles comparam isso a dirigir com o freio de mão puxado
• No fim, a vantagem sintática da linguagem não era tão decisiva quanto imaginavam, e os desenvolvedores aceitam com tranquilidade usar o TypeScript familiar com alguns parênteses a mais

• O verdadeiro moat não é a linguagem, mas a compreensão do app inteiro em tempo de compilação

  • No início da empresa, tratavam "language" e "specification" como sinônimos, mas o que os usuários realmente gostavam era da visão do app inteiro por meio de uma especificação de alto nível (main.wasp, agora main.wasp.ts)
  • Com o comando wasp studio, é possível visualizar como a Wasp entende a estrutura do app em tempo de compilação
  • À medida que ferramentas de IA e geração automática de código crescem, o valor desse suporte estrutural aumenta ainda mais para a nova geração de "vibe-coders" de perfil não técnico
  • Nesta transição, só muda o "frontend" do compilador (a forma de definir a especificação), enquanto o funcionamento interno permanece igual

• SDK em TypeScript — de experimento a produto oficial

  • O SDK em TypeScript, introduzido como preview experimental, foi adotado de imediato por muitos novos usuários, inclusive casos de pessoas que nunca usaram a linguagem Wasp
  • Exemplos de código
    • app.page, app.route para definir páginas e rotas
    • app.query para definir queries, com possibilidade de especificar entities
    • app.job para definir jobs assíncronos, com suporte a executor PgBoss e opções de retry
  • Benefícios práticos da transição
    • Funciona em qualquer editor sem configuração adicional
    • Permite usar condicionais, loops e imports — por exemplo, para implementar roteamento próprio baseado em arquivos
    • Fica mais fácil dividir a especificação em vários arquivos
    • Abre base para recursos avançados como Full Stack Modules

Reflexão sobre DSL

• Eles reconhecem que, sem a abordagem de DSL, a própria Wasp provavelmente não existiria
• A abordagem de DSL os forçou a permanecer fiéis à visão de "separação entre especificação e implementação"
• Continua existindo interesse em possibilidades futuras como suporte a outras linguagens e runtimes, como Python e Rust, e diversificação/otimização de arquitetura aproveitando a visão completa do app em tempo de compilação

Compatibilidade com agentes de IA

• À medida que a IA aumenta sua participação na escrita de código, cresce também a preferência dos desenvolvedores por ferramentas com estrutura e opinião claras
• A Wasp, por cobrir todo o full-stack e garantir consistência o tempo todo, se encaixa bem nessa tendência
• Isso ocorre no mesmo contexto em que frameworks monolíticos "à moda antiga" como Django, Rails e Laravel voltam a ganhar atenção; a Wasp quer oferecer isso ao ecossistema JS
• Existe inclusive o caso real de um desenvolvedor que tentou 10 stacks antes de escolher a Wasp

Anúncio do lançamento do Wasp TypeScript-First

• Nas próximas semanas, por meio de uma Launch Week, será lançado oficialmente o SDK em TypeScript como forma padrão de usar a Wasp
• Novos usuários poderão usar todos os recursos da Wasp apenas com TypeScript, sem precisar aprender uma nova linguagem