Y Combinator はこのフレームワークを拒否したが、今では GitHub を乗っ取っている

Y Combinator が私と双子の兄弟に「開発者にとっての聖杯」を追い求めていると言ったとき、私たちは成功するかどうか全く分かりませんでした。現在、 Waspは 15,000 以上の GitHub スターを獲得し、サイド プロジェクトから Fortune 500 のツールまで、何千もの Web アプリを動かしています。

この記事では、JavaScript での Web 開発を簡素化するというアイデアから、JavaScript エコシステムで最も急速に成長しているフルスタック フレームワークの 1 つを構築するまでの流れを紹介します。

ウェブアプリ開発のためのDSLは聖杯であり、多くの人がそれを構築しようとして失敗している。

これは、2020 年 5 月にマティヤ (私の双子の弟) と私がWaspに 2 度目の応募をしたときに Y Combinator から受け取ったフィードバックです。その時点で、私たちは Wasp に 1 年半携わっており、最後の 9 か月はフルタイムで働いていました。私たちは以前の仕事を辞めて、全力で取り組んでいました。

現在、 Wasp は GitHub で 15,000 を超えるスターを獲得しています。さらに重要なのは、 買収されたり収益を生み出すビジネスに成長したサイドプロジェクトから、ベンチャー支援を受けたスタートアップや Fortune 500 企業内で導入された社内ツールまで、あらゆるバックグラウンドの開発者が Wasp を使用して何千もの Webアプリを開発していることです。

Wasp とそれが追求するビジョンを愛するようになった人々がいます。彼らのおかげで、私たちは Wasp に取り組むことを楽しんでいます。Wasp の周りに集まったコミュニティ (Discord には 4,000 人以上の開発者が参加) がなければ、私たちは今日のような状況に近づくことはできなかったでしょう。彼らのために、私たちは約束した聖杯に向かって進み続けます。

私たちの仕事はまだ始まったばかりですが、これまで以上に興奮しています。

Wasp の旅 - GitHub で 0 から 15,000 のスターを獲得するまで

ほとんどの成功物語と同様に、成功は直線的に起こることはめったにありません。通常は、長い「干ばつ」の期間から始まり、ときどき活気の兆しが見られ、その後、物事がうまく噛み合って非常に速く動き始める瞬間があります。私たちも同じことを経験しましたが、次のような感じでした。

Wasp の始まり - 「なぜダメなのか?」

当初、Wasp は単なるアイデア、あるいは「なぜ誰もこれをまだ作っていないのか? 試してみたら何がわかるのか? 」という疑問でした。10 年かけて Web アプリを構築し、あらゆる主要な技術スタック (サーバー上の PHP から Java、Node.js、クライアント上の Backbone、Angular、React まで) を使用した後、私たちは「フレームワーク疲労」、つまり新しいスタックごとに車輪の再発明をするという苦痛を感じていました。

そこで私たちは、それについて考え始め、紙に書き出すことにしました (Google スライド)。こうして Wasp の元々のアイデアが生まれました。つまり、より高レベルの抽象化を提供することで多くの定型句を排除しながらも、十分に柔軟で、特定のスタックやアーキテクチャに厳密に縛られないフレームワークを作成できるかどうかです。

こうやって見ると、本当に聖杯のように思えます。

YCに参加して現実になる

私たちはすでに 1 年前に仕事を辞めており、かなり疲れ果て、コンセプト全体に疑問を抱いていました。初期の段階では一定の支持を得ており、Reddit、Hacker News、Product Hunt から有望なフィードバックを受けていましたが、特に自分たちに課した野心的な要件を満たすフルスタック Web フレームワークを使用可能な状態にするには、どれだけの作業が必要であるかを認識し始めていました。

ついに、3 回目の応募で YC に合格しました。彼らは過去 1 年間の私たちの進歩を追跡しており、コミュニティの盛り上がりを見て、私たちの突飛なアイデアに賭けてみることにしたのです。

Wasp がベータ版以降に突入 - MAGE と OpenSaaS

グラフを見ると、2 つの重要な変曲点がわかります。1 つ目は、2023 年 7 月に Wasp を基盤に使用した GPT SaaS スターターであるMAGEをリリースしたときです (ワンショットの Loveable/Bolt と考えることができます)。これは、機能するフルスタック Web アプリを生成できる最初の LLM 製品の 1 つであり、Wasp に注目が集まりました。

2 つ目の大きな成長のきっかけは、2023 年 12 月に、Wasp 上に構築されたオープンソースの SaaS スターターであるOpenSaaSがリリースされたことです。OpenSaaS は現在、GitHub でほぼ 10,000 個のスターを獲得しています。

私たちは、ほとんどのビルダーが、認証、支払い、管理ダッシュボード、メールの送信、ブログなど、あらゆる SaaS に必要なさまざまな機能をすべて選別して組み合わせることなく、できるだけ早く自分のアイデアに取り組み始めたいと考えていることに気付きました。

そして、私たちが提供したのはまさにこれです。React 、Node.js、Prisma、Wasp をベースにした、100% 無料でオープンソースの高品質な SaaS スターターです。OpenSaaS は、開発者が試してみてフレームワークの有用性に気付くきっかけとなったため、Wasp にとって基本的に「キラー アプリ」となりました。

Open SaaS は、Cursor や WindSurf などのツールとも非常に相性が良いです。Wasp の堅牢な構造と高レベルのプリミティブにより、多くの開発者は、アイデアから数日で本番環境対応のアプリまで SaaS を実現できる理想的な組み合わせとして Wasp を見出しています。

言語/DSL とフレームワーク - Wasp はどちらでしょうか?

上記の例からわかるように、私たちは Wasp を言語、つまり DSL (ドメイン固有言語) と呼んでいました。こうした理由から、私たちは当初、将来的にはあらゆる言語、ライブラリ、アーキテクチャで動作できる抽象化レイヤーを用意することを目指しました。

このため、まず Wasp で定義したアプリの仕様 (ルート、非同期ジョブ、DB 操作など) を分析し、それを React と Node.js で記述した「ネイティブ」コードと組み合わせて、最終的に React/Node.js アプリを生成する独自のコンパイラを導入する必要がありました。これは実質的に、非常に制限がありシンプルではあるものの、独自の言語を発明したことを意味します。

これは当初 Wasp を紹介した方法ですが、これは間違った考え方だとわかりました。Wasp は Laravel、Rails、Next.js と同様に、機能的には Web フレームワークです。Wasp が内部でコンパイラを使用しているという事実は、Wasp にスーパーパワーを与える実装の詳細にすぎません。たとえば、このアプローチのおかげで、 wasp studioコマンドを使用して、データベースからサーバーおよびクライアント コンポーネントまで、アプリ全体のトポロジを簡単に視覚化できます。

1.0への道と次世代JavaScriptフレームワークの構築

これは、Wasp が今日の地位に至るまでの経緯を物語っています。

次は何でしょう? ほぼ 5 年間の開発と皆さんからのフィードバックを経て、Wasp 1.0 がどのようなものになるべきか、かなり明確なイメージができました。簡単に言うと、私たちは最高の開発者エクスペリエンスを備えたフルスタック フレームワークの構築に着手しました。皆さんには製品の構築に集中していただき、スタックと格闘する時間をできるだけ少なくしていただきたいと考えています。

Rails と Laravel が Ruby と PHP にもたらした影響を考えてみてください。私たちは、AI を活用した最新の JS エコシステムに対しても同じことを行っています。

私たちのストーリーをフォローしてサポートするには、 GitHub で Wasp にスターを付け、Discord に参加してください。お会いできるのを楽しみにしています。