0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

WebViewerで利用するJSフレームワークにはPreactがおすすめ

Posted at

以前、このアドカレで軽量なJSフレームワークのAlpine.jsを紹介しました。
AI花盛りの今年は、Preactの紹介です。

何故Preact?

AIの力を使ってコードを書くのがすっかり当たり前の世界になった今、そのAIが提示するコードの精度は、情報量の多さに比例してるであろう事は間違いないと思います。
例えば、AIに対して"適当なフレームワークでWEBアプリのフロントエンドの雛形を作って"とリクエストすると、多分Reactを使った案が真っ先に提案されるでしょう。それだけ広く支持されているし、エコシステムも確立しています。困った時の解決策も多いです。それだけ情報が多いと当然AIの精度も高くなるはずです。

じゃあReactを使えばいいかと言うと、FileMakerのWebViewerには機能過多で巨大過ぎます。実際FileMakerのアドオンではいくつか使われているようですが、最近のReactはサーバーコンポーネントやキャッシュ戦略を強化しており、バックエンドサーバーとの通信がないWebViewerには無関係な機能満載です。自分がAlpine.jsを使い続けているのも、シンプルにフロントエンドのUIに特化しているからです。
しかしReactの書き心地というか、コンポーネント管理の容易さは、コードが複雑化すればするほど有り難みがある。

そこで試したのがPreact

今年の夏頃にちょっと触ってみたら、書き方はまんまReactです。Reactのコードがそのままです。
Preactの目的に書かれているように、React APIとほとんど互換性があります。Reactのバージョンでいうと17前後に相当するようです。
WebViewerで利用する上では以下の機能があれば十分ですよね?

  • Hooks
    • useState,useEffect,useContextなど
    • use***カスタムフック
  • JSX
    • ほぼReactと同じ書き方です
  • TypeScript
    • Reactと同じくとてもマッチしています。この親和性は重要

Reactが近年強化しているサーバーコンポーネントやキャッシュ戦略はWebViewerでは以下の理由で不要です。

  • データはFileMaker内に既に存在し、クライアント(WebViewer)がそれを直接利用できるため、サーバーコンポーネントのメリット(サーバーサイドでデータ取得とレンダリングを行うことによる高速化)は不要
  • 同じ理由で、通信の最適化やキャッシュ機構を使う必要性がない

そして重量

例えば最小限の'Hello, World'を表示するだけのページを作成したとして、ビルド後の単一のindex.htmlは何バイト程度になるのか?
バンドラーでminifyした後のざっくりとしたサイズですが、
React: 100kb
Preact: 10kb
とおよそ10倍の差があります。
その差の理由はPReactではReactDOMに相当する部分が簡略化されているからのようです。
もちろんざっくりしたものなので、規模が大きくなるとその差は縮まるようですが、相当軽量なのは間違いない。

軽量フロントエンドの必要性

WebViewerの課題は、初回読み込み時のパフォーマンスだと思っています。純粋なWEBブラウザとは当然ですがかなり差があります。個人でできる事は出来るだけ軽量に作る事です。Reactを使いたいのですが、ランタイムが大きいためロード時間に影響が出ます。簡易なものなら気になりませんが、WebViewer内が機能マシマシになってくると結構待たされます。それはクライアントマシンのメモリ不足や貧弱なCPUの場合に顕著です。FileMaker本体と双方向にデータをやり取りしやすくなった今では、例えば初回ロード後に即WebViewerに表示用データを投入するケースや、ロード直後にWebViewerからFileMakerスクリプトを叩くケースがあると思うのですが、0.5秒とかwaitを挟まないと空振りするケースが多いです。対策としてDOM上に関数が確実に配置されたのを確認する処理を挟んだりしていますが、正直面倒です。

できれば生のJavaScriptが良いのは間違いないですが、後々の事を考えると私的には使いずらい。

半年使った感想

夏以降のおよそ半年間、新しく実装するWebViewer内のコードは全てPreactで実装しました。ほぼ毎日のように触っていたと思います。
私は特にReactに精通しているわけではなく、時々使う程度の中途半端な知識ですが、正直React書いているのと全く同じ感覚で扱えます。
何よりAIとの親和性が高く、UIコンポーネント単位で見るとReactのコードがそのまま動くので、かなり精度の高い提示・修正案が返ってきます。そしてテストコードも同じ感覚で実装できます。
あまりよろしくない事ですが、公式ドキュメントを見たのは最初の数日だけだった気がします。Reactの経験があると、それくらい調べる事がないです。この記事を書くにあたって久しぶりに覗きました。

そしてTypeScriptとの相性でしょうか。Alpine.jsはその点が少し煮詰まっていなかったのですが(自分の設定が悪いのか)、React同様PreactもTypeScript Readeyです。
私はTypeScriptも浅い知識しかないので以前は型エラーの解決に時間を食ったりしていましたが、今ではAIが迅速に解決策を提示してくるので、型エラーで時間を潰す事はほぼなくなりました😅

つまり、今ではすっかりお気に入りです。

Preactの認知度

以下、openAI調べ

グローバルでの認知度

  • State of JavaScript 2023では、ランクインしています
  • 世界的にはモバイルファーストのアプリや、制約の多い環境(IoTや低スペック端末向けアプリ)で軽量なフレームワークが求められるケースが多い。PreactはReactの代替として適しており、これが支持の背景にあるそうです

日本でのPreactが話題にならない理由

  • Preactは「Reactより軽量」という特化型フレームワークであるため、パフォーマンスやファイルサイズを極端に気にするプロジェクト以外ではあまり検討されない
  • 日本では、多くのWebアプリが比較的リッチで、初期ロードのパフォーマンスにそこまで厳しい要件が求められないため、Preactの軽量性が大きなアピールポイントにはなりづらい
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?