フレームワークの下層:Webのプリミティブを信頼する

フレームワークの依存関係を追加するたびに、そのライブラリがプロジェクトよりも長く存続することに賭けています。一方、Webプラットフォームはブラウザが永続的にサポートすることを約束する機能を提供しています。フレームワークが提供するものとネイティブブラウザAPIが現在処理できるものとの間のギャップは、劇的に縮小しています。

本記事では、フレームワークへの依存を減らす特定のWebプラットフォームプリミティブと、Baselineをガイドとして使用してその準備状況を評価する方法を検証します。

Baseline Web機能の理解

ネイティブブラウザAPIを採用する前に、クロスブラウザサポートを評価するための信頼性の高い方法が必要です。Baselineは、まさにこれを提供します。機能は、Chrome、Edge、Firefox、Safariの最新安定版に搭載されると「新たに利用可能」ステータスに到達します。これらのブラウザ全体で持続的な利用可能期間(約30ヶ月)を経た後、「広く利用可能」になります。

これは、プログレッシブエンハンスメントの決定において重要です。Baselineは、機能をプライマリ実装として使用しても安全な時期と、フォールバック拡張エクスペリエンスとして残すべき時期を示します。

Web機能の現在のクロスブラウザステータスは、https://webstatus.devのWeb Platform Statusダッシュボードで確認できます。このダッシュボードは、Baseline分類とブラウザサポートを一箇所で追跡しています。

フレームワークパターンを置き換えるネイティブブラウザAPI

モーダルとツールチップパターンのためのPopover API

React開発者は、アクセシブルなポップオーバーを構築するために、RadixやHeadless UIなどのライブラリをよく利用します。Popover APIは、現在Baselineの新たに利用可能な機能であり、これをネイティブに処理します:

<button popovertarget="menu">Open Menu</button>
<div id="menu" popover>
  <p>Menu content here</p>
</div>

ブラウザは、フォーカストラップ、ライトディスミス動作、トップレイヤーレンダリングを管理します。基本機能にJavaScriptは不要です。機能検出は簡単です:

if ('popover' in HTMLElement.prototype) {
  // ネイティブポップオーバーを使用
} else {
  // フレームワークソリューションにフォールバック
}

ページアニメーションのためのView Transitions

シングルページアプリケーションが存在する理由の一つは、マルチページナビゲーションが不快に感じられたからです。View Transitions APIは、DOM状態間のスムーズな遷移を可能にすることで、この方程式を変えます:

document.startViewTransition(() => {
  updateDOMSomehow();
});

クロスドキュメント遷移の場合、CSSだけでページをオプトインできます:

@view-transition {
  navigation: auto;
}

View Transitionsファミリーは、現在同一ドキュメント遷移に対してBaselineの新たに利用可能となっています。サポートされていないブラウザは、単にアニメーションをスキップします。

クライアントサイドルーティングのためのNavigation API

React RouterのようなフレームワークルーターがHistory APIが扱いにくかったために存在します。Navigation APIは、ナビゲーションをインターセプトするためのよりクリーンなモデルを提供します:

navigation.addEventListener('navigate', (event) => {
  event.intercept({
    handler() {
      return loadContent(event.destination.url);
    }
  });
});

Navigation APIは現在Baselineの新たに利用可能となっていますが、これは明日すぐにルーターを削除すべきという意味ではありません。これは、ネイティブナビゲーションプリミティブがスタックをシンプル化できる場所、特に軽量な「アプリライク」エクスペリエンスにおいて、評価を開始できることを意味します。

JavaScriptを不要にする最新CSS機能

Anchor Positioning

トリガー要素に対してツールチップやドロップダウンを相対的に配置することは、従来JavaScriptの計算を必要としていました。CSS Anchor Positioningは、これを宣言的に処理します:

.trigger {
  anchor-name: --trigger;
}

.tooltip {
  position: absolute;
  position-anchor: --trigger;
  top: anchor(bottom);
  left: anchor(center);
}

