5年と500万ドルの教訓：Web開発向けの新しいプログラミング言語を作ったのは間違いだった | Wasp

• Y Combinator出身のフルスタックWebフレームワーク Wasp が、5年にわたって 独自DSLベースの言語 開発を試みた末にこれを断念し、TypeScriptへ移行する決定を公開
• 「JS版Rails/Laravel」を目指し、React・Node.js・Prisma の上で アプリ仕様を宣言的に記述 する構造として出発し、総額500万ドル超の資金を調達
• lang 接尾辞によって JavaScript 代替言語と誤解され、IDEサポートとツールエコシステム構築 の負担が予想をはるかに上回った
• 実際の中核的価値は新しい言語そのものではなく、コンパイル時に フルスタックアプリ全体の高水準仕様 を維持することにあった
• 今後 Launch Week を通じて TypeScript SDKを標準インターフェース として正式リリース予定で、内部動作はそのまま維持される

---

背景：なぜ新しい言語を作ろうとしたのか

• Wasp は2021年に双子の兄弟が創業し、Y Combinator を経て総額 500万ドル超を調達
• 初期構想は、どのようなスタックでも動作可能な「汎用フレームワーク」であり、そのために新しい言語が必要だと判断
• クラウドインフラ向けの Terraform のように、Webアプリのスタックに対して同じ抽象化を提供することが目標だった

スタック移行疲れと偶発的複雑性

• 以前は Spring Boot、Django、Rails のいずれかを選べば、認証・ルーティング・状態管理が一括で解決された
• 現在は React、Redux、Webpack、Express、Passport、Sequelize などを 自分で組み合わせて接続 しなければならない
• その結果、ビジネスロジックよりもスタック管理に多くの時間を費やすようになり、これを「偶発的複雑性(accidental complexity)」と定義

「一度宣言すればよい」構造の構想

• 「Google・GitHub認証を使いたい」「/profile ルートは認証済みユーザーのみアクセス可能」「毎日午後5時に cron job を実行」といった要件を 実装非依存の仕様(specification) として表現する方式を構想
• 例
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• 既存スタックを置き換えるのではなく、ロジックは React・Node.js に置いたまま、中核バックボーンだけを別に持つ 構造
• 核心的な洞察は、Webアプリのドメイン（ページ、ルート、API、データモデル）はほとんど変わらない一方で、実装手法は急速に変化する という点だった

なぜ既存言語ではなく新しい言語を選んだのか

• 新しい言語をゼロから設計した理由は2つ
  • 文法を完全に制御 し、ボイラープレートを最小化するため
  • ランタイム非依存(runtime-agnostic) のツールを目指したため — 例：一部ロジックは Node.js、データ集約部分は Python
• TypeScript ベースの埋め込み DSL を使おうという初期フィードバックもあったが、当時はそれがビジョンへの裏切りに思えて退けた
• Wasp を独立した言語として公開することが、Rails・Django のような言語依存フレームワークとの差別化 においてより強いメッセージになると判断
• 創業者たちは Haskell 愛好家であり、言語・コンパイラ制作そのものが魅力的な作業だったことも率直に認めている

市場の反応：アイデアは愛されたが、言語は耐えなければならなかった

• アルファ公開から約1年で初期ユーザー層を形成し、Y Combinator 採択とプレシードラウンド調達を実現
• ベータ以降は採用率が本格的に上昇し、ボイラープレート疲れとスタック組み合わせ疲れが大きな要因として作用
• 同時期には RedwoodJS、BlitzJS などの「JS版Rails」フレームワークも登場
• ただし RedwoodJS は GraphQL、BlitzJS は Next.js に強く結びついていたため限界があり、Wasp は特定技術に依存しない点が生存要因となった

• wasp-lang は JavaScript を置き換えるのか？

  • lang 接尾辞のため、開発者は自動的に Rust・Java のような汎用言語だと認識した
  • 実際にはコードの90%を今なお React・Node.js で書くが、ポジショニング自体が誤解を招いた
  • その結果、「かっこよく見えるが時期尚早」という認識カテゴリーに括られてしまった

• 既存IDE・ツールと互換性があるのか

  • 「独自エコシステムまで構築する必要があるのか」という疑問が自然に付いて回った
  • 新しい標準を作り、エコシステムを育てるコストを開発者たちはよく知っている

