質問: 私は数年前からReactについて意識しており、実際にReactに関する書物などを購入してHello Worldの実装も行なったことがあるのですが、どうもReactは癖が強い気がしていまして(JSXなど)今までテンプレートエンジンを利用してウェブサイトを作成していた自分には、Reactの素晴らしさがまだ実感できていません。 私がこれらデータバインディング系(またはWebコンポーネント化系?)モジュールに初めて触れたのはKnockout.jsが切っ掛けになるのですが、Knockout.jsを利用することで複雑なDOM操作から解放されたときは本当に感動しました。 しかし、それらのモジュールを使いこなしていく過程でより複雑なことをしようとすると、どう実装すれば良いかわからないことがあり、ドキュメントを何度も読み返して悪戦苦闘することがありました。(Knockout.jsならではの苦闘かもしれませんが) 時々jQueryでいいんじゃないの?と、思うこともありつつ、なんとか実装を終えて一息ついたところでプロジェクトから離れるわけですが、残念なことに再び戻ってきて自分の書いたコードを見て見ると、コードが複雑すぎてよくわからない状態が起こり、基本に立ち返って勉強をし直すといったことがありました。 もちろんこれは、自分の書いたコードが汚いということもあると思いますがこれらモジュールの学習コストが高いのも事実だと思います。 そんな痛い経験をしつつも、総合的にデータバインディング系(またはWebコンポーネント化系?)モジュールは便利であると思っているのですが、どうにも単純明快なモジュールが少ないように思います。 個人的にVue.jsはとてもシンプルだなと思っており今最も関心を持っていたりするのですが、新しいモジュールが登場したり、従来のモジュールにおいてもアップデートが頻繁に行われたりなど、モジュールの進化が速いこともあり、未だに安心して使えるものが見つかっていません。 そもそも、自分がこれらのモジュールに興味を持ったのはサーバサイドレンダリングに魅力を感じたからです。もし、これから作るプロジェクトはSPAで作ると初めから定めることができるのであれば、あまり気にしなくて良いことなのかもしれませんが、実際に仕事としてウェブサービスを構築するとなるとSEOについて議題になることが多く、後から対応するようなことが経験上多かったのです。 そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトを読み込ませて何でもかんでもJSでやろうとする新しい考え方が、古いWeb技術と比較した時にギャップが多大なために色々なことに悩まされるといった状態から解放されるとも思ったため、サーバサイドレンダリングに関心を持って今まで追ってきました。 ただ、これらのデータバインディング系(またはWebコンポーネント化系?)のモジュールは開発環境を劇的に変化させてしまうことが多く、jQueryの必要性を奪い、Ajaxは代わりにfetchを利用するなど、新しいスタイルで開発することを余儀なくされる点も含まれていると思います。 また、jQueryのような原始的なDOM操作がどうしても必要になってくる場面というものがあるような気がしていて、例えばUXをより良いものにするために画面全体に暗転用のDIVを貼り付けてロードサークルを表示させたり、touchmoveを制御してスマートフォンで一時的にスクロール操作を禁止するといった、jQueryを使って今まで行っていたトリッキー制御がReactやjQueryを使わずに簡単に実装できるのかわかりません。 jQueryは確かに古い技術なのかもしれませんが、シンプルなセレクタとメソッド、そして豊富なプラグインを提供してくれるjQueryは素晴らしいものであると私は今でも思っています。(容量が気になりますが) そこで色々と考えた結果、jQuery環境を残しつつ、サーバサイドレンダリングが行える環境を実現できれば良いと思い、独自のモジュールを作ったりもしました。その独自モジュールはnodeで実装されており、従来の良くあるテンプレートエンジンを利用したHTML出力に加え、サーバサイドのテンプレートの一部をクライアントサイドに送りつけて特定の範囲をクライアントサイドで再レンダリングできるというものです。 サーバサイドのテンプレートをクライアントサイドでも利用できれば事足りることが多かったため、個人的にこの方法はうまくいきました!つまりReactのような大げさなものはいらない..と。 しかしこの独自モジュールはアプローチが異なり、データバインディング系(またはWebコンポーネント化系?)のツールとは違ってコンポーネントを作成することはできないため、もしもプロジェクトが大きくなっていってコンポーネントの必要性に迫られた時には恐らく困ってしまうんだと思います。 (話は逸れますが、サーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか..もちろん、データバインディング機能込みで初めてサーバサイドレンダリングといえるのかもしれませんが..) そういった意味でやはり独自のものは使わず、なるべくメジャーなモジュールを使いたい...そう常日頃思っているのですが、どうにも多すぎやしませんか?今日、Riot.jsというものの存在を知ってもう意味わからんと思ってます。 これら独立したモジュールに対し、それぞれ互換性の異なるコンポーネントがたくさん作られているんですよね...?そう考えると心底ゾッとします。 さらには、ブラウザ標準搭載予定のWeb Componentsの実装が進んでるというカオスっぷり。 しかも、Web componentsはReactやVueに比べてより低レベルなコンポーネントの実装ができるわけです。 そこでふと思ったのですが、コンポーネントとしてはやはりより低レベルな実装の方が良いわけで、このまま主要ブラウザのWeb componentsの実装が進むにつれて、ReactやVueで作られたコンポーネントはWeb componentsで作り直され、デベロッパーの意識がWeb componentsに集約することによってReactやVueといったデータバインディング系(またはWebコンポーネント化系?)のモジュールは不要なものになってしまうのではないでしょうか? そう考えていたら、ただでさえどれを使えば良いか迷っている中、怖くてこれらのモジュールを導入することが本当に正しいのかわからなくなってしまいました。 もし、ReactやVueなどで作られたコンポーネントがこの標準のコンポーネントと互換性を持たないのであれば、Web componentsはこれらデータバインディング系(またはWebコンポーネント化系?)モジュールに破壊的な打撃を与えることになると思っているのですが、皆様はどう思われますか? 意見をお待ちしております。
回答: > > ReactやVueなどで作られたコンポーネントがこの標準のコンポーネントと互換性を持たないのであれば、 > > Web componentsはこれらデータバインディング系(またはWebコンポーネント化系?)モジュールに破壊的な打撃を与えることになると思っているのですが、 > > > そこまで破壊的かなぁ、という印象です。 例えば、Array.isArray()というメソッドがあります。これはIE8までは使えませんでした。(たぶん) 古くは Prototype ( Object.isArray )、jQuery ( jQuery.isArray() )、Lodash (#isArray )、Underscore.js ( #isArray ) など、各種ライブラリが代替メソッドを用意することで機能を実現していました。 さすがに Prototype.js を今から新たに使うことはあまり無いですが、数年前までメンテナンスが続いていましたし、現役で動いている古いサイトに出会うこともあります。jQuery は最近は皆さん避けていますが、今でも十分使用に耐えるライブラリとして現存しています。(他は言うまでも無いので省略) 実装を具体的にきちんと見たわけではありませんが、それらライブラリは `Array.isArray()` があれば内部的に使っていると思います。単純なメソッドなので機能も変わらないから、という事もありますが、速度に優れ問題なく機能するなら内部的に使うだけだと思います。 ReactやVueなどがどのようにDOMにアクセスするかはそこまで調べていませんが、現在と同じ書き方で内部的に Web Components を利用することだってあり得ると思います。 ライブラリやフレームワークはたくさんありますが、結局自身で調べて納得のいくものを利用するか、既にされているように自作するかどちらかしかありません。 「本当に正しい」は人によって違います。死ぬまでReactに出会わないJavaScriptプログラマがいてもおかしくないし、それが「正しい」か「正しくない」かは本人が決めることです。楽しく悩んで「正しい」を探してみてください。がんばってください!