AstroはWebの原点回帰です
(websmith.studio)"Astroは開発者にとって最高のフレームワーク"である
- Astroはコンテンツ中心のWebサイトに最適化された新しいWebフレームワークで、基本的にZero JavaScript方針と優れた性能、簡単な開発体験を提供する
- Island Architectureという独自の方式で必要な部分にだけJavaScriptを適用し、それ以外は高速な静的HTMLとして処理する
- Astroサイトは従来のReactベースと比べて40%以上速い読み込み速度を示し、その結果SEO、ユーザー体験、コンバージョン率などの実質的な利点を提供する
- 他のフレームワークと異なり、データロジックとフロントエンドコンポーネントが明確に分離されており、React・Vueなどさまざまなフレームワークと混在して使える
- ただし、SPAや複雑な状態管理、大規模なルーティングが必要な場合には、Next.jsなど既存のフレームワークのほうが適していることもある
Astroとは何か
- Astroは2021年に登場したWebフレームワークで、複雑なアプリのための既存のJSフレームワークとは異なり、コンテンツ中心サイトに焦点を当てて設計されている
- 基本哲学は**「コンテンツ優先、サーバー優先、デフォルトはZero JavaScript」**であり、ツール群も直感的で使いやすい点が強みである
Island Architecture
- Astroは**"Island Architecture"**という概念を導入し、ページ全体ではなく必要な一部にだけJavaScriptを適用する
- ブログ記事のように大半がテキストのページはHTMLだけでレンダリングされ、コメントやカルーセルなど相互作用が必要な部分だけJSを読み込む
- そのおかげでページは非常に高速で軽量になる
実際の性能と効果
- Astroベースのサイトは従来型のReactフレームワークより40%以上高速に読み込まれることが記録されている
- こうした性能改善は検索エンジン順位、ユーザー満足度、コンバージョン率といったビジネス成果につながる
- 低速なデバイスや低速ネットワーク環境では、速度差がさらに大きく体感される
開発者体験(Developer Experience)
- プロジェクトセットアップは簡単で、"Houston"という親切なセットアップ支援ツールが案内してくれる
- Astroコンポーネントではビルド時にのみ実行されるロジック（例: データフェッチ、API呼び出しなど）が利用できる
- 複雑な状態管理、ライフサイクル、フックを気にすることなく、必要なときだけクライアント側JSを活用できる
さまざまなフレームワークとの互換性
- React、Vueなど主要なフレームワークをAstroと自由に組み合わせて使える
- 例: 管理ダッシュボードはReact、データ可視化はVue、残りはAstroで構成できる
「ちゃんと使える」便利機能
- Markdownをコンポーネントのように直接インポートして活用できる
- TypeScript、Sass、画像最適化、ホットモジュールリプレースなどモダンなビルドパイプラインをサポート
- 静的サイト/SSR/混合レンダリングをすべて選択でき、プロジェクトの性質に合わせて柔軟に適用できる
Astroが輝く領域
- マーケティングサイト、ブログ、eコマースカタログ、ポートフォリオなどコンテンツ中心サイトで卓越した性能を発揮する
- 複雑なクライアント状態管理が不要な環境で理想的である
トレードオフ
- SPA、複雑なルーティング、コンポーネント間の状態共有が重要なプロジェクトには、Next.jsなど他のフレームワークのほうが適している
- エコシステム規模はまだ小さく、ファイルベースルーティングが大規模プロジェクトでは制約に感じられることもある
すばやく始める方法
- npm create astro@latest my-site
- 必要に応じて npx astro add react などでフレームワークを追加
- src/pages/ にページ、src/components/ にコンポーネントを追加して開発を始める
Astroの意義
- 近年のJSフレームワークがますます複雑になるなか、AstroはWebの基本（高速でアクセシブルなコンテンツ中心体験）へ立ち返りつつ、開発のしやすさも保証する
- 「高速なサイトを標準とし、必要な場所にだけインタラクティブ性を追加し、好きなフレームワークを自由に使う」という設計思想が開発者を満足させる
- ブログからeコマースまで、コンテンツ中心のプロジェクトにはAstroを積極的に勧められる
1件のコメント
Hacker Newsの意見
従来のWebフレームワークは常にページ全体をJavaScriptで「ハイドレーション」していた。たとえば単純なブログ記事にインタラクティブなウィジェットが1つあるだけでも、全体がJavaScriptで処理されていた。一方Astroはデフォルトで静的HTMLを使い、必要な部分だけを「JavaScriptアイランド」として動作させる。以前はこうしたやり方を「プログレッシブエンハンスメント(progressive enhancement)」あるいは単に「Webページ」と呼んでいて、これがWebサイト制作の標準だった。その後SPAが登場して、プログレッシブエンハンスメントは次第に使われなくなった。今は「JavaScriptアイランド」と呼ばれているが、結局は昔のやり方に戻っただけ。興味のある新人Web開発者には プログレッシブエンハンスメントの概念 を勧めたい
新しいツールの機能説明を聞いて、昔からやっていたことと同じだと勘違いする人は多い。でもAstroの本当の価値は、さまざまなJavaScriptフレームワークと連携しつつ、HTMLの一部のサブツリーだけをそれぞれ処理できる点にある。このとき初期状態は文字列としてレンダリングされ、クライアント側では事前取得したデータでハイドレーションされる。React/Svelte/Solid/Vueのようなフレームワークをページの一部だけに使いたい、かつデータをサーバーで先に読み込んでおきたい場合に価値を発揮する。ただしこの方式は「プログレッシブエンハンスメント」ではない。ハイドレーション前のHTMLが正しく動作する必要はなく、たとえば
<form>がJavaScriptなしで動かなくてもよい。こうした細部こそ、皮肉に構えるのではなく好奇心を持って見ないと気づけない点だ完全に同意。Astroは素晴らしいツールだが、いちばん難しかったのは2010年以降に入ってきた開発者たちがWebの仕組みを説明するために作った各種用語を理解することだった
新しい概念ではないが、今のやり方のほうがずっと洗練されている感じがする。昔はPHPとjQueryでインタラクティブなWebを作っていて、ReactやSPAが登場する前の時代だった。今振り返るとアーキテクチャ的には昔の方式のほうが優雅だったが、当時はデバッグやDXが本当にひどかった。PHPでフロントエンドをデバッグしていた時間には二度と戻りたくない。SPAは複雑なダッシュボードやインタラクティブなアプリでは今でも用途がある。Astroはサーバーコードとクライアントコードを一か所で管理でき、区別も明確なので、わざわざPHPでパースしてJSに渡す必要がなく、DXが大きく改善される
AJAXと呼んでいた時代を思い出す。完全に流れを見失った感じがする
初期のWebフレームワークは、ステートレスなWebサイトとサーバーレンダリングについて本当に正しい方向性を持っていたと思う
個人的にはAstroを強く勧めたい。最初は「htmlとcssにinclude機能を足しただけのツール」だと思っていたが、個人サイトとMatrix Conferenceサイトのリニューアルで使ってみたところ、本当に手間なく使えて楽しかった
Astroの主な利点:
Astroがhtmlとcss中心で必要なときにだけjsを追加するものなら、ファイルディレクトリに直接 .html、.css、.js を作って配布しても同じ体験なのではないか。むしろそのほうが開発時オーバーヘッドや不要なbloatがなく、もっと速いのではという疑問がある。また、CSSのインライン化が実際に性能上の大きな問題だったことはない。数百のWebサイトの経験でもCSSがボトルネックだったことはほとんどなく、実際にはネットワークが問題だった
ただ一つ惜しかったのは、ルーティングが複雑になるほど抽象化が急速に増えて、かえって混乱したこと。複雑さは必ず friction を伴うので、最終的には別の方法を選んだ
「htmlとcssにinclude機能」が必要なら、nginxのような一般的なWebサーバーでサーバーサイドインクルードを有効にして使えばよい。20年以上安定していて、ほとんど保守も要らないソリューションだ。テンプレートエンジンのような追加のセキュリティリスクもなく、冗長性は防ぎつつ、バックエンド脆弱性を心配せず純粋なインクルードだけができる
20年間ずっとデータ/バックエンドをやっていて、フロントエンドのプロジェクトのために戻ってきたが、Reactで苦労した末にAstro+Svelteへ切り替えて本当にうまくいった。HTML/CSS中心なのでコード構造が予測しやすくきれいで、React経験のある開発者にフロントエンドを引き継いだときも、ほぼすぐ適応できた
「従来のフレームワーク」という表現をSPA/Virtual DOMフレームワークの意味で使っているのを見て、世代差を感じる。BackboneやjQueryのようなものこそ本当の伝統的Webフレームワークで、まさにブログ記事の説明どおりに動いていた
「伝統」というのは結局いつ生まれたか次第だと思う。自分にとって伝統的インターネットとは56kモデム、vbulletinフォーラム、GTA:VCのMOD、IRCなどで、もっと上の世代にはBBSが、もっと若い世代にはDiscordが「伝統的」インターネットなのだろう。政治にも似た現象があって、みんな自分が若かった頃が良かったと思いがちだ
Backboneは pure SPA 向けにクライアントMVCを志向していた記憶がある
Astro、NextJSなどのSSRフレームワークが、SvelteKitのような動的パスを持つ静的ページをサポートしない理由が気になる。たとえば /todos/[todoId] のようなページは、NextJSではそもそも static bundle に入れられない。一方SvelteKitは 404.html を使うことで、実際には404でありながらCloudflareやモバイルWebView環境でも完全に動作する。こうした機能は、特にモバイルWebView向けのバンドルでは非常に便利だ
部分的には同意するが、この設計には欠点もある。/todos/123 のようなURLをSPAでハードリロードすると、実際のサーバーにそのファイルがあるかをリクエストし、なければ404が返る。そのため404ページ側でクライアントルーティングを使って再度データを読み込み処理しなければならず、これはnginxなどのHTTPサーバー設定が必須になる。つまり純粋な静的ファイルだけでは不可能。またHTTP仕様上、ブラウザキャッシュは404レスポンスを決して保存しない。だからハードリロードやブックマーク時にはキャッシュを絶対に使えない。こうした設定が負担なら、クエリパラメータを使って /todo?id=123 のように処理するほうがむしろ良いと思う
自分が誤解しているのかもしれないが、NextやAstroの static build でも動的ルーティング/ページを実装したことがある。CMSとしてcontentfulやstoryblokを使ったとき、エディタが自由にルートとコンポーネントを作れるようにして、[...slug] パターンで全ルートをカバーした。getStaticPaths 関数を使ってすべてのページを事前生成した。ISR/ISPオプションを有効にすると、ビルド時に分からなかったページも動的にプリレンダーされる。Nextでは dynamic routes、Astroでは dynamic pages と呼ばれている
参考: Next dynamic routes, Astro dynamic pages
もしかすると自分の理解違いかもしれないが、Astroの
getStaticPaths関数が求めている機能をサポートしているように見える参考
自分も静的デプロイが好きなので参考までに言うと、NextJSでも 静的パラメータ生成 をサポートしている
Astroやさまざまなフレームワークを完全に理解しているわけではないが、Astroの server islands が求めている機能に近いかどうか、一度見てみることを勧める
フロントエンドの議論自体があまりに混乱していると感じる。記事で言っていることも結局は「ブラウザをHMIとして使うのか、アプリケーションランタイムとして使うのか」に帰着する。だが議論の大半は「新鮮だ」「速く読み込まれる」といった曖昧な主張ばかりだ。フレームワークをブランドのように宣伝する雰囲気が、ファッション業界とあまりにも似ていると思う
ファッション業界こそ、フロントエンドフレームワークの議論を説明する最高の比喩だと思う。「content-driven」「server-first」のような主張を技術的に厳密に検討することはほとんどない
「速く読み込まれる」が幻想だと言うのは理解できない。実際に重要な要素だ
最近、医療機関のWebサイトをAstroで作ったが、以前Wordpressで作っていた時よりずっと簡単で、Netlifyのような場所に無料でホスティングできるのでハッキングの心配もしなくてよかった。gitベースのシンプルなCMSまで作って、クライアントが自分でコンテンツを修正できるようにもした。Web開発は本当に大きく進歩したと感じる
それは知人に頼まれて作ったのか、それとも医療機関のWebサイト制作案件はどうやって取っているのか気になる
NetlifyはVercelより帯域料金が高いので注意したほうがいい
Astro最大の利点は、ReactやVueのような他フレームワークへの依存なしに、HTMLやWeb Componentだけで作業できる点だ。しかしAstroもNext、Nuxtと同様にSSR、ISR、SSG、ミドルウェアをサポートしている
差別化要素としてはアイランドアーキテクチャがあり、これによってマイクロフロントエンドを実装できる
たとえば1つの企業内で複数のチームがそれぞれ決済、カート、商品ページを作っていても、1つのページに統合して適用でき、レンダリング方式も直接制御できる。グローバル状態も共有できるので、各チームが独立してエンドツーエンドの責任を持ちながら、パートごとに開発・デプロイできる
ただし、こうした構造は大規模プロジェクトでこそ必要なソリューションだ。すべてのチームがReactを各自バラバラに使えば複数バージョンが混在するが、Astroのようにアーキテクチャで分離すればその問題を解決できる
個人的にこれがWebを完全に変えるかは確信していない。Next/Nuxtからフレームワーク依存を取り除き、アイランドアーキテクチャを加えた程度という印象だ。それでも一度使ってみることは勧めたい
React/Vueから離れてweb-componentへ移行したい、あるいはNext/Nuxtを置き換えたいなら、段階的にAstroを活用できるので勧められる
自分にとってAstroはあらゆる状況で完璧というわけではない。オフラインレンダリングだけが必要な場面なら、わざわざJavaScriptを無理に使う理由はなかった
アイランドアーキテクチャにも限界があり、ビルド結果が過度にインライン化されることも多い
正直、Astroの hype はViteのおかげの部分が大きいと思う。Viteは本当に最高だ
Next.jsをReactの標準フレームワークとして勧めないでほしい。フロントエンドにはもっと批判的思考が必要だ。Remix(React Router v7)やTanStackのほうがずっと良い代替だ
自分も同意する。Next.jsにポテンシャルがあったのは確かだが、Vercelが関与してからかなり後退したと感じる。v10から使っていて、v13の混乱期からv15まで経験したが、かなり失望した。ReactとNext.jsは変化のスピードが速すぎて追いかけられず、本当に必要そうな変化よりも、変化のための変化のほうが多いように感じる
React自体をデフォルトフレームワークとして勧めることすらやめたい。フロントエンド開発にはHTML/CSS/JSのほうがずっと良いと思う
Remix/React Router v7は正しい方向性だと思う。特にRemixがpreactを使い、Web標準中心に向かうなら、より堅実なWebサイト制作のやり方が戻ってくると期待している。ただしRemixからRR7へ移る移行はあまりスムーズではなく、プロジェクトを書き直さなければならなかった
Webの基本原則は今でも有効だと思う。PHP、Spring、Quarkus、ASP.NET MVCを使う開発者の立場では、JSフレームワーク中心のWeb開発環境がどれほど大変になっているか実感しにくいかもしれない。流行主導の業界の空気のせいで、基本に立ち返るのは簡単ではないと感じる