• 「Haskellは学びたくない」という反応

  • コンパイラ内部は Haskell で書かれているが、最終ユーザーは TypeScript だけを使う
    • Prisma コアが Rust、Terraform HCL が Go で書かれているのと同じ構造
  • Haskell コミュニティ向けマーケティングがあまりにうまく機能し、Wasp が「Haskellベースの言語」として誤って刻み込まれた
  • GitHub リポジトリの「Languages」バーに「Haskell: 90%」と表示されていた点も、誤ったポジショニングを強化した

• パッケージングの問題

  • 実際に使った開発者の多くは満足し、React・Node.js を維持しながら 素早くリリースできる ことを確認
  • しかし「これは何かわからない」から「一度使ってみよう」へ進ませる段階が最も難しかった
  • 参入障壁を下げるため、Wasp の上にオープンソース SaaS ボイラープレート starter や、初期型の Lovable のような 上位製品 を構築
    • ユーザー流入には効果があったが、核心的問題は残った

• 決定打：IDEサポート実装の難しさ

• ユーザーではなく 内部開発プロセスの中で限界に到達
• JSエコシステムで求められる IDE 体験の水準は非常に高く、IDE とコンパイラの境界も曖昧になっている
• ツールエコシステム全体が標準的な JS・TS フレームワークを前提に構築されているため、それ以外の言語は即座に限界 に突き当たる
• 独自 language server と VS Code 拡張を開発したが、Prisma DSL と React・Node.js ファイル参照まで組み合わさり、目標の80%程度にとどまった

独自言語との別れ、TypeScript への移行

• 採用は増え続けていたが、「なぜ独自言語なのか」という問いは消えず、まるで「サイドブレーキを引いたまま走っている感覚」とたとえられた
• 結局、言語がもたらす文法上の利点は思ったほど決定的ではなく、開発者は 慣れ親しんだ TypeScript に括弧が少し増える程度なら進んで受け入れた

• 本当の moat は言語ではなく、コンパイル時のアプリ全体理解

  • 創業初期には「language」と「specification」を同義語として捉えていたが、ユーザーが本当に気に入っていたのは、高水準仕様(main.wasp, 現 main.wasp.ts) を通じたアプリ全体の把握 だった
  • wasp studio コマンドで、コンパイル時に Wasp がアプリ構造をどう認識しているかを可視化できる
  • AIツールとコード自動生成が増える中、非技術的背景を持つ「vibe-coders」世代にとって、このような構造的支援の価値はさらに大きくなっている
  • 今回の移行はコンパイラの「フロントエンド」（仕様定義方式）だけを置き換えるもので、内部動作は同じまま維持 される

• TypeScript SDK — 実験から正式製品へ

  • 実験的プレビューとして導入された TypeScript SDK は、多くの新規ユーザーに即座に採用され、Wasp 言語を一度も使ったことがないケースも出てきた
  • コード例
    • app.page, app.route でページ・ルートを定義
    • app.query でクエリを定義し、entities を指定可能
    • app.job で非同期ジョブを定義し、PgBoss executor、retry オプションをサポート
  • 移行の実質的メリット
    • すべてのエディタで 追加設定なしに動作
    • 条件文、ループ、import が使える — 例：独自の file-based routing を実装可能
    • 仕様を 複数ファイルに分割 しやすい
    • Full Stack Modules のような高度機能の土台を整えられる

DSLについての振り返り

• DSL という方式がなければ、Wasp 自体は存在しなかっただろうという点は認めている
• DSL アプローチは「仕様と実装の分離」というビジョンに忠実であることを強制した
• 今後も Python、Rust など他言語・他ランタイム対応や、コンパイル時のアプリ全体把握を活用した アーキテクチャの多様化・最適化 の可能性への関心は維持している

AIエージェントとの相性

• AIがコード作成の比重を高めるにつれ、開発者は 構造と意見(opinion)が明確なツール を好む傾向を強めている
• フルスタック全体を横断し、常に一貫性を保証する Wasp はこの流れに適している
• Django、Rails、Laravel のような「古い」モノリシックフレームワークが再評価されている現象と同じ文脈で、Wasp はそれを JSエコシステムに提供することを目指している
• 実際に10個のスタックを試した末に Wasp を選んだ開発者の事例もある

TypeScript-First Wasp のリリース予告

• 今後数週間以内に Launch Week を通じて TypeScript SDKをWaspの基本的な利用方法 として正式リリース予定
• 新規ユーザーは新しい言語を学ばなくても、TypeScript だけで Wasp の全機能を活用できる