https://jp.quora.com/search?q=webシステムの大部分のページはjQueryで、一部の動的なページだけVue.jsといった構成はありですか？
シェアしました。
いいえ、まったくオススメできません。なぜなら、その両者はパラダイムが完全に異なっているからです。
jQuery のような DOM 操作ライブラリでは通常、アドホックに DOM を書き換えていきます。したがって、アプリケーションの状態は、ページそのものに埋め込まれることになります。これには大きな問題があります。
それは、ある瞬間のページの状態が、予測不可能だということです。ページの状態を復元するには、ユーザーの操作履歴を一から辿りなおさなければなりません。少なくとも、そうしなければ「同じであるという保証」がありません。このことは、かつての Web エンジニアたちを大いに苦しめてきました。
その問題を解決したのが、React や Vue のような仮想 DOM を扱うライブラリです。これらのライブラリでは、アプリケーションの全状態を内部データとして保持し、そのデータを青写真として DOM を生成します。
そのため、ある瞬間のページの状態が完全に予測可能になります。そのときの内部データの状態を調べれば、どのようなページが生成されるか一意に決定できるからです。内部データを復元すれば、ページの状態も復元されます。
また、内部状態の変更に制限を設け、一定の規約のもとそれを行うことで、状態変化を引き起こした要因の追跡可能性をさらに上げるというアプローチも考案されています。（これが Flux アーキテクチャの目的です）
では、DOM 操作ライブラリと仮想 DOM ライブラリを混ぜ合わせるとどうなるか……？ もちろん水と油です。
生 DOM を書き換えてしまえば、仮想 DOM ライブラリの内部データの青写真としての信頼性が失われ、予測可能な世界が崩れ去ってしまうからです。
一方、DOM 操作ライブラリ側から見ても、直接書き換えた DOM を仮想 DOM ライブラリが差し替えてしまうなど、予期せぬ挙動が生じる可能性があります。
とにかく考え方が正反対なので、どうしたって相性はよくありません。
jQuery でゴリゴリに書いている昔のフロントエンドを漸進的に Vue に差し替えていく、みたいなケースはあると思いますが、その場合でもなるべく混ざらないように、ページ単位で差し替えていくなどしたほうがよいでしょう。
少なくとも Web アプリケーションの新規開発をする場合、jQuery という選択肢はもはやないと考えるべきです。
ちょっと強い言葉を使いますが、ただ慣れ親しんでいるからという理由だけで jQuery を捨てられないのは、エンジニアの怠慢に他ならないとぼくは考えます。Git がよくわからないと言って Subversion を使い続けるようなものです。
jQuery は今や「もっと速い馬」であり、我々は自動車に乗るべきなのです。
See also: なぜ仮想DOMという概念が俺達の魂を震えさせるのか
0 コメント:
コメントを投稿