Next.js の App Router はデフォルトでキャッシュされる設計でリリースされました。一方でデフォルトでキャッシュされることに対して不満を持つ開発者も多かったように思います。このようなフィードバックを受けて、Next.js 15 ではいくつかのキャッシュ戦略が変更されました。さらに現在 canary チャンネルで提供されている dynamicIO フラグを有効にすることで、"use cache" ディレクティブを用いてキャッシュを制御できるようになります。
CSSStyleSheet インターフェースは、JavaScript でスタイルシートを構築し、操作するための API です。CSSStyleSheet() コンストラクターで新しいスタイルシートを作成し、.replaceSync() メソッドでスタイルを適用できます。
@r2wc/react-to-web-component は React コンポーネントを Web Components に変換するためのライブラリです。このライブラリを使用することで、React コンポーネントを任意の HTML 要素として使用することが可能になります。
この発表はすでにアクセシビリティに興味を持っていて、ソフトウェア開発の現場にアクセシビリティを取り入れたい人を対象としています。開発チーム全体でアクセシビリティに意識を持つ状態が理想ですが、全員が詳細な実装を行うのは実際には難しいでしょう。そこで、特に意識をせずともある程度のアクセシビリティを保つ状態にするための施策について紹介いたします。
Svelte は記述量が少なくシンプルなコードで書けることが特徴の 1 つでした。しかし、アプリケーションの規模が大きくなるにつれて学習コストや認知負荷が増加していくという課題が浮上してきました。Svelte v5 で導入される Rune は今までの Svelte のコンセプトを覆し、よりシンプルになることを目指しています。このトークでは Svelte v5 の新機能を通じて Svelte の書き方がどのように変わるのかについて話します。
まずはじめ React に焦点を置き、昨今のフロントエンドでどのようなフレームワークが選択肢にあげられるのかについて紹介します。続いて、技術選定を行う際に、どのようなことを考えるべきかについて話します。最後にこれまで話した点を踏まえて、私が実際に技術選定を行った際にどのような選択をしたのか実践的な内容について触れたいと思います。
OpenTelemetry には Semantic Conventions と呼ばれる規約で service という属性が定義されています。service はメトリックが計装されたアプリケーションの名前やバージョンを表します。特に、service.name と呼ばれる属性の重要性について話します。
Next.js、Remix、SvelteKit といった近年のフレームワークは、JavaScript がなくても動作することを一つの価値として提供しています。例えばSvelteKit のフォームではプログレッシブエンハンスメントとして、JavaScript が利用できる環境ではリッチなユーザー体験を提供しつつ、JavaScript が使えない環境においては HTML のフォームとして振る舞うことでアプリケーションの機能を変わらず提供できます。 React Server Component はサーバー側で HTML に変換されるため、クライアントに JavaScript のコードが配信されることはありません。React Server Component では useState() を使用できないといった制約がありますので、我々開発者は React Server Component の利点を十分に発揮するために、JavaScript を用いた状態管理を行う範囲を狭めることが求められています。このトークでは、CSS の :has() セレクターや、Popover API といった、従来は JavaScript を用いなければ提供できなかった機能を代替する方法を紹介します。
アクセシビリティの改善が正しい行いであることがわかっていたとしても、はじめからチームのタスクとして進めていくことはなかなか難しいでしょう。なぜなら、プロジェクトには他にも新規機能の開発などやるべきことがたくさんあり、優先度がつけられて入念に計画されているはずだからです。この発表では、azukiazusa が Mackerel チームにおいて具体的にどのような手法でアクセシビリティの改善を進めていったかについて話します。
