フロントエンドの技術選定で考えること
Frontend Study 用
前提: フロントエンドは式年遷宮が有効である
- DB を持たないため、表層の技術を交換するだけで済む
- JSON API が実質的な分解点になっている
- 近年ではモバイルアプリのために JSON API が切り離されていることが多く、ここの利用者になるだけでよい
- Rails や PHP で ORM ヘルパーにべったりな場合に困難になる(クライアントで同等のバリデーションを再現する必要)
- デザイントレンドと技術トレンドの両方の影響を受けて、非技術要件で再実装の機運が発生する
- 例: レスポンシブ対応
- 例: モバイルアプリとトンマナ合わせるためにマテリアルデザインを採用したい(脱 bootstrap)
- 例: Core WebVitals が始まるからスコアを上げてほしい
- パラダイムが違うものは共存することが難しい
- 例: 暗黙のグローバル変数渡し vs ESM+Webpack
- 例: jQuery vs React
- 例: browserify vs Pure ESM
- UI 仕様はドキュメント化しづらい。要件が定まっていれば同じ仕様で作り直すほうが速いことも多い。
- まあでもここで暗黙の「〜があるって当然だと思ってました」が無限に来る。頑張って向き合う。
- ロックインで得られるパワーもある
- Next.js 型フレームワークを選ぶと、クラサバまたいだ高い最適化が行われる
今日 npm init したとして、およそ 4~5年もてばよいぐらいの時間間隔。もちろんドメイン次第だが…。
フロントエンドの速さとの付き合い方
- GitHub Trend や コミュニティは力
- コミュニティの大きさが、大体のことを解決できる。今はできてないこともそのうちできるようになる。
- 流行りだけでライブラリを決めてはいけないが、閑古鳥が鳴いてるプロジェクトに依存するのは危険
- 大きい企業がスポンサーしてるものを優先的に選ぶ(MS, Google, Facebook)
- バージョンを固定するのは、「安定」ではなく、「リスク」
- ドキュメント: 最新版以外ドキュメントやノウハウが消失するので、問題が発生した時に解けない可能性がある
- 採用: レガシーを放置する組織に魅力がない。最新技術を追いかけられないので、一般的な知識が身につかない。
- セキュリティ: 既知の脆弱性を放置して攻撃面にならないか。npm audit を無視してないか
- 伸びしろがあるものを採用する
- React は 7年目 で全盛
- 筋の良さを見抜けるかどうか、自分の経験次第
ビジネス要件
- パフォーマンスと複雑性: どの程度担保するか
- メンテナンス性: 作り捨てか、継続的な開発か
- セキュリティ:
- そのビジネスドメインがどういう間違いを誘発するか。間違えた際のインパクトがどの程度になるか
- JS が得意でない人がJSを書いた時にXSSを起こさないような補助輪が付いているか
- IE を落とせるか
メンバー構成
- どのフレームワークが得意なメンバーがいるか
- Node.js ツールチェインを使いこなせるメンバーの比率
- CLI がおぼつかない ~ ライブラリ作者
- ある程度任せたとして、アーキテクチャ選定に自走できるか
- Server Side Node.js を運用できるか
- フロントサーバーとして Next, Nuxt を挟む選択肢がある
- Design Engineer が JavaScript を書けるか
- デザインシステムは自作か
- 高い作成コスト
- (ないのが理想だが)特定のフレームワークで書かれるので、フレームワークロックインが発生する
技術選定で何を考えるか
- そのライブラリは分解点が担保されているか？
- そのライブラリの採用でアーキテクチャ全体を歪めてしまわないか
- 例: フレームワークによってデータバインディングされたオブジェクトがシリアライズできるか？
- チームメンバーがスケールものを選択する
- Node.js なら Next / Nuxt などがメンバーの力を活かす
- 例えば Haskell を中心としたチームなら elm や purescript も検討する
- API が Rails PHP 等ならマイクロサービス化できるか検討
- フロントエンドで頑張ることがそのプロジェクトにおいてどれぐらい重要か
- フロントエンドがプロダクト価値において比重が少ないので頑張りたくない => AMP なども選択肢になる
- 技術選定者は課題となりうる点を洗い出して、それを個別に倒す
- 問題が起きたら都度対応する
- すべてにおいて TypeScript との相性
- 堅牢性と同じぐらい、IDE補助の快適性が大事
- tsconfig.json はメンバーのスキルで強くしたり弱くしたりする
フロントエンド筋の磨き方
- たくさんプロジェクトを作る
- 小さいユースケースでたくさん試す
- 自分でちゃんと苦労する
- 例: 2013年の自分「backbone で入力状態に対する冪等性を保証するのがしんどい => React ってやつよくね？」
個人の watch 範囲
Adopt
- TypeScript
- React
- Next.js
- Webpack
- Vercel
- (new) Svelte
- (new) Rollup
Trial
- (new) Vite
- Cloudflare Workers
- Deno
- Tailwind
Assess
- SvelteKit
- Rome
- pnpm
- worker-dom