この機能は、まだすべての主要ブラウザでBaseline利用可能ではないため、必要に応じてJavaScriptフォールバックを備えたプログレッシブエンハンスメントとして厳密に使用してください。

Container Queriesと:has()

Container Queriesは広く利用可能であり、コンポーネントがビューポートではなくコンテナのサイズに応答できるようにします。これにより、脆弱なJSレイアウトロジックの多くが不要になります。

:has()セレクタは新たに利用可能であり、以前はJSベースの「親の認識」と状態反映を強制していたパターンを解放します。まだ広く利用可能ではないため、対象オーディエンスによっては注意が必要かもしれませんが、測定されたフォールバックで構築する実際のオプションになりました。

SSR Web ComponentsのためのDeclarative Shadow DOM

Web Componentsのサーバーサイドレンダリングは、以前はハイドレーションの複雑な処理を必要としていました。Declarative Shadow DOMはこれを解決します:

<my-component>
  <template shadowrootmode="open">
    <style>/* scoped styles */</style>
    <slot></slot>
  </template>
</my-component>

Shadow DOMは初期HTMLペイロードに存在します。最初のレンダリングにJavaScript実行は不要です。これは現在新たに利用可能であり、最新ブラウザで使用できますが、特に古いバージョンのSafariではフォールバックが必要な場合があります。

アーキテクチャとしてのプログレッシブエンハンスメント

ここでのパターンは「フレームワークを放棄する」ことではありません。Webプラットフォームプリミティブが、以前は抽象化レイヤーを必要としていた特定の問題を処理できるようになったことを認識することです。

機能検出により、このアプローチが可能になります:

1. ネイティブAPIが存在するかチェック
2. 利用可能な場合は使用
3. 利用できない場合はフレームワークソリューションにフォールバック

これは、長年のプログレッシブエンハンスメントの原則に従い、対応ブラウザのバンドルサイズを削減しながら、すべての場所で機能を維持します。

結論

現在のBaseline機能に対してフレームワークの依存関係を監査してください。Popover API、View Transitions、最新CSS機能、Declarative Shadow DOMは、わずか2年前にはフレームワークコードを正当化していた実際の問題に対処します。

Webプラットフォームはゆっくりと、しかし永続的に進化します。Baselineステータスに到達した機能は、安定した基盤を表しています。その基盤の上に構築し、プラットフォームが本当に不足している場合にのみ補強してください。

FAQ

使用する前にブラウザが特定のネイティブAPIをサポートしているかどうかを確認するにはどうすればよいですか?

関連オブジェクトにプロパティまたはメソッドが存在するかどうかをチェックすることで機能検出を使用します。例えば、Popover APIの場合は'popover' in HTMLElement.prototypeをテストし、View Transitionsの場合は'startViewTransition' in documentをテストします。チェックが失敗した場合は、フレームワークベースのソリューションにフォールバックします。

Baselineの「新たに利用可能」と「広く利用可能」な機能の違いは何ですか?

新たに利用可能とは、Chrome、Edge、Firefox、Safariの最新安定版に機能が搭載されていることを意味します。広く利用可能とは、すべての主要ブラウザで持続期間(約30ヶ月)サポートされていることを意味します。広く利用可能な機能は、本番環境でフォールバックなしで使用するのがより安全です。

ネイティブAPIを優先してフレームワークの依存関係を完全に削除すべきですか?

必ずしもそうではありません。目標は不要な依存関係を減らすことであり、フレームワークを完全に排除することではありません。問題を完全に解決する場合はネイティブAPIを使用しますが、複雑な状態管理、ルーティングロジック、またはブラウザサポートが限られている場合は、フレームワークソリューションを維持してください。

View Transitionsはサーバーレンダリングされたマルチページアプリケーションでどのように機能しますか?

クロスドキュメント遷移の場合、navigationをautoに設定した@view-transitionのCSSルールを追加します。ブラウザは、ページロード間のアニメーションを自動的に処理します。JavaScriptは不要であり、サポートされていないブラウザは、遷移効果なしで通常通りページを読み込みます。