eコマース企業EtsyのスタッフソフトウェアエンジニアBen Sangster氏は、最近、EtsyがReact v15.6からPreact 10に移行した理由を詳しく説明している。Sangster氏は、ライブラリのサイズの違い以上に、Preactを採用することで、Etsyの大規模なコードベースの移行に伴うリスクが低下したと主張している。PreactはEtsyのフロントエンドチームによってすでに使われていたため、売り手向けのページをPreactに移行することで、断片化されたスタックを維持する必要がなくなる。
Sangster氏は、EtsyがReactからPreactに移行することを次の言葉で説明している。
Preactを使用するために、EtsyのすべてのReact v15.6コードを移行しました。これは大きな勝利でした。移行はv16に移行するよりもはるかに簡単でした（古いコードのリライトやリファクタリングがはるかに少ない）。Preactチームは、プロセス全体を通して素晴らしかったです。
[…]非常にシームレスだったので、移行をフラグの下に置きました。そして、クライアントについては、React v15.6を使った1つのバンドルとPreactを使用した1つのバンドルという文字通りまったく同じものを使えました。ゆっくりと立ち上げ、フラグを使ってSentryのライブラリ固有のエラーを追跡できました。
付随するブログ投稿で、Sangster氏は、Etsyのコードベースの一部を最新バージョンのReactではなくPreactに移行することになった3つの理由を詳細に説明している。
まず、Preactを採用することで、移行のリスクが最も減少した。開発者は、React 16の新機能（エラー境界、フラグメント、ポータル、より優れたエラースタックトレース、カスタムDOM属性、React 16.8のフックなど）を歓迎している。React 16.0のドキュメントには、これらの新機能と引き換えに大きな変更がいくつか記載されている。一方で、一部の開発者は移行の大変さを報告している。React.PropTypesまたはReact.createClassの使い方と、React 16以前の内部の依存は、典型的な移行の問題点である。コンソールのエラーや警告は多くの場合に役に立つが、依存関係の更新は面倒な場合がある。DiscordのMichael Greer氏は次のように述べている。
しかし、すべてのパッケージエラーがそれほど簡単に発見されるわけではなく、ここに本当の大変さがあります。
エラーが発生して、ライブラリまで追跡するのに2日かかりました。皆さんも同じものを見つけるかもしれません。
多くのWebアプリケーションの主要な依存関係にあるルーティングライブラリも、移行の問題を引き起こす可能性がある。Sangster氏は、全体として、Preactでは移行リスクの特性がより優れていることが示されていると説明している。
- PreactはReactとAPI互換性があります。つまり、後日Reactへの移行と互換性がないPreactを使っても変更する必要はありません。
- PreactはReactv15とReactv16の両方との互換性を重視しているため、Preact v10.4.2への移行は非常に簡単で、完了するまでの手順もはるかに少なくて済みます。[…] Preactに移行すれば、更新する必要がなくなるコードがいくつか出てきます。いずれにせよ、移行は実施すべきだが、プロセスは遅く、ややトリッキーな場所でかなりの量のコードをリファクタリングする必要があるでしょう。
- Preactを採用する上で開発者ツールの観点からは、大きな障壁はないようです。
第二に、EtsyのフロントエンドシステムチームはすでにPreactを使用していた。Etsyの至る所でPreactを使用すると、開発者としての活動が楽になる可能性がある。Sangster氏は次のように言っている。
[…]すべてのEtsyに1つのPreact / Reactライブラリのみを使うことにすれば、時間の経過とともに開発者にとって困難なことが大幅に軽減されるでしょう。特に、Web Toolkitのようなツールに対してReactとPreactでサポート/テストを行う必要があると、そのチームや共有ツールやアーキテクチャに取り組んでいる他のチームに多くのオーバーヘッドが加わるでしょう。
第三に、Preactのバンドルサイズ（Preact v10.4.5は4KB）はReactの6分の1である（React v16.13.1はreactとreact-domを加えると38.5KBになる）。
開発者はよく、Webページに載せるJavaScriptを減らす努力をしている。実際に、JavaScriptスクリプトはネットワークからダウンロードし、解析して実行する必要がある。遅延（インタラクションできるようになるまでの時間)）、メモリ、CPU使用率は、通常、JavaScriptの量とともに増加する。ローエンドのモバイルデバイスでは、消費が大きい特性があると、バッテリーの寿命が短くなる可能性がある。
Sangster氏の移行発表のツイートは、多くの開発者の注目を集めた。Axel Rauschmayer博士はPreactにはなかったがReact 16には存在するハードルについて尋ねた。Sangster氏は次のように答えている。
所有していない多くの古いコードと、古いライブラリがたくさんあります。そこには、コードベースにチェックインされ、React v15で動作するように手動で変更されたものも含まれます。React 16にアップグレードすると、APIの問題（特にポータル/レガシーコンテキスト/参照）が発生しました。これには多くの作業が必要となります。 代わりに、Preactに移行し、そのコードを最新のものにリファクタリングすることができました。これにより、ロックステップでアップグレードする必要のあるコンポーネント/ライブラリではなくなり、多くのことを考えやすくなりました。
Sangster氏のブログ投稿には、その理由を説明する多くの技術的詳細が他にも記載されている。Preactは、同じ最新のAPIを持つReactに対して、高速で3kBの代替手段として、それ自体を説明している。PreactはMITライセンスの下でオープンソースである。