投稿者: cum38898

  • Interop 2023は、互換性改善を“重点領域と調査領域”に分けて前進させた

    Interop 2023は、互換性改善を“重点領域と調査領域”に分けて前進させた

    Mozilla HacksのAnnouncing Interop 2023を読みました。Interopは、各ブラウザベンダーが同じWeb標準を同じように実装できているかを、公開テストとダッシュボードで継続的に見ていく取り組みです。

    この記事で印象的なのは、互換性を「なんとなく大事なこと」として語るのではなく、web-platform-testswpt.fyiのダッシュボードに寄せて、改善対象を測れる形にしている点です。Firefoxだけを良くする話ではなく、Gecko、WebKit、Blinkがそろって通る状態を目標に置いているところに、Webらしい健全さがあります。

    記事の要点

    • Interop 2023は、Apple、Bocoup、Google、Igalia、Microsoft、Mozillaなどが参加するブラウザ互換性改善プロジェクトです。
    • 対象は「Focus areas」と「Investigations」に分かれます。前者は仕様とテストが整っていてスコア化できる領域、後者はテスト基盤や仕様整理から始める必要がある領域です。
    • CSSでは、Flexbox、Grid、Subgridを継続しつつ、Container Queriesや:has()のような新しい機能も対象に入っています。
    • Webアプリ寄りの領域では、Web Components、OffscreenCanvas、WebCodecsが取り上げられています。UI部品化、グラフィックス、動画処理といった実装差が体験差になりやすい領域です。
    • Web Compatibilityの領域では、仕様単位ではなく、実際にサイトが壊れている事例をもとにテストを選んでいるのが特徴です。

    参照リンクから見えたこと

    記事中のリンクも1世代分確認しました。Interop 2023 READMEでは重点領域が整理され、State of CSS 2022はCSSまわりの開発者ニーズを補助線として使われています。MDNのContainer Queries:has()Web ComponentsOffscreenCanvasWebCodecsを並べて見ると、Interop 2023は「CSSの書きやすさ」と「Webアプリの表現力」を同時に押し上げようとしていたことが分かります。

    また、前年のInterop 2022の振り返りを読むと、Viewport UnitsやCascade Layers、Web Compatibilityで実際にスコアが改善した流れが説明されています。Interop 2023は、その成功を受けて、より複雑な領域にも測定と合意形成を広げる年だったと言えそうです。

    気づき

    今回の気づきは、Interopの価値が「今年直すリスト」だけではなく、「まだ測れない問題を、将来測れる問題へ変換する仕組み」にあることです。Focus areasだけならテストの点数競争に見えますが、Investigationsを併設することで、モバイルやアクセシビリティのようにテスト基盤から作る必要がある領域も、次の改善候補として扱えるようになります。

    あわせて読みたいリンク

  • UniFFIのRust-JS bindingsは、Firefoxの共有コンポーネント戦略をDesktopまで広げる鍵だった

    UniFFIのRust-JS bindingsは、Firefoxの共有コンポーネント戦略をDesktopまで広げる鍵だった

    Mozilla Hacksの「Autogenerating Rust-JS bindings with UniFFI」を読みました。Firefox Syncチームが、Rustで書いた共有コンポーネントをFirefox DesktopのJavaScriptからも使えるようにするため、UniFFIにJavaScriptバインディング生成を加えた話です。

    記事の要点

    Mozillaは以前から、履歴、ログイン、同期といった機能を各プラットフォームごとの実装から、Rustで書いた共通のコアへ寄せる方針を進めていました。AndroidではKotlin、iOSではSwiftのラッパーを使えますが、手書きラッパーは時間がかかるだけでなく、深刻なバグやクラッシュの原因にもなります。そこで生まれたのが、Rustライブラリ向けに外部言語バインディングを自動生成するUniFFIです。

    当初のUniFFIはKotlinとSwiftを支えていましたが、Firefox Desktopのフロントエンドを動かすJavaScriptには届いていませんでした。Firefox 105でUniFFIによるJavaScriptバインディング生成が入ったことで、同じRustコンポーネントをDesktop、Android、iOSの3系統で共有する道が開けた、というのがこの記事の中心です。

    参照先も確認したこと

    元記事から、2019年のRust FFI戦略の記事UniFFIのユーザーガイド、ADR、過去のC++/WebIDL実装PR、FFIの説明、js-ctypes、FirefoxのWeb IDL bindingsドキュメント、MDNのWeb WorkersとPromise、GleanGeckoViewも確認しました。

    UniFFIの現在のドキュメントでは、Rustライブラリに対して外部言語バインディングを自動生成し、複数プラットフォーム向けのビジネスロジックを1つのRustライブラリへまとめるための道具だと説明されています。記事で出てくるWebIDL bindingsの仕組みも、Firefox内部のC++/GeckoコードとJavaScript APIをつなぐ生成基盤として位置づけられています。

    気づき

    今回の気づきは、Rustで共通化する価値は「コアが安全になる」だけでは完結しないという点です。コアがRustでも、各プラットフォームとの境界を手書きでつなぐなら、その境界が新しいバグの温床になります。UniFFIはその境界を生成物として管理し、Rustの安全性をアプリ全体の構造に届かせるための仕組みに見えます。

    JavaScript対応で特に面白いのは、FirefoxのフロントエンドJavaScriptではメインスレッドを止められないため、UniFFI呼び出しをPromiseベースの非同期APIに寄せた点です。Rust側のモデルをそのまま押しつけるのではなく、JavaScript側の実行モデルに合わせてAPIを再設計しているところに、実運用の重さがあります。

    2024年のReact Native向けUniFFI記事とあわせて読むと、UniFFIは単なるバインディング生成器ではなく、Rustを共通ロジックの基盤にしながら、各UI/アプリ環境の作法へ橋を架けるプロジェクトだと分かります。Firefox 108でリモートタブ同期エンジンが3プラットフォーム共有になったという成果は、その設計が実際に製品コードへ届いた例として印象的でした。

  • Firefox Developer Edition/Betaの.deb提供は、Linux更新体験を公式経路に近づける一歩

    Firefox Developer Edition/Betaの.deb提供は、Linux更新体験を公式経路に近づける一歩

    Mozilla Hacksの「Firefox Developer Edition and Beta: Try out Mozilla’s .deb package!」を読みました。この記事は、DebianベースのLinuxディストリビューション向けに、Mozilla公式APTリポジトリからFirefox Developer EditionとBetaを.debパッケージとしてインストールできるようになったことを紹介しています。

    記事の要点

    Mozillaはこの少し前にFirefox Nightly向けの.debパッケージを導入しており、今回の記事では対象がDeveloper EditionとBetaにも広がったことが発表されています。従来のバイナリ配布と同じDebian/Ubuntuバージョンに対応し、APTリポジトリを追加することで通常のパッケージ管理と同じ流れでインストール・更新できるようになります。

    記事で挙げられている利点は、コンパイラ最適化による性能、Firefoxのリリースプロセスに統合された素早い更新、セキュリティフラグを有効にした堅牢なバイナリ、アップグレード後も好きなタイミングでFirefoxを再起動できることです。単にファイル形式が.debになるだけでなく、日常的な更新体験まで含めて公式経路に近づける取り組みです。

    参照先も確認したこと

    元記事から、先行するFirefox Nightly向け.debパッケージの記事Firefoxのシステム要件ページRelease Engineering向けのBugzilla報告フォーム、APTリポジトリのhttps://packages.mozilla.org/aptと署名鍵https://packages.mozilla.org/apt/repo-signing-key.gpgを確認しました。

    Nightlyの記事側では、.tar.bz2配布からAPTリポジトリに切り替えることで、Firefox Nightlyを通常のアプリケーションのようにインストール・更新できると説明されています。コメント欄でもAPT鍵の置き場所や将来のStable提供、RPM対応への期待などが議論されており、この配布経路がLinuxユーザーにとって実務的な関心事だったことが分かります。

    気づき

    今回の気づきは、ブラウザの品質は実行中の機能だけでなく、配布と更新の経路にも強く左右されるという点です。公式APTリポジトリからDeveloper EditionやBetaを入れられるようになると、開発者や早期利用者は新しいビルドを試しやすくなり、フィードバックもFirefoxのリリースサイクルに乗りやすくなります。

    また、2026年に投稿したRPMパッケージの記事とあわせて読むと、MozillaはLinux向け配布を一気に置き換えるのではなく、Nightly、Beta/Developer Edition、RPM系へと段階的に広げていることが見えてきます。パッケージ形式ごとに利用者の期待やディストリビューション文化が違うため、公式配布を整えるには技術だけでなく運用上の信頼も積み上げる必要があります。

    この.deb記事は短い発表ですが、Linux上のFirefoxを「手動で展開するバイナリ」から「システムの更新機構に参加するアプリケーション」へ近づける節目として読むと、見た目以上に意味のある更新だと感じました。

  • Interop 2024は、互換性を“測れる改善”にする年次プロジェクトだった

    Interop 2024は、互換性を“測れる改善”にする年次プロジェクトだった

    Mozilla Hacksの「Announcing Interop 2024」を読みました。Interop Projectは、ブラウザベンダーが共通の重点領域を選び、web-platform-testsと公開ダッシュボードで互換性改善を追跡する取り組みです。この記事は、Interop 2023の成果を振り返りつつ、2024年の重点領域を紹介しています。

    記事の要点

    Interop 2023では、参加ブラウザのプレリリース版が対象テストで97%超のスコアに到達し、全エンジンで通るテストの割合も年初の59%から95%へ上がったと説明されています。特に:has()のような開発者からの要望が強い機能を、高い互換性で広げられた点が強調されています。

    2024年版では、Popover API、CSS Nesting、Accessibilityなどが新しい重点領域として挙げられています。Popover APIはツールチップや通知のような前面表示UIを標準の仕組みで扱うためのAPIで、CSS Nestingはプリプロセッサなしで入れ子のCSSを書ける機能です。どちらも「便利な新機能」ですが、ブラウザごとに挙動がずれると開発者の負担が増えるため、Interopの対象に入る意味があります。

    参照先も確認したこと

    元記事から、Interop ProjectInterop 2024 READMEInterop 2024 DashboardMDNのPopover APIMDNのCSS Nesting、Apple WebKit、Google web.dev、Microsoft Edgeなどのパートナー発表も確認しました。

    Interop 2024 READMEを見ると、対象はAccessibility、CSS Nesting、Custom Properties、Declarative Shadow DOM、font-size-adjust、IndexedDB、Layout、Popover、Relative Color Syntax、requestVideoFrameCallback、Scrollbar stylingなど幅広く並んでいます。新機能だけでなく、LayoutのようにFlexbox、Grid、Subgridの残課題をまとめて扱う領域も含まれているのが特徴です。

    気づき

    今回の気づきは、互換性改善は「ブラウザ各社が頑張る」という曖昧な努力ではなく、テストセット、スコア、公開ダッシュボードに落とし込むことで初めて継続的なプロジェクトになるという点です。Interopは、標準化や実装差分という見えにくい問題を、開発者コミュニティからも追える形に変換しています。

    また、Interop 2024ではAccessibilityの扱いが印象的です。2023年の調査活動でテスト基盤を増やした結果、2024年には重点領域として扱えるようになっています。つまり、すぐに測れない領域はまず測れるようにし、次の年の改善対象に引き上げる流れが作られています。

    2025年版や2026年版とあわせて読むと、Interopは単年のキャンペーンではなく、Webプラットフォームの差分を毎年少しずつ減らしていく運用の仕組みだと分かります。新しいAPIを早い段階からそろえることと、既存機能の細かな違いを直すことを同じ枠組みで扱っている点が、このプロジェクトの強さだと感じました。

  • Option Soupは、ビルドフラグの組み合わせが本番クラッシュを生む怖さを教えてくれる

    Option Soupは、ビルドフラグの組み合わせが本番クラッシュを生む怖さを教えてくれる

    Mozilla Hacksの「Option Soup: the subtle pitfalls of combining compiler flags」を読みました。Firefox 120 Betaで発生したLinux向けクラッシュを入口に、配布パッケージのビルド設定、C++標準ライブラリ、ELFのシンボル解決まで掘っていく技術調査の記事です。

    記事の要点

    最初に見えていた現象は、WebGLページを開いたときにstd::locale::operator=周辺でクラッシュするというものでした。一見するとWebGLやANGLEの問題に見えますが、問題のコードはstd::ostringstreamstd::locale::classic()を設定するだけの普通のC++コードです。

    調査を進めると、Ubuntu 18.04 LTS向けのFirefox Betaパッケージでlibstdc++が静的リンクされていることが分かります。古い環境に新しいC++ランタイムを持ち込むための現実的な工夫でしたが、Firefox側では-Bsymbolic-functionsも使われていました。この組み合わせにより、関数シンボルと変数シンボルの解決のされ方がずれ、std::localeの初期化状態がモジュール間で食い違う状況が生まれた、というのが記事の核心です。

    参照先も確認したこと

    元記事から、Bugzillaのクラッシュ報告Firefox Beta PPAUbuntu向けビルドログLaunchpadの関連バグGCC/libstdc++側の議論NixOS側のWebGLクラッシュ報告NixOSの関連PRFirefox configureへの検出追加を確認しました。

    Bugzilla側でも、クラッシュはFirefox Build Systemの問題として扱われ、Firefox 120以降で修正対象になっています。NixOS側の報告でも、Firefox 120でWebGLを使うと落ちる再現手順が共有されており、Mozilla側の調査結果がディストリビューション側の修正にもつながったことが分かります。

    気づき

    今回の気づきは、ビルドフラグは個別には妥当に見えても、組み合わせるとランタイムの前提を壊すことがあるという点です。-static-libstdc++は古いOS向けに新しいC++機能を届けるための手段で、-Bsymbolic-functionsもシンボル解決を制御するための手段です。しかし、それぞれの意図が正しくても、標準ライブラリの内部状態を複数モジュールがどう共有するかという低いレイヤーで矛盾が出ることがあります。

    この話は、Firefoxのような巨大プロジェクトだけの特殊事例ではありません。OS配布、独自ビルド、古い実行環境への対応、静的リンク、最適化フラグの追加は、多くのプロダクトでも起こり得ます。クラッシュがアプリケーションコードの近くに見えても、原因はビルド設定やリンク時の挙動にあるかもしれない、という調査の視野を持つことが大事だと感じました。

    記事タイトルの「Option Soup」はかなり的確です。オプションを足していくほど解決できる問題も増えますが、そのぶん組み合わせの意味を説明できない構成にも近づきます。最終的にFirefox側では、この特定の危険な構成をconfigureで検出する対策が追加されており、再発防止まで含めた読みごたえのある調査記録でした。

  • PuppeteerのWebDriver BiDi対応は、ブラウザ自動化を標準へ戻す転換点だった

    PuppeteerのWebDriver BiDi対応は、ブラウザ自動化を標準へ戻す転換点だった

    Mozilla Hacksの「Puppeteer Support for the Cross-Browser WebDriver BiDi Standard」を読みました。この記事は、Puppeteerが次世代のブラウザ自動化標準であるWebDriver BiDiをサポートし、FirefoxとChromeを同じ標準プロトコルで扱える方向へ進んだことを紹介しています。

    記事の要点

    記事では、Puppeteer v21.6.0以降でFirefoxをWebDriver BiDi経由で起動できることが示されています。使い方としては、puppeteer.launchproduct: 'firefox'protocol: 'webDriverBiDi'を指定する形です。同じwebDriverBiDiプロトコルをChromeでも使える点が、この話の重要な部分です。

    背景には、Firefoxの従来のPuppeteer対応がChrome DevTools Protocol、つまりCDPの部分的な再実装に頼っていたという事情があります。CDPはChrome由来の強力な仕組みですが、ブラウザ横断の標準として設計されたものではありません。記事は、長期的にはWebDriver BiDiがFirefoxのリモート自動化の中心になるという見方を示しています。

    参照先も確認したこと

    元記事から、Puppeteer本体のドキュメントWebDriver BiDi仕様PuppeteerのWebDriver BiDiページChrome DevTools Protocol、Mozilla Hacksのクロスブラウザテスト解説記事、pdf.jsのPuppeteerテスト移行PRChrome for Developers側の記事などを確認しました。

    参照先まで見ると、これは「FirefoxでPuppeteerが動くようになった」という個別対応ではなく、テスト自動化の土台をブラウザ固有APIから標準仕様へ寄せる流れの一部だと分かります。Puppeteerの現在の説明でも、ChromeやFirefoxをDevTools ProtocolまたはWebDriver BiDiで制御するライブラリとして位置づけられています。

    気づき

    今回の気づきは、開発者体験の改善は新機能を足すことだけではなく、既存ツールの入口を標準へそろえることでも進むという点です。Puppeteerのように広く使われているツールがWebDriver BiDiへ対応すると、開発者は「ブラウザごとの自動化の癖」を直接扱う時間を減らせます。

    もちろん、記事の時点ではWebDriver BiDi側に未対応機能もあります。Cookieストア、ネットワークインターセプト、一部のエミュレーションや権限まわりなどにはまだ差分があると説明されています。それでも、pdf.jsのテスト移行のような実例が出ていることから、標準化が机上の話ではなく、実際のテスト基盤を動かしながら進んでいることが見えてきます。

    2024年のPuppeteer Firefox公式対応の記事とあわせて読むと、この2023年の記事はその前段にある重要な節目です。Firefox対応そのものよりも、ブラウザ自動化をCDP依存からWebDriver BiDiという共通の標準へ移していく設計判断として読むと、意味がかなりはっきりします。

  • llamafileの4か月は、ローカルAIを“配布しやすい実行形式”へ育てる時間だった

    llamafileの4か月は、ローカルAIを“配布しやすい実行形式”へ育てる時間だった

    Mozilla Hacksの「Llamafile’s progress, four months in」を読みました。llamafileは、LLMの重みと実行環境を単一ファイルにまとめ、インストールの手間を減らしてローカルで動かしやすくするMozillaのプロジェクトです。この記事は、公開から約4か月でv0.8へ進んだ時点の変化をまとめています。

    記事の要点

    中心にあるのは、ローカルAIを「試せる人だけのもの」から「普通の端末でも扱えるもの」へ近づけるための地味な改善です。tinyBLASによってNVIDIAやAMD GPUの利用を簡単にし、CUDAやROCm SDKの導入負担を減らす方向が示されています。GPUを持たない環境向けには、CPU推論の性能改善が大きく扱われています。

    特に印象的なのは、Justine Tunney氏の詳細記事で説明されている行列演算カーネルの改善です。元記事では、84個の新しい行列乗算カーネルにより、プロンプト評価の性能が前リリース比で大きく伸びたことが紹介されています。Raspberry Pi 5のような小型機でも小さめのモデルを現実的な速度で動かす話が出てくる点は、ローカルAIの射程をかなり広げています。

    参照先も確認したこと

    元記事から、llamafileのGitHubリポジトリllama.cppCPU高速化の詳細記事llama.cppへのPRHugging Faceのllamafile対応モデル検索、Open Interpreter、LangChain、LlamaIndexなどの連携先を確認しました。記事単体では「速くなった」という話に見えますが、参照先まで見ると、llamafileは単なる実行形式ではなく、既存のAI開発ツールに差し込める部品として育てられていることが分かります。

    気づき

    今回の気づきは、ローカルAIの普及にはモデル性能そのものだけでなく、「配れる」「起動できる」「既存コードから差し替えられる」という周辺の摩擦を削ることが同じくらい重要だという点です。OpenAI互換APIサーバーやHugging Faceでのllamafile検索、LangChainやLlamaIndexとの連携は、モデルをローカルで動かすだけでなく、開発者が普段の道具立てを崩さずに試せるようにするための設計に見えます。

    llamafileのv0.8時点の記事は、派手なAIデモというより、ローカルAIを実用の入口へ近づけるための足場づくりの記録として読むと面白いです。モデルの性能競争とは別の場所で、配布形式、ハードウェア対応、API互換性、OSSへの upstream という複数のレイヤーを同時に整えている点が、Mozillaらしい取り組みだと感じました。

  • Mozilla AI Guideは、オープンモデル選びを“勘”から評価手順へ移す

    Mozilla AI Guideは、オープンモデル選びを“勘”から評価手順へ移す

    Mozilla Hacksの「Mozilla AI Guide Launch with Summarization Code Example」を読みました。Mozilla AI Guideの公開紹介と、オープンな要約モデルを使ってテキスト要約を試すコード例をまとめた記事です。

    記事の要点

    Mozilla AI Guideは、AIに新しく入る開発者が基本概念を確認し、言語モデルの選び方を学ぶための入口として紹介されています。AI BasicsやLanguage Models 101では、AI、機械学習、LLMの関係や、人間が判断に関わる考え方などを扱っています。

    記事の中心は、閉じた大規模LLMを最初から使うのではなく、特定のタスクに合うオープンモデルをどう選ぶかです。例として「テキスト要約」を取り上げ、Hugging Faceで要約モデルを探し、Papers With Codeでよく使われるデータセットや評価指標を確認します。CNN/DailyMailデータセットやROUGE指標を見ながら、モデルを比較するための土台を作っていく流れです。

    コード例では、Hugging Face Transformersを使ってGoogleのPegasusモデルを読み込み、MozillaのTrustworthy AIに関するテキストを要約します。その後、max_new_tokens、sampling、temperature、top_k、top_pなどを変えながら、出力の長さや品質の違いを試しています。AI Guide本体では、別モデルとしてBARTを試す流れや、評価結果の見方にも進んでいます。

    気づき

    この記事で大事だと感じたのは、AI開発の最初の作業が「モデルを呼ぶコードを書くこと」ではなく、「そのモデルを選んでよい理由を作ること」だという点です。どのデータで学習され、どの評価指標で比べられ、どのハードウェアで動き、ライセンスやデータ来歴に問題がないか。ここを確認する手順があるだけで、オープンモデル利用はかなり実務に近づきます。AI Guideは、流行のモデル名を追う場所というより、モデル選定を再現可能な判断へ寄せるための足場として読めました。

    参照した記事

  • Firefoxの2023年高速化は、ベンチマークではなく実ユーザー指標で語られている

    Firefoxの2023年高速化は、ベンチマークではなく実ユーザー指標で語られている

    Mozilla Hacksの「Down and to the Right: Firefox Got Faster for Real Users in 2023」を読みました。この記事は、Firefoxの性能改善をベンチマークの点数だけではなく、実際のユーザー環境から集計した匿名のタイミング指標で見ようとしている点が特徴です。

    記事の要点

    記事では、FirefoxがSpeedometer 3の取り組みを通じて性能改善を進めてきた一方で、本当に大事なのはその改善が実ユーザーの体験に届いているかだと説明しています。Firefoxはページ読み込み、応答性、起動などに関する匿名化されたタイミング指標を集めていますが、プライバシーを守りながら集計するため、特定サイトごとの細かな分析には限界もあります。

    まず取り上げられているのがFirst Contentful Paintです。MDNによると、FCPはブラウザがDOM由来の最初のコンテンツを描画し、ページが読み込まれていることをユーザーへ示すタイミングです。記事では、response startからFCPまでの中央値が2023年初めの約250msから10月には約215msへ改善し、ページ読み込みのフィードバックが約15%早くなったと説明されています。

    次に、ページ読み込み中のJavaScript実行時間です。95パーセンタイルで見ると、年初の約1560msから10月には約1260msへ下がり、約300ms、ほぼ20%の改善が見られています。記事では、Speedometer 3に関連する作業がSpiderMonkey JavaScriptエンジンの最適化につながったことが、この改善の大きな要因だと示唆されています。

    さらに、読み込み後の応答性としてkeypress present latencyも紹介されています。これはキー入力から結果が画面に表示されるまでの時間です。95パーセンタイルでは、年の大半で約65msだったものが、Firefox 116と117のリリース後に59ms未満へ下がったとされています。

    気づき

    この記事の気づきは、性能改善の成果を「速くなったはず」では終わらせず、ユーザーが感じるタイミングまで戻して見ていることです。ベンチマークは改善の方向を決める道具として強力ですが、最終的にはFCPや入力応答のような体感に近い指標で確認しないと、仕事の価値が見えにくい。プライバシーを守りながら集計値で判断する制約込みで、実ユーザー指標へ接続しているところが実践的だと感じました。

    参照した記事

  • FirefoxのVue.js高速化は、実利用ベンチマークがJIT最適化を導いた例だ

    FirefoxのVue.js高速化は、実利用ベンチマークがJIT最適化を導いた例だ

    Mozilla Hacksの「Faster Vue.js Execution in Firefox」を読みました。この記事は、FirefoxでVue.jsの実行速度が改善された背景を、Speedometer 3とJavaScriptのProxy最適化という観点から紹介しています。

    記事の要点

    Speedometer 3は、実際のユーザー体験に近い形でブラウザ性能を測るための横断的なベンチマークです。その更新作業の中で、Vue.jsのテストがVue 2からVue 3へ変わったとき、Firefoxで性能課題が見つかりました。原因の中心にあったのが、Vue 3のリアクティビティで使われるJavaScriptのProxyです。

    Proxyは、オブジェクトのプロパティ読み書きなどを横取りして振る舞いを変えられる強力な仕組みです。MDNの解説にもあるように、getやsetなどの操作をhandlerで定義できます。一方で、Proxyは設計上とても汎用的で、JITコンパイラにとっては最適化しづらい対象でもあります。

    Vue公式のリアクティビティ解説では、Vue 3がreactive objectにProxyを使い、プロパティの読み取りで依存関係を追跡し、書き込みで更新を通知する仕組みが示されています。つまり、Vueアプリの重要な実行経路にProxyが入っています。Mozillaはこの利用実態を受けて、特定のcall-siteで出会うProxyの形に合わせ、JIT内で実行できるように最適化しました。この変更はFirefox 118に入り、記事ではVue.jsベンチマークが年間で約40%改善したと説明されています。

    気づき

    面白いのは、最適化の出発点が「仕様としてProxyがある」ことではなく、「Vue 3という実アプリの重要経路でProxyが使われている」ことだった点です。汎用機能を全部速くするのは難しくても、現実の使われ方をベンチマークで捉えれば、安全に特殊化できる範囲が見えてきます。ブラウザ性能改善は、エンジン内部の技術だけでなく、フレームワークの進化をどう観測するかにも左右されるのだと感じました。

    参照した記事