静的サイトジェネレータとして、Preactを実務で使ってみた

はじめに

あけましておめでとうございます。イタンジのエンジニアリングマネージャー(以下EM)の田渕です。
つい最近のことですが、EMという役職が新設され、そちらの役職に就任いたしました。

イタンジのEMに求められている役割の中で最も大きいものは、「全社横断での技術的負債の解消」です。
チームをまたいで、様々な方法で技術的負債を少しずつ減らすような活動をしていきます！

その一環として、ITANDI BBというサービス群のLPページをPreactに置き換えました。

動的な要素のないLPページ群がRailsからホスティングされている状態でした。それにより以下のような課題がありました。

このような課題を解決するために、ページの見た目や振る舞いは変えないまま、技術スタックを大幅に変えようという決断をしました。

候補に上がったものは以下の5つのライブラリです。

それぞれについて、簡単な所感を述べていきます。

現状がRailsのページであるため、変更量が最も小さくなる点が魅力でした。

しかし、今後Reactを全社的に多く使っていく流れがあるため、その際に社内共通コンポーネント等の恩恵に預かれなくなりそうです。

実際に開発するデザイナーの意見としても、できることならばReact+CSS modulesで、コンポーネント志向で開発したいようでした。

また、開発があまり活発ではない点も気になりました。

middlemanよりは変更が多くなりそうですが、それでも変更量は小さくなりそうです。そしてmiddlemanよりは開発は活発です。

しかし、会社としてフロントエンドをReactベースで開発していくという流れを考えると、あまり良い選択とは思えなかったです。

今フロントエンドでアツいフレームワークです。

React+CSS modulesで、コンポーネント志向で開発したいという要求にも答えられそうです。

完全に静的なサイトを作るのは、本来のフレームワークの目的とはズレていて、Static HTML Exportという機能はあることにはあるのですが、ドキュメントを見るとadvanced featureの欄に書かれている点が気になりました。

デザイナーからの要求は満たしています。

Gatsbyについてはあまり調べられていないのですが、やや扱いにくい印象を受けました。
GraphQLベースであるので、ライブラリの思想を知るためにはGraphQLが必要になり、やや学習コストが高いように感じました。

Reactそのものではないのですが、ほぼReactと同じように使えるため、要件としては満たしていそうです。

ランタイムの軽さという強みがあるため、最低限のシェアは保たれそうな技術的な筋の良さを感じました。
Pre-renderという機能もあり、静的サイトを作るのにも便利なライブラリのようです。

ただ、純粋なReactではないことは気になる点でした。

Next.js・Gatsby・Preactどれでも良さそうなところだったので、それぞれ少し試してみました。

Preactの環境構築やエコシステムが非常にシンプルだったことと、最悪の場合はPreactで作ったものをReactに移行することが想像以上に容易にできそうであったため、Preactの採用を決めました。

また、LPという保守リスクの比較的小さいところでPreactを使っておくことで、会社としての技術の幅をもたせたいという意図もありました。

先にCI/CDを組みました。デプロイフローはyarn buildしたものをs3にアップロードするだけです。
配信はCloudFrontから行うように設定しました。

ページ自体の移行については、いろいろな人に手伝っていただきながら、地道な置き換え作業を行いました。
全体の工数としては0.5人月程度でした。

当初の課題が全て解決され、デザイナーだけでLPページでの高速なPDCAが回せるような体制になりました。
また、CSS modulesのおかげで開発コスト自体も下がったという声を頂いており、かかった工数はすぐにペイしそうです。

技術選定したときからやや状況も変わってきているのですが、想像よりもNext.jsの流れが来ているため、Next.jsという選択もあったかと思います。
ただ、特定の極限状況でランタイムの軽さからPreactを採用できるかどうかという手札にはなるので、決して悪い選択だったとも思っていません。

今後も色々なアプローチで技術的負債と向き合っていくので、またブログを書こうと思います。