ハクソク

世界を動かす技術を、日本語で。

AstroがCloudflareに参加

129日前原文(astro.build)

概要

  • Astro Technology Company が Cloudflare に参加
  • Astroフレームワーク は今後も オープンソース かつ MITライセンス で継続
  • 従業員全員 がCloudflare社員となり、Astro開発に専念
  • 今後も 多様なデプロイ先 に対応し、 ロードマップ も維持
  • Cloudflareの支援で 開発リソース 増加と 集中力向上

Astro Technology Company、Cloudflare参加のお知らせ

  • Astro Technology Company が Cloudflare に加わる決定
  • Astroフレームワーク の採用数が毎年倍増、次期バージョン Astro 6 も間近
  • Cloudflare からの支援により、より多くのリソースを確保し、開発に集中
  • Astro は引き続き オープンソース かつ MITライセンス を維持
  • Astro は今後も 幅広いデプロイターゲット をサポート、Cloudflare専用にはならない方針
  • オープンガバナンス と 現行ロードマップ も継続
  • 全従業員 がCloudflare社員となり、Astro専任で活動

Astro誕生の経緯とこれまでの歩み

  • 2021年、ウェブサイトがアプリケーション化の流れに対する課題意識から Astro 誕生
  • SSR や コード分割、 遅延ロード など複雑な最適化手法への疑問
  • コンテンツ駆動型ウェブサイト 向けフレームワークとしての使命
  • 週あたり100万回近いダウンロード数、 10万人超の開発者 が利用
  • Webflow、 Wix、 Microsoft、 Google など主要企業でも採用実績
  • ビジネス展開 も模索し、資金調達や会社設立を実施
  • ホステッドサービス や 有料プロダクト の導入は期待ほど成果を得られず
  • Astro DB や ECレイヤー などの取り組みは最終的にオープンソース化
  • 有料サービス開発の試行錯誤が 本来のフレームワーク開発 を分散させる要因に

Cloudflareとの連携による再集中

  • Cloudflare CTOのDane との対話から将来像の共有
  • AI時代のフレームワークの在り方 への議論
  • Cloudflare は インフラ、 Astro は フレームワーク の側面から同じビジョンを追求
  • 両社の強みを生かし、 新しいウェブの未来 を目指す体制
  • 事業運営の負担 から解放され、 開発とイノベーション に集中可能

CloudflareとAstroの価値観

  • Cloudflare は Astro をはじめ、 TanStack や Hono 等、優れたオープンソースプロジェクトを支援
  • オープン性の維持 が両社の絶対条件
  • Astro は今後も 無料・オープンソース・MITライセンス で提供
  • オープンガバナンス や コミュニティ参加型ロードマップ も継続
  • プラットフォーム非依存 の方針を堅持し、全てのデプロイ先を引き続きサポート

今後の展望と感謝

  • Cloudflare の支援で、 コンテンツ駆動型ウェブサイト 向け最高のフレームワーク開発に再注力
  • パフォーマンス、 スケール、 信頼性、 エクスペリエンス の向上を追求
  • Astro 6 リリースや 2026年ロードマップ に反映予定
  • これまで支えてくれた 代理店、 企業、 スポンサー、 パートナー、 テーマ作者 への感謝
  • 投資家 や コミュニティ、 Astroユーザー への謝意

Hackerたちの意見

Cloudflareがこの取引で何を得るのか理解できるといいな。この記事は「Astroだけど、誰かが費用を払ってくれる！」って感じで、Astroには素晴らしいことだけどね。

└

開発者とのマインドシェアがCloudflareの得るものだね。

└

https://astro.build/blog/astro-6-beta/ を見ると、「Cloudflare」が記事のあちこちに散りばめられてるのが明らかだよね。

└

彼らは全体のスタックで垂直統合をしようとして、Vercelと競争しようとしてる感じがする。

└

Vercelがオープンソースを買う理由と同じだね…Cloudflareにとって、すべてのAstroサイトにとって素晴らしいデプロイメントオプションになるから、Cloudflareのコアビジネスにも役立つ。例えば、Cloudflareは4月にviteプラグインをリリースして、vite env APIを使うフレームワークがworkerd内で簡単に動作するようにしたんだけど、React Routerだけがそれに対応してた。Next.jsは対応してないし、Sveltekitのサポートを追加するためのドラフトPRは次のメジャーバージョンまで保留中。Astroは3日前にベータ6.0リリースでようやくサポートを追加したばかり。この買収によって、AstroはCloudflareとの互換性を高める将来のアップデートに最初に対応するかもしれない。賢い判断だし、あまり高くなかったんじゃないかな（むしろ人材確保って感じ）。

