質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.33%

  • React.js

    913questions

    Reactは、アプリケーションのインターフェースを構築するためのオープンソースJavaScriptライブラリです。

主要ブラウザのWeb Componentsの実装が進むにつれてReactはいらない子になってしまうのですか?

解決済

回答 4

投稿 編集

  • 評価
  • クリップ 8
  • VIEW 5,508

hojo

score 178

私は数年前から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コンポーネント化系?)モジュールに破壊的な打撃を与えることになると思っているのですが、皆様はどう思われますか?

意見をお待ちしております。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • 退会済みユーザー

    2017/04/11 13:02

    複数のユーザーから「問題・課題が含まれていない質問」という意見がありました
    teratailでは、漠然とした興味から票を募るような質問や、意見の主張をすることを目的とした投稿は推奨していません。
    「編集」ボタンから編集を行い、質問の意図や解決したい課題を明確に記述していただくと回答が得られやすくなります。

回答 4

+6

ReactやVueは、使う人がいる限りいらない子にはならないと思います。
それによって目的を達成できるのであれば、使われ続けると思います。誰も使わなくなってしまったら、要らない子になると思います。

あくまで私見ですが、使う言語や考え方は手段でしかないと思っています。
そういう意味では、書かれた言語が何であろうが、ユーザーにストレスの無い画面を提供する等といった目的が達成できていれば、何も問題はないと思っています。
分野は違いますが、COBOLだってまだ現役で動いていますしね。

言語の選び方によってコーディングの効率、保守性が変わってくるという意見もあると思いますが、どんな言語を使っても、分かりにくくも分かり易くもなります。

言語の選び方はリスクをどこで取るかということだと思っています。ちょっと違うかもしれませんがどこの株を選ぶかというようなイメージと似た感覚を持っています。
私自身はAngularJSのユーザーです。AngularJSはGoogle製、Reactはfacebook製。Web Componentsもあまり興味は無いのですがどこかの誰かが定めて標準だと謳っているんですよね。5年後にどこが継続して流行っているか、10年度にどこがアップデート終了しているかは誰にも分かりません。

私自身はGoogleと付き合っていくことに決めました。Googleが倒れたり不便さを感じたり他のほうが良さそうだったりしたら乗り換えを検討しますが、現状は満足しています。
hojoさんはそのリスクが取りたくなくて、自前でモジュールを作られました。株を買わず、タンス預金にしたイメージですね。それも、目的が達成できているのであれば一つの道だと思います。

最近確かに選択肢が多すぎますよね。
でもそれは、手段を提供する各団体が「ウチのファンを増やしたい!」というような目的のために流行らせようとしているに過ぎません。提供者はそれで何らかの利益(金銭的なものとは限らない)を得たいという目的があるはずです。
提供者の目的(ファンを増やしたい)と利用者の手段(リッチな画面を作りたい)が合致すれば利用すればいいと思います。
提供言語のファンが増えれば、それだけ言語も長続きします。だからいろんな提供者もがんばってユーザーを増やそうとしていると思いますが、あまり流されず、冷静に手段として優れているかどうかを判断し使うことが大事だと思います。

