React.jsについての見解(まともに使ったことはない)

Read More



★注意がき★
今からReact.jsについてのこと書きますが、
ここで先に断っとくけどReact.jsをまともに使ったことはないデス。
せいぜい流し読み+サンプルコード動作程度。
批判的な内容も含まれるのでReact.jsが批判されてイヤな人は回れ右してください。
★注意終わり★


--
さて、ある日会社の同僚がReact.jsを勉強してた。
jsっていうくらいだから女子しょ…じゃなくてJavascriptのライブラリ的なものなんだろーなとまず想像した。
jQueryが台頭してからその他のライブラリは実質死んだも同然だったので、
新しく出てくる、ということは当然jQueryを超えるものなのだろうな、と少し興味を持った。

予備知識のないままReact.jsの概念をその人の口から聞いた。





( ゚д゚)ぽかーん







…空いた口が塞がらなかった。

うん、悪い意味で。



--
さてReact.jsって結局どういうものなんだ?


■React.jsとは
React.jsとは、WebページのUIを HTMLじゃなくてJavascriptプログラム内に書いて動的に生成・表示させてしまおう、というもの。



通常Webページを表示させる場合はHTMLでページ構成を書くわけだがReact.jsがその一部を担うというわけだ。

これだけ聞くとPHPと同じようなものだなーという感じ。
しかしPHPなどのようなサーバサイドで動くものと、
Javascriptのようなクライアントサイドで動くものとではその意味が全然違ってくる。


言わずもがなだが、クライアントサイドで動くということはすなわちPCのスペックなどがもろに動作に影響するからだ。

昔よりだいぶPCスペックが上がってきてるとはいえ、
全員が全員買い替えてるわけではない。
また買い替えていたとしても色々なものを入れていたら当然性能は落ちる。

こんなこと今更言わなくてもわかるだろう?
いや、わかってくれ

これはReact.jsに限った話ではないし自分がいっっつも言うことだけど
javascriptに大きな仕事をさせるなと。
↑Reactどうこうよりこれが言いたい


まあこういった概念自体は割と昔からあるものだが、問題は表示内容をどこまで任せるのか、だ。
React.jsのサンプルを見ていても思ったが、
そもそもjsのコード内にHTMLコードを組み込むこと自体がナンセンスだ。
いや別にこれもReact.jsに限った話じゃないけど。

仮に組み込むものがHTMLコードじゃなかったとしても
やはりUI部分をプログラム内に隠すのは頂けない。


Webデザイナに対して無駄に要求スペックが上がるだけだ。
まあWebデザイナという肩書はあるけどHTMLコード自体わかりませーんって人もいるけど。
そういう人は最初からWebデザイナとは認められない。認めてない。


あと、某サイトではカレンダーや電卓の使いまわしができるとか書かれていたけど、
そんなものそのまま使えるわけないだろう。

どこかで表示されていたのとまったく同じものが自分が使うサイトに表示されているとサイトの格が下がるだけだ。

「ああ、どこぞのCMS使って作っているのかな?」

或いは
「フリーのツールをそのまま使ってるのか」
とか思われる。


もし開発を依頼している立場で現場からそんな提案が上がってきたら間違いなくブチ切れですよ。
そんなモン、使えるのは個人のやっすいサイトだけだ。


仮に使うにしても上記の理由から当然UIやらなにやらを変更する必要が出てくる。
そうなると中身を解析していく必要がでてくる。
React.jsでUI部分まで隠されていたら今度はjavascriptの解析から行わなくてはならない。

以下のようなことが起こるだろう。
「あ、ここにHTMLコードがあったぞ!」
「ここにもHTMLコードの一部があるぞ」
「こんなとこにもタグがあるんですけど…」
「これはこう表示される部分かな?(想像)」
「え、これ自分でUI作って他のjavasライブラリあてた方がはやくね?」
「あーコンパイルめんどくせ」

こんなのこと言いながら触るのなんてごめんだわ。
UI変更なのにデザイナがそんな深いとこを触るの?


まあUIをリッチにしようとすること自体はいいことだと思うよ。
お金取りやすくなるし発注元も満足させやすいしな。
ただし、ってのがつくけど。

ただし、
 1.ユーザの使うPCに負荷が少ないもの
 2.ユーザの使うPCで差がでない程度のもの
上記は最低限のお約束。

そして、
 3.リデザインや改修の時に障害になりにくいもの
 4.携わる人の要求水準を無駄に上げないこと
この辺はコスト的な問題があるから当然だな。



あと某サイトに注目される理由として、
・Facebook産であること
と、かかれていたけどそれが理由になるのか?

君はYUIを知っているかね?


あと、
フロントエンドの考え方を根本的に覆す
とも書かれていた。
そりゃ覆すだけなら覆るわ。


もしこんなのを個人サイト以外で使われていたとしたらあとあと触る人が哀れだわ。




--
まあ勉強しようという心意気を否定する気はないし、新しいものに興味を持つのはいいことだと思う。
何が流行るか残るかなんてものは確実には誰にもわからないしな。
# FLASHなんかもすっかり消えたねえ


ニッチな技術を持つのも考え方によってはアリなのかも。




俺はやらんが。




Comments(3)

1  みやび  2016/11/28 (月) 13:18 ID:6ee2XnR15
HTML本来の用途を考えればシラサヤさんの発信してる内容で間違いないですが、
毎回ページをレンダリングし直すのは遅いので、多少マシンパワーを使ってでもJSで必要な分を最小限に表現するWebアプリは需要が増えて来てます。
その時に素のJSやjQueryだと破綻しますので需要と共に生まれた必要悪的な存在でしょうか。

例としてリネージュの計算機のWebアプリを作るとします。
リネージュのHPやMPはクラス・Lv・CON・WISを基準にランダムな値を加えた数値により決定されます。
これをJSで書くとこんな風に再計算の処理だらけになります。
・クラス、Lvのセレクトボックス→onChangeでHPとMPを再計算してDOMを操作
・CONのセレクトボックス→onChangeでHPを再計算してDOMを操作
・WISのセレクトボックス→onChangeでMPを再計算してDOMを操作

その中でもLvはあらゆる攻撃や命中、防御の計算に関わってくる為、Lvを増減させた時に走る関数は機能の実装に比例してどんどん肥大化していきます。
武器防具や敵が出てきて仮想の戦闘が始まると収集がつかなくなります。
この問題をJSフレームワークはオブザーバーパターンを用いて解決します。(データバインディング等と呼ばれています)

HPはLvとクラスとCONに依存するので、これら3つの値を利用した含む計算式をテンプレートに記載し、仮想の要素を宣言します。
仮想の要素はDOM上に展開されると同時に3つの値を監視し続け、3つの値のどれかが書き換わった時点で再計算を行い、常にあるべき状態に描画しなおします。
要するに「DOMの書き換えはエンジニアがやることじゃない」「現実(DOM)は理論(JSの値)に従え」といった思想で作られています。

React.jsはこの辺の塩梅が優秀で、黒魔術な所は上手くライブラリ内で完結させ、速度は出るし値は綺麗に一元管理出来ると人気のあるJSフレームワークです。
しかし酷いオレオレワールドで勉強量も多ので、もし機会があればVue.jsみたいなゆるくて簡単なフレームワークを使ってどんな感じか掴んでみてはどうでしょうか?

2  シラサヤ  2016/11/28 (月) 14:15 ID:NTXPwzm15
例えを出してくれてありがたいのだがこの2つの違いがわからんのだが。

これと、
>・クラス、Lvのセレクトボックス→onChangeでHPとMPを再計算してDOMを操作
>・CONのセレクトボックス→onChangeでHPを再計算してDOMを操作
>・WISのセレクトボックス→onChangeでMPを再計算してDOMを操作

これ。
>仮想の要素はDOM上に展開されると同時に3つの値を監視し続け、
>3つの値のどれかが書き換わった時点で再計算を行い、
>常にあるべき状態に描画しなおします。


やってること同じことように思えるのだが。

3  みやび  2016/11/29 (火) 00:25 ID:a2Jls9E15
機能追加のフェイズで効果を発揮します。
例えばキャラクター情報をクッキーで保存する機能を付け足すとします。

前者の設計思想はレベル、クラス、CONのセレクトボックスの値が変更されたことがトリガーなので、
新機能により3つの数字のどれかが変更される可能性がある場合、HPとMPの更新を追加する必要があります。
大抵こうした作業が漏れて、クッキーからロードするとHPは更新されるけどMPが更新されてないというような不具合につながります。

後者はあくまで3つの値に依存していると宣言するので、
他の要因で勝手に3つの値が書き換わっても、1行もコードを足すことなくHPやMPがあるべき値に書き換わります。
なので、様々な機能の関数からHPやMPを更新するという行が消えて、関数内をシンプルに保ちやすくなります。

後者は設計としては優れているものの、オブザーバーを実現する際に何時・頻度は…という問題があり、コードが汚れる上にパフォーマンスが落ちます。
JSフレームワークはその辺のパフォーマンス低下を上手く抑えつつ、この設計思想を、SmartyのようなHTMLベースのテンプレートで簡単に表現出来るというのが売りです。