└

VercelはNext.jsから何を得るの？ただの高額なクラウドインフラのデフォルト統合だよ。

└

https://www.tumblr.com/ourincrediblejourney これはおそらくただの買収目的だね。

└

CF Workers/Pagesのサポートがもっと良くなって、Wranglerとの統合も進むといいな。

└

Astro -> Cloudflareをデフォルトのパブリッシングパイプラインにするんだね。ユーザーが他の選択肢を選ぶかもしれないけど、少しでもCloudflareを使い続ける人がいれば、全体としては勝ちだよね。

└

Next.jsは最新バージョンだとCloudflareでうまく動かないよ。アダプターはあるけど、バグだらけ。方向性もこのまま続く可能性が高いね。 出典: https://omarabid.com/nextjs-vercel 私はCloudflareを使ってて、そこでアプリ（Next.js）を運営してたけど、vite.jsに移行しなきゃいけなかった。だから、これはCloudflareがVercelに対する反応だと思ってる。

└

CloudflareはこれでポジティブなPRを得てるね。最近のCEOのツイッターでの meltdown をみんな忘れちゃうよ。

2021年、Astroはフラストレーションから生まれた。当時のトレンドは、すべてのウェブサイトをアプリケーションとして設計し、ユーザーのブラウザに送信してレンダリングすることだった。そうだったの？まじで、いつかこうなるとは思ってたけど、結局ぐるぐる回ってるだけだよね。結局、同じ人たちがまた同じループを繰り返して、新しいフレームワークを作り出すんだろうな。今の「サーバークライアント」モデルが突然意味をなさなくなって、もちろんサーバーサイドでレンダリングされるべきなのに。なんでこんなことを繰り返さなきゃいけないんだろう？特にウェブ開発ではどうしてこんなに早く起こるんだろう？お互いの歴史や知識は目の前にあるのに、なんでこんな無限ループから抜け出せないんだろう？

└

うーん、「アイランド」がただの「静的ページ上のJavaScriptの塊」じゃない理由がよくわからない。なんか「サーバーサイド言語としてのJavaScript」派の人たちが、他のシステムで何度もやられてきたことを新しいかっこいい名前で繰り返し再発明してるだけな気がする。

└

何か古いものが再び新しくなったと感じるとき、過去の足跡を辿っているだけだと思ってしまうと、その間に得た教訓を見逃すリスクがあるよね。

└

当時のトレンドは、すべてのウェブサイトをアプリケーションとして設計し、ユーザーのブラウザに送信してレンダリングすることだった。これは間違いだ。一部のウェブサイトは、主にクライアント側でレンダリングされる方が良い（私たちはそれを「アプリ」と呼ぶ、地図アプリのように）し、他のものは主にサーバー側でレンダリングされる方が良い（ブログのように）。これは過去も現在も変わらない。

└

個人的には、ウェブには行動の多様性があるのに（ネイティブアプリにはない形で）、開発側は単一文化になっているからだと思う。Gmailを作るならReactは意味があるけど、ほとんど静的なブログを作るならあまり意味がない。でも、前者の方が仕事の機会が多いから（世の中には内部ウェブアプリがたくさんあるし）、みんなが受けるトレーニングコースはReactやアプリ中心の考え方を強調するんだよね。そして、何よりもそれで十分なんだ。動くし、ユーザーもそれでやっていける。開発者体験もBackboneの頃よりは良くなってるし、変化を求める人は少ないよね。

└

もっとひどいことになるよ。あるチームがウェブサイトの特定のスペースを持っていて、あるチームはReactを使い、別のチームはVue、また別のチームはAngularを使うことになる。なぜなら、そのスペースはそのチームが得意な技術だから。Astroはそれを可能にしつつ、すべてを静的コンテンツに変えるんだ。GoogleやYouTubeのような大規模な組織を考えてみて。見た目は小さなことでも、実際には巨大なパイの異なる部分を担当するチームがあるんだ。

└

