Q&A
因みにReactはReactNativeというスマホアプリに化けますので、
今後ますます伸びるでしょうね。
私もこれでアプリを作りたいと考えています。
私は数年前から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コンポーネント化系？）モジュールに破壊的な打撃を与えることになると思っているのですが、皆様はどう思われますか？
意見をお待ちしております。
回答4件
0
ReactやVueは、使う人がいる限りいらない子にはならないと思います。
それによって目的を達成できるのであれば、使われ続けると思います。誰も使わなくなってしまったら、要らない子になると思います。
あくまで私見ですが、使う言語や考え方は手段でしかないと思っています。
そういう意味では、書かれた言語が何であろうが、ユーザーにストレスの無い画面を提供する等といった目的が達成できていれば、何も問題はないと思っています。
分野は違いますが、COBOLだってまだ現役で動いていますしね。
言語の選び方によってコーディングの効率、保守性が変わってくるという意見もあると思いますが、どんな言語を使っても、分かりにくくも分かり易くもなります。
言語の選び方はリスクをどこで取るかということだと思っています。ちょっと違うかもしれませんがどこの株を選ぶかというようなイメージと似た感覚を持っています。
私自身はAngularJSのユーザーです。AngularJSはGoogle製、Reactはfacebook製。Web Componentsもあまり興味は無いのですがどこかの誰かが定めて標準だと謳っているんですよね。5年後にどこが継続して流行っているか、10年度にどこがアップデート終了しているかは誰にも分かりません。
私自身はGoogleと付き合っていくことに決めました。Googleが倒れたり不便さを感じたり他のほうが良さそうだったりしたら乗り換えを検討しますが、現状は満足しています。
hojoさんはそのリスクが取りたくなくて、自前でモジュールを作られました。株を買わず、タンス預金にしたイメージですね。それも、目的が達成できているのであれば一つの道だと思います。
最近確かに選択肢が多すぎますよね。
でもそれは、手段を提供する各団体が「ウチのファンを増やしたい！」というような目的のために流行らせようとしているに過ぎません。提供者はそれで何らかの利益（金銭的なものとは限らない）を得たいという目的があるはずです。
提供者の目的（ファンを増やしたい）と利用者の手段（リッチな画面を作りたい）が合致すれば利用すればいいと思います。
提供言語のファンが増えれば、それだけ言語も長続きします。だからいろんな提供者もがんばってユーザーを増やそうとしていると思いますが、あまり流されず、冷静に手段として優れているかどうかを判断し使うことが大事だと思います。
繰り返しになりますが、質問者さんは上記のようなことを考えるということ全般をリスクに感じ独自路線に走られているんじゃないかなと予想しており、それはそれで本当に立派なひとつの道だと思います。
投稿2017/04/07 00:24
総合スコア1947
0
ベストアンサー
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プログラマがいてもおかしくないし、それが「正しい」か「正しくない」かは本人が決めることです。楽しく悩んで「正しい」を探してみてください。がんばってください！
投稿2017/04/11 18:19
総合スコア69400
0
既にjQueryが無くても実装者の5割以上の要望は素のJSだけで簡単に実現出来ますよ。
最近実装されたCSSセレクタ・クラスの付け外しは特に便利で、ちょっとした事ならネイティブでいいやと思えるレベルになりましたね。
参考リンク：You Don't Need jQuery - Qiita
ならば何故jQueryを使うのでしょうか？
Ajaxの為？否、Ajaxのためだけに馬鹿でかいjQueryのライブラリを読むのは馬鹿げています。
参考リンク：jQuery.ajaxの代わりにSuperAgentを使う - Qiita
jQueryの存在意義は下位互換もうまく考えられていますので、
別に知らんでも生きていける類の話ですね。
ならばWeb Componentsは？
これも同様で、優れたエンジニアならばある程度触れて当然になるかも知れませんが、
基本的にはライブラリやフレームワークの開発者でなければ知らんでも生きていけるものとして扱われる技術でしょう。
じゃあWeb Componentsが正式に登場した後どうなるか？
何も変わりませんよ。
ライブラリやフレームワークが必要に応じて内部的に勝手に取り込んで有効活用するだけの話です。
少なくともReact等の既存JSフレームワークが脅かされるとは到底思えません。
下記はその根拠です。
そもそも、何故データバインディング系のJSフレームワークが台頭してきたのかと言うと、
そのフレームワークが「現実世界が論理世界に従うべき」という考え方をしているだけの話です。
今まで我らは現実世界に介入するには、計算やロジックとは全く関係ないところで必死にDOMツリーを操作する必要がありました。
そこでフレームワークは
「論理世界にある変数」を常に監視する仮想なDOMを用意して、
変数が書き換わると「現実世界のDOM」が有るべき形に瞬時に置き換わるという構造を作り上げました。
（オブザーバーパターンと呼ばれるやつです）
これにより、どこからでもバインドされた変数の値を更新しても、
確実にDOMツリーは最新の状態を保つことが出来るようになりました。
つまらない更新漏れのバグはほぼなくなりました、めでたし。
さて、この概念自体は「Web Components」と衝突しますか？しませんか？
別に衝突しませんよね、だって「Web Components」は単なる技術であり、概念を形にしたフレームワークとは別のものなのですから。
だからそのJSフレームワークが必要な時、必要な分だけ「Web Components」という新技術を利用する事になるでしょう。
投稿2017/04/12 04:22
編集2017/04/12 04:40総合スコア21158
自分もreact nativeでアプリ作りたい！
0
最新動向に詳しいというほどではないのですがコメントします。
例えば、WebComponents の 仕様の1つである ShadowDOM v1 には夢を感じますし、ShadowDOM v1 を前提としたフレームワークおよびライブラリが増えていくことは予想ができます。
いっぽうでやはり仕様の1つである HTML Template については、JavaScript 周辺技術が発達してしまった現在においては活用できる範囲は限定的になるのではないかなと思います。
WebComponents 技術と関連の深いライブラリとしては Polymer がもっとも著名と認識しています。Polymer は 2.0 のリリースを間近 （？） に控えていますが自分の観測範囲では大きな注目を集めているとは言い難い状況です。
ごく個人的な予測として、ライブラリやフレームワークの「ユーザー」という観点であれば、 WebComponents の実装状況や勢力を睨みながら技術選定を行う必要性はそれほどないのではないかと思っています。
投稿2017/04/10 12:53
総合スコア142
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/07 02:35 編集
2017/04/07 02:02
2017/04/07 14:10 編集