僕に「ドクターペッパー」の話させたら長くなりますよ？
これは僕に「○○」の話させたら長くなりますよ Advent Calendar 2016 - Adventar22日目の記事です。
なおドクターペッパーを飲みながら書いています。
前振り
ドクターペッパーの話をするとしてもどのぐらいの在住国で「ドクターペッパー」の話をすべきか、あまりにも販売国が広すぎて困ってしまうので、フォーカスするためにいくつかの質問に答えてもらっていいですか？、でないととっかかりについて迷いますので。
まずひとつ目の質問、日本に住んでいますか？
※なお、この質問にはYesと答えたものとして進めます
二つ目、コーラ派ですか？
※コーラ派だ！囲め！、ペプシ派？見逃してやる！ドクターペッパーを愛すものにこの設問は愚問でしたね
三つ目、知的飲料と言えば？
※この質問にはドクターペッパーと答えt(ry
知的飲料ドクターペッパー
画像検索で拾った
日本でドクターペッパーと言えばコカ・コーラから発売されているものが代表的ですね、そうです、マゼンタ系の赤みがかったアメリカンチックなデザインのラベルが特徴的な飲料です。
コカ・コーラ公式より
僕はこのドクターペッパーの350ml缶を近所の販売店で毎週備蓄しており、運動後、頭がちょっと疲れた時などの身体が糖分を欲しがっている時によく飲みます、特にデスクワークや研究中などに飲むのは最適です、そうです、ドクターペッパーは知的飲料なのだフゥーハハハ!
食事にもドクターペッパー
と言っても合うものと合わないものがあります、肉類、揚げ物、バーガー類などはよく合います、枝豆は微妙です、ビールの範囲をカバー出来てるようで微妙に出来ていないです、おしい。
魚も微妙です、パスタはりんごサワー変わりにいけるかな？、お？これは？・・・いけ・・・やっぱり微妙でした。
こう見るとジャンクなものとの組み合わせに限られますね、ただそれはコーラでも同じこと、ならばコーラを飲むくらいならドクターペッパーですね、みなさんドクターペッパーを飲みましょう。
コーラではダメなのか？
よく比較されます、なんでドクターペッパーなのかと、コーラじゃダメなのかと、ダメなんです、コーラはダメなんです。
コーラはパンチが強すぎる
これは僕の体質の問題も含んでいると思いますが、コーラはパンチが効いています、たまに飲む分には良いんですがデスクワーク中に飲むには効き過ぎる、変な覚醒度合が集中の邪魔をするって言うんですかね、とにかくデスクワークにはコーラは合わないんです。
そこでドクターペッパーですよ、(コカ・コーラの)ドクターペッパーは20種類以上のフレーバーからなる優しい目覚めを与えてくれます、集中の邪魔をしない、むしろ優しく手を差し伸べてさあご一緒に頑張りましょうと応援してくれてるような気がしてよし僕も頑張るかという気持ちになりドクターペッパーの優しさに身を包まれながら次第に僕は(この文章は省略されました)
ドクターペッパー初心者へ向けて
ドクターペッパーはよく杏仁豆腐の味と呼ばれます、味に不慣れな人が不味いと言うのも分からないでもないです、とりあえず一本飲んでみましょう、さあさあ遠慮なさらずに、え？コーラが良い？囲め！最初はみんなそういうんですよ、だけど慣れてくるとドクターペッパーを飲みたくなってきます、慣れなんです、慣れのその先にやみつきになる美味しさが待ってるんです、そのあと一週間くらい間を置いてまた飲んでみましょう、すると今度はすんなり飲めるはずです、また一週間後に飲んでみましょう、すると美味しさに気付くはずです、そのうちドクターペッパーを習慣的に飲みたくなるでしょう。
そうなればおめでとう、これであなたもドクターペッパー愛飲者だ。
ReactJS界隈の人に聞きたい、への返答
mizchiさんの返答により一段落した感がありますが、自分もidコールされてたので自分の考えを返答しておきます、Qiitaに書くような事ではないのではてなブログを開設(はてなダイアリー:wordiの日記もあるけど長い事更新してないし今からならはてなブログの方が良い気がしたので)。
自分のブコメ
Backbone(&Marionette)に対するReactの利点は、構造に各Viewが縛られた構造変更時のView改築コストからの解放。SPAは必要なら。JSX嫌ならjadeを使うのも手。5年後React残ってるか知らんけど今だと有力候補、少なくともBackboneより良い
ここでは、自分のブクマの範囲である「何故React.jsを使うのか」と「Backbone.js(& Marionette.js)と比較してどうか」についてを掘り下げたいと思います。
jQueryではなくReact.jsを選定する基準について
サーバ・クライアントの計算・通信コスト等がありますが、ここでは開発時の筋の良さについて考えてみます。
jQueryを使うと現状態のDOMの取得・追加・更新が直感的に、かつ手軽に行えます、シンプルなページに何か小さな機能を加える、って程度ならjQueryがマッチするでしょう。
ただし、ここに状態を持ったデータが含まれると状況が変わってきます、jQueryが出来るのは現DOMに対しての差分の適用です、データ(MVCのMにあたる)をもとにDOM(MVCのVにあたる)に適用しようとする時、jQueryだけだと初回のDOM構築、途中の差分DOM更新とロジックが複雑化してくるでしょう、それを緩和する為にJsRenderやHandlebars、Jade等のテンプレートエンジンを使ってロジックから複雑さを排除し、Viewの冪等性を簡単に保障する仕組みが欲しくなるでしょう、jQueryの役目はここまでです。
jQueryでもFormへの入力内容やサーバからのレスポンス結果をデータとしてまとめ(例えば、モデルクラスに集約するとか)、適切にDOMを更新する仕組みは作れるでしょうが、それらをやってるのがBackbone.js(& Marionette.js)やReact.jsであり、それなら最初からBackbone.js(& Marionette.js)やReact.jsを使えって事になります。
Backbone.js(& Marionette.js)とReact.jsの比較
自分はBackbone.js(& Marionette.js)とReact.jsの両方で開発経験があり、その二つを比較した結果React.jsの方が開発しやすいと結論を出したのでReact.js推しです。
ちなみにどちらもデータの更新、Viewへの適用、View・サーバからのデータ取得のサイクル上ではほぼやってる事に大差はないです、Backbone.js(& Marionette.js)でも基底クラスの各Viewを用意して、
var AppBaseItemView = Backbone.Marionette.ItemView.extend({
modelEvents: {
'change': 'render',
},
});
var AppBaseCompositeView = Backbone.Marionette.CompositeView.extend({ 略 });これらを継承するようにすればthis.model.set()でrender()が発火したりと(ただし、配列等の参照型の場合はchangeイベントが発生しない為、明示的な発火が必要ですが)React.jsのsetStateとほぼ似たような使用感に近づける事が出来ます。
Backbone.js(& Marionette.js)で辛いのはレイアウト変更の時です、上記コードでも少し使ってますが、ViewにはItemView・CollectionView・CompositeView・LayoutViewがあり、レイアウトにより適切に使い分ける必要があります。
CompositeViewから直属のItemViewが無くなる、とかであればCollectionViewへの格下げや、ItemViewをnullにするとかでいいのですが、CompositeViewのItemViewもCollectionにしたい、って時には改めてLayoutViewを設け、Regionを用意し、CollectionViewを2つぶら下げる、というめんどくさい手順を踏む必要があります。
力技でぶら下げる事も出来ますが、そうすると冗長なコードが発生するし、意味不明な挙動が発生する要因にもなりかねるのであまりやりたくありません、最終的にBackbone.js(& Marionette.js)辛い、ってなります、React.jsではそういった煩わしさがありません。
まとめ
というわけで、そのページが状態を持ち始めた辺りからjQueryではなくReact.jsを使うってのが自分の意見です、ちなみにdomの改変コストについても質問されましたが、自分はロジック上で無駄な事はしていないか?、までは気にしますが、そこまで調査をしたわけではないので改変コストの分岐点はよく分かってないです、数十個くらいになるとvirtual domの方が速いんだろうなあ、とは思っていますが。
一応、React.jsを使う前にもベンチをとったりしてるので、その時のページを載せておきます。