今、逆のことをするにはどうするのがいいの？すべてのウェブアプリがウェブサイトとして設計されるべきじゃないよね。

Astroのアイデアは好きで、いくつかのウェブサイトで使ったことがあるよ。でも、Astroがいろんなフレームワークをアダプターでサポートすることで複雑さが増すのがちょっと心配だし、将来的にそのウェブサイトがどれだけ安定してメンテナンスしやすいかも気になる。例えば、Astroを使ってSvelteで静的サイトを作っているんだけど、クライアントサイドのインタラクティブなコンポーネントが必要なものもある。AstroがデフォルトでJSを出さず、静的なHTMLだけを出力するのはすごくいいと思うし、インタラクティブなJSコンポーネントが必要なページには、Svelteが比較的小さなクライアントJSを生成してくれる選択肢になる。でも、静的サイト用にAstroとSvelteを組み合わせて使うのは、2025年8月から壊れてるんだ。Svelteで条件付きレンダリングの子コンポーネントを持つと、Astroがそのスタイルを静的出力にバンドルできなくなって、しかもそれが本番環境でだけ起こるのが本当に厄介。astro devを使って全体のサイトを作っても、デプロイしたときに壊れることになる。問題はここにあるよ: https://github.com/withastro/astro/issues/14252 OSSプロジェクトでお金を払ってないから、問題がどれだけ早く解決されるかを文句言うつもりはないし、すべてのフレームワークの統合を把握していないことを責めるつもりもない。ただ、最新のAstroとSvelteでウェブサイトを作りたいだけなんだ。残念ながら、SvelteKitにしておけばよかったなって思ってる。

└

まだプロジェクトで完全に使ったことはないけど、いじるのが好きなプロジェクトの一つだよ。これからも続けられるように資金が得られるのは嬉しい。単一のSPAフレームワークに縛られないオープンソースの素晴らしいプロジェクトだと思う。

└

OSSプロジェクトが1000万ドル以上のVC資金を受け取っている時に文句を言うのは違うよ。その時点で優先順位の問題になるし、重大な問題を明示的に無視することで、オーナーたちは自分たちが何を大事にしているかを示している（利益を得ること、ユーザーを助けることではない）。

└

クライアントサイドのインタラクティビティにalpineを使わなかった理由は何？「Astroでフレームワークプラグインを使う」って道に進んだとき、あまりにも違和感があって、alpineに戻ったらうまくいったよ。

ここでの「リフレッシュ」って実は問題なんだよね。実際のユーザーがいるオープンソースプロジェクトが持続可能なビジネスモデルを見つけられないとき、正直に認めることを美徳として扱う。でも本当の疑問は、なぜ最初からマネタイズが急務だったのかってこと。VCから支援を受けたプロジェクトは、資金調達して成長目標を達成し、5〜7年以内に出口戦略を考える。これは一部のビジネスには合うけど、成熟するのに数十年かかるインフラツールには最悪なモデルだよね。抽出圧力のないプロジェクトと比べてみると：

  • SQLite: 23年の歴史があり、数十億のデバイスを支えてる。VCマネーは一切なし。
  • Linux: 33年の歴史があり、インターネットを動かしてる。コミュニティ資金で運営。
  • Nginx: ゆっくりと成長し、創業者のタイムラインで売却（投資家のタイムラインではない）。 Astroは価値あるものを作ったけど、VCマネーには時計がついてくる。持続可能な収益が現れる前にその時計が切れたとき、買収が唯一の出口になった。これはAstroの失敗じゃなくて、資金調達モデルの特性なんだ。人工的なマネタイズのタイムラインを必要としないインフラの資金調達方法がもっと必要だよ。（開示：私は起業家専用の授業料無料の学校を運営してる... 100%創業者資金で、この抽出圧力を避けるためにね。）
└

Linux: 33 years old, runs the internet, community-funded 夢の中だけだよ。IBMみたいな企業がUNIX開発のコストを削減する手段としてLinuxを選んだおかげで、いろんな重要なプロジェクトがRed-Hat Enterpriseライセンスのおかげで生まれた。今ではIBMの一部でもある。GCC、clang、GNOME、Linuxカーネル、systemd、CUPS、AMD/NVidiaのドライバー、たくさんの大企業の資金が入ってる。 出典: https://en.wikipedia.org/wiki/History_of_Linux 「1998年: IBM、Compaq、Oracleなどの多くの大企業がLinuxをサポートすることを発表。」

└

SQLiteは多分VCマネーを受け取ったことはないと思う。人々は彼らの仕事に対してお金を払ってるからね。Linuxに関わってる多くの人が、Linuxのためにお金を払ってくれる会社で働いてる。Linuxはコミュニティ資金で成り立ってるとは言ってないし、そういうことはないと思う。Nginxは何度か買収されたことがあるから、ある程度の資金注入はあっただろうね。> インフラを資金調達する方法をもっと増やす必要がある。人工的なマネタイズのタイムラインを必要としない方法でね。インフラの資金調達が問題なわけじゃない。VCは特定のタイプの資金調達のためのもので、リスクのあるビジネスがスケールしてお金を稼ぐために必要なんだ。私たちは答えを見つけた：あなたのプロジェクトに全てのお金を失う覚悟のあるVCたち。

└

あなたはLLM生成のコメントを使って、自分の本や偽の大学を宣伝してるの？

└

それは本当に同じような比較じゃないよ。何百万ものものが乗っているコアテクノロジーと比べてるんだから。そこには常にお金があるよ。

└

アンドリュー・ケリーは、問題は営利企業にあると言うだろうね。VCマネーはタイムラインを短くするだけだよ。https://andrewkelley.me/post/why-we-cant-have-nice-software....

└

これは100% AI生成の投稿だね。こんなものがHNに出てくるのは本当にがっかり。学校を宣伝したいなら、せめて自分で投稿を書いてよ。

└

ここにLLMが生成した返信があるよ。見た中では最悪ではないけど、お願いだからプロンプトも投稿して。

この記事にこれが載ってないのは驚きだけど、CloudflareはすべてのドキュメントをAstroのStarlightドキュメントフレームワークに移行してるんだよね。これはCloudflareの機能を優先する方法なんじゃないかな。

https://blog.cloudflare.com/open-source-all-the-way-down-upg...

Astroが大好きで、ブログをそこに移行したんだ（ここでは徐々に改善されていったけど）。会社のウェブサイトも移行したよ（みんな喜んでる）。今の時代、バイブコーディングが主流だから、WYSIWYGのウェブサイトエディタを使う理由はかなり減ったね。うちの会社では、技術的じゃないアシスタントがClaude Codeを使ってウェブサイトを修正したんだ。今回の買収がうまくいくといいな。この素晴らしいフレームワークを失うのは悲しいからね。同時に、Cloudflareにも展開してるから、彼らのビジネスはAstroをクールに保つことだし、そうすればもっと多くの人がCloudflareを使うようになる。ウィンウィンだね！

私は個人のウェブサイト（username.com）にAstroをCloudflareで数年使ってるけど、どちらも本当に素晴らしいよ。両方について良いことを言い尽くせないくらい。私のウェブサイトはPageSpeed/Lighthouseで全て100点だし、これはAstroとCloudflareのパフォーマンス重視のおかげ。私の手柄じゃないよ。主にAstroが絶対必要じゃない限り0 JSを優先して出荷してくれたからで、Cloudflareは静的HTMLを提供するのがすごく得意なんだ。でも、Astroが直面した難しさも理解できる。フレームワークには非常に満足してるけど、私は一度もお金を払ったことがない。提供されていた有料プランは私には響かなかったし、彼らが提供していたものはCloudflareが非常に寛大な無料プランで既に提供していたからね。チームがCloudflareの中で第二の人生を得られて嬉しいよ。何年も無料で素晴らしいソフトウェアを提供してくれた人たちに感謝してる。ありがとう、みんな！

Astroはウェブサイトを作るのに最高の方法だと思ってる（特に得意なタイプのやつね）。チームのために嬉しいし、Cloudflareは働くにはめっちゃクールな場所だよね。これからどんな方向に進化するのか楽しみだな。次のNextになれるチャンスがあると思う。

Cloudflareか他のテック企業がDenoを買ってくれたらいいな。Denoは素晴らしいけど、大きなブランドのスポンサーが足りないんだよね。

自分のSveltekitアプリがCloudflare Pagesで動いてて、AstroアプリがVercelで動いてるのがすごいよね。でも、少なくともこういうサービスがあって、個人プロジェクトを無料で披露できるのは感謝してる。