常に進化するウェブ開発の世界では、プレーンな JavaScript と React 、 Vue 、 Svelte などの人気フレームワークの利点をめぐる熱い議論が再燃しています。この議論の中心は「 Writing JavaScript Views the Hard Way 」と呼ばれるパターンで、フレームワークが提供する抽象化レイヤーに依存する代わりに、バニラ JavaScript を使用して直接 DOM 操作を行うことを提唱しています。
 |
|---|
| 「 Writing JavaScript Views the Hard Way 」のGitHubリポジトリ。プレーンJavaScriptとフレームワークの議論における重要なプロジェクトを示している |
フレームワークを使わない魅力
コミュニティの多くの開発者は、フレームワークを捨ててプレーン JavaScript アプローチを採用することに熱意を示しています。彼らは、パフォーマンス上の大きな利点、デバッグの容易さ、そしてウェブプラットフォームとのより直接的な接続を挙げています。ある開発者は、 Vite を使用してプレーンな TypeScript でアプリケーションを構築した最近の経験を共有し、直接的なアプローチの利点を見た後、フロントエンドの「ベスト」プラクティスにますます疑問を持つようになったと述べています。この魅力は技術的な利点だけでなく、教育的なメリットにも及んでいます。DOM と直接作業することで、開発者は基礎となるウェブ技術をより深く理解することが求められるからです。
「スケールするかどうかは結論づけられませんが、パフォーマンス面で大きな利点があり、楽しく、多くを学べ、デバッグが簡単で、アーキテクチャの理解が容易であり、このレンダリング/メモ化/その他のテクニックに博士号を取得する必要がないと結論づけることができます。」
「Writing JavaScript Views the Hard Way」の利点
- パフォーマンス：不必要な操作を最小限に抑えた最適に近いパフォーマンス
- 依存関係なし：外部ライブラリのアップグレードや管理が不要
- 移植性：どのフレームワークでも使用可能なコード
- 保守性：予測可能なコード構成のための厳格な規則に従う
- ブラウザ対応：すべてのブラウザと互換性あり（古いブラウザ向けの互換性オプションあり）
- デバッグの容易さ：浅いスタックトレースで問題の追跡が簡単
- 関数型アプローチ：複雑なクラス階層なしのプレーンな関数を使用
真実の源としての DOM
議論の中で浮かび上がった興味深いパターンは、アプリケーションの状態の真実の源として、別々の状態変数を維持するのではなく、 DOM 自体を使用することです。一部の開発者は、 DOM と同期させる必要がある別々の JavaScript 変数を保持する代わりに、ゲッターとセッターを通じて DOM 要素に直接読み書きすることを提唱しています。このアプローチにより、状態を2箇所で維持する必要がなくなりますが、予期せず DOM を変更する可能性のあるブラウザ拡張機能に対する潜在的な脆弱性や、複数の UI コンポーネント間で冗長な状態を処理する際の課題について懸念が生じています。
保守性に関する懸念
Hard Way アプローチはシンプルさを約束していますが、多くの開発者はチーム環境や大規模なアプリケーションでの保守性について懐疑的です。このパターンは強制された構造ではなく、規約に大きく依存しているため、異なるチームメンバーがコードベースに貢献するにつれて一貫性がなくなる可能性があります。あるコメンテーターが指摘したように、「このデザインパターンは規約のみに基づいています。つまり、開発者はいつでも自由に規約から逸脱することができます。」これは、 API とツールを通じて特定のパターンを強制するフレームワークとは対照的です。
状態管理：真の課題
コメントで繰り返されるテーマは、フロントエンド開発における真の難しさは DOM 要素を作成することではなく、状態を管理し、その状態と UI を同期させることだということです。リアクティブフレームワークはまさにこの問題を解決するために存在します。アプリケーションがより複雑になるにつれて、状態が変化したときに UI のどの部分を更新する必要があるかを手動で追跡することはますます困難になります。ある開発者は、「基本的な問題は、ある状態が変化したとき、その状態に依存するすべての UI を更新する必要があり、アプリケーションが大きくなるにつれて、これらの更新関数を手動で維持することが扱いにくくなる」と指摘しました。
「Hard Way」コンポーネントの構造
- テンプレート: HTML構造のために
document.createElement('template')を使用 - クローン関数: テンプレートの新しいインスタンスを作成
- 初期化関数: 以下を含むコンポーネントインスタンスをセットアップ:
- DOM変数（要素への参照）
- 状態変数（データ値）
- DOM更新関数（要素を変更するため）
- 状態更新関数（データを変更するため）
- 更新関数（親からpropsを受け取るため）
セキュリティに関する考慮事項
複数の開発者が、手書きのテンプレート作成アプローチにおける潜在的なセキュリティ脆弱性について懸念を表明しました。テンプレートリテラルを使用して HTML 文字列を生成すると、ユーザー入力が適切にエスケープされていない場合、クロスサイトスクリプティング（XSS）の脆弱性につながる可能性があります。サーバーサイドのサニタイズが役立つ場合もありますが、多くの人は、現代のフレームワークがこれを自動的に処理することでより良い保護を提供すると主張しています。この議論では、特にフレームワーク以前のウェブ開発時代を経験していない開発者が、手動で HTML を生成する際にセキュリティ問題を簡単に引き起こす可能性があることが強調されました。
結論として、Hard Way アプローチは特定のユースケース、特にパフォーマンス、制御、学習機会の面で魅力的な利点を提供しますが、コミュニティはそれが本番環境の大規模なアプリケーションに適しているかどうかについて意見が分かれたままです。この議論は最終的に、長年にわたってウェブ開発を特徴づけてきたシンプルさと構造の間、直接的な制御と抽象化された便宜の間の緊張を反映しています。ブラウザがより強力なネイティブ API を提供し続ける中で、この会話も進化し続けるでしょう。