繰り返しになりますが、質問者さんは上記のようなことを考えるということ全般をリスクに感じ独自路線に走られているんじゃないかなと予想しており、それはそれで本当に立派なひとつの道だと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/04/07 09:56 編集

    ご回答ありがとうございます。
    モジュールの利用を株に例えたあたり、すごくわかりやすいと思いました。

    確かにおっしゃる通りなのですが、もう少し踏み込んだ意見をお聞きしたいと思っておりましてAngularやReactはあくまでもJavaScript(やnode)によって作られたモジュールですが、Web Compornentsはブラウザに標準で実装されるためAngularやReactよりも低レベルなものと認識しています。

    その点を踏まえてWeb Compornentsがどのブラウザでも利用できるようになった場合、ReactやVueやAngularはどの程度の影響を受けるのか、そして、Web Compornentsが利用できるようになった場合、ReactやVueやAngularなどのデータバインディング系(またはWebコンポーネント化系?)モジュールがどのようにWeb Compornentsに歩み寄っていくだろうか、そしてどれくらい破壊的影響を受けるだろうかという予測について知りたいと思っています。

    もちろんWeb Compornentsがブラウザ標準だからと言って、それが必ず使われるようになるとは思ってはいません。そのため、そう考えるとWeb Compornentsもそれらモジュールの1選択肢となんら変わらないのですが、Angularを開発しているGoogleが中心となってWeb Compornentsの仕様を定めているという話も聞いているため、単純に選択肢の一つとして無視できるようなものではないのでは?と思っています。

    自分も詳しくないため質問させていただいているのですが、Web CompornentsはそれらJSのモジュールに対して破壊的な存在なのではないかという不安が拭えないため皆様の意見が欲しいと思って質問させていただいた次第です。

    データバインディング系(またはWebコンポーネント化系?)モジュールは今では数え切れないほど存在しますが、わかりやすさを優先してReactに絞って質問させていただいておりますが、個人的にはReactに限らずどういう影響を受けるのか意見をお聞きしたいと思っています。

    キャンセル

  • 2017/04/07 11:02

    最新情報や技術動向を踏まえていないという意味で、あまり望まれるような回答ではないと思いますので心苦しいのですが、私見であれば、Web Compornentsは大きな影響力は持てないと予想します。そのため各言語はある程度歩み寄る可能性はあるとはいえ、それによって破壊的な影響を受けていらない子になるようなことはないと思っています。

    その意見を支える大きな根拠はありません。あえて言えば何年経っても未だにその全貌が見えないことです。3年後ぐらいにも「そろそろ確定」とかやってるんじゃないですかね。
    判断がまともにできる状況ではありません。

    そうしている間に、ReactやVueのユーザーはどんどん増えていきます。Angularも最初の頃からすると随分様変わりし、より良くしようという流れは各言語提供元の独自路線で止まりません。
    そうすると当初Web Compornentsでやろうとしていたようなことがなんとなくできるようになって、「Web Compornentsって誰かに必要とされてるんだっけ?」という流れに進んでいく。もう既にそんな感じですかね。そんな状況でやっとWeb Compornentsが出てきたとして、流行るとは思えませんし、仕様策定している人たちのモチベーションもちゃんと続いているのか不安でなりません。

    最新状況や技術動向を踏まえた予測については、私も回答を待ちたいと思います。

    キャンセル

  • 2017/04/07 20:28 編集

    なるほど、貴重な意見ありがとうございます。

    確かにかつて、Web標準になると言われていたものが非推奨になったりしたものを見たことがあるのでWeb Componentについても同じ運命をたどる可能性がありますよね。(もう辿っていると)

    ただ、Web Componetの中のHTML templatesについてはcaniuse.comで確認したところほぼ全てのブラウザで現段階で使えるようになっているようで、少し驚きました。それがどういうものなのかはわかっていませんが...

    他にも皆様の意見をお聞きしたいと思っていますので気軽に回答してくれると嬉しいです。

    キャンセル

checkベストアンサー

+4

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プログラマがいてもおかしくないし、それが「正しい」か「正しくない」かは本人が決めることです。楽しく悩んで「正しい」を探してみてください。がんばってください!

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

既に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 13:32

    因みにReactはReactNativeというスマホアプリに化けますので、
    今後ますます伸びるでしょうね。
    私もこれでアプリを作りたいと考えています。

    キャンセル

  • 2017/07/17 10:14

    自分もreact nativeでアプリ作りたい!

    キャンセル

0

最新動向に詳しいというほどではないのですがコメントします。

例えば、WebComponents の 仕様の1つである ShadowDOM v1 には夢を感じますし、ShadowDOM v1 を前提としたフレームワークおよびライブラリが増えていくことは予想ができます。

いっぽうでやはり仕様の1つである HTML Template については、JavaScript 周辺技術が発達してしまった現在においては活用できる範囲は限定的になるのではないかなと思います。

WebComponents 技術と関連の深いライブラリとしては Polymer がもっとも著名と認識しています。Polymer は 2.0 のリリースを間近 (?) に控えていますが自分の観測範囲では大きな注目を集めているとは言い難い状況です。

ごく個人的な予測として、ライブラリやフレームワークの「ユーザー」という観点であれば、 WebComponents の実装状況や勢力を睨みながら技術選定を行う必要性はそれほどないのではないかと思っています。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

同じタグがついた質問を見る

  • React.js

    913questions

    Reactは、アプリケーションのインターフェースを構築するためのオープンソースJavaScriptライブラリです。