astro.build

支配的なユーザー体験から始める

このページでリンクされている代替手段を候補として使用し、実際に提供する必要がある体験の種類と比較してください。Astroは、ブラウザ側で状態を継続的に管理することより、コンテンツを読む、移動する、比較する、発見することが重要なプロジェクトに最も直接的に適合します。

プロジェクトに最も当てはまる記述を選んでください。

• ページの大部分がHTMLとして動作する必要がある。 静的コンテンツではデフォルトでクライアント側JavaScriptが不要なため、Astroをより重視します。
• インタラクションが複数の明確なコントロールに分かれている。 それらのコントロールが、明確で独立してハイドレーションされるアイランドを形成するかテストします。
• ほぼすべての領域がライブなクライアント状態を共有する。 アイランドの境界がもたらす価値が小さい可能性があるため、アプリケーション中心の候補を慎重に評価します。
• Markdownによる公開に一貫した構造が必要である。 Astroの検証済みでTypeScript対応のコンテンツコレクションと、リンクされた各候補のコンテンツモデルを比較します。
• チームが既存のUIコンポーネントを再利用する必要がある。 すべてのコンポーネントシステムを自由に組み合わせられると考えず、関連するインテグレーション、ランタイムコスト、保守上の期待を確認します。

代表的なページを1つ比較する

リンクされたすべての代替手段で、同じ実際のページと要件を使用してください。スターターテンプレートはツールが動作することを示しますが、そのアーキテクチャが最も難しいコンテンツ、インタラクション、執筆上のニーズに適合するかは明らかにしません。

判断のための質問	収集する証拠
必須コンテンツがブラウザ実行なしで届くか？	配信されたHTMLを調査する
インタラクションを明確に分離できるか？	コンポーネントと共有クライアント状態を整理する
各コントロールはいつ有効化すべきか？	即時、アイドル時、ビューポート基準の読み込みニーズをテストする
コンテンツワークフローを保守できるか？	検証要件を含む実際のコレクションをモデル化する
ブラウザに何が届くか？	コンポーネントコード、ランタイム、メディア、サードパーティスクリプトを確認する
チームが自信を持って運用できるか？	規約、デバッグ、継続的な保守を比較する

インタラクティブなスコアカードを適用する

リンクされた各候補について、すべての基準を非常に適合、実用可能、負担が大きいのいずれかとして評価します。単純に点数を数えるのではなく、プロジェクトに応じて基準に重みを付けてください。

1. 有用なHTMLとして提供されるコンテンツ。
2. インタラクション境界の明確さ。
3. チームが希望するUIアプローチへの対応。
4. 構造化コンテンツと検証。
5. 共有クライアント側状態のコスト。
6. インテグレーションとデプロイの要件。
7. ランタイムの重複と依存関係の保守。
8. 実際のインタラクションパターンにおけるアクセシビリティ。

Astroが候補として残る場合は、静的な記事だけでなく、大規模または要求の厳しいアイランドをテストしてください。リンクされた代替手段が候補として残る場合も、同じメディア、ナビゲーション、サードパーティスクリプト、編集ワークフローを適用し、本番環境の条件を反映した比較にしてください。