Vue vs React vs Angular Part.2

**デフォルトの名無しさん** · 2019/03/09(土) 22:02:33.71

実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
※前スレ
Vue vs React vs Angular
http://mevius.5ch.net/test/read.cgi/tech/1545395856/

★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください

**デフォルトの名無しさん** · 2019/04/08(月) 01:56:14.66

>>302はいったい何を否定しようとしたんだ？webサイトという言葉の使い方がおかしいということなのか？

**デフォルトの名無しさん** · 2019/04/08(月) 02:16:44.05

>>303
> そうか？office365とかgoogle documentとか成功してるじゃん。

それらは、もともとデスクトップアプリだったもの
ウェブサイトだったわけじゃない。

>>305
> webサイトという言葉の使い方がおかしいということなのか？

アプリのように動作するウェブサイトという
変なインターフェースは誰も求めてないという話。
例えるならば、ジョイスティックで操作し、美麗な3Dゲームのような
新聞ビューワーみたいなもの。誰もそんなので新聞を読みたいなんて思わんだろ？

**デフォルトの名無しさん** · 2019/04/08(月) 08:10:05.44

>>306
ん？だったら例えばoffice365はアプリのように動作するwebサイトで成功してるじゃん。

**デフォルトの名無しさん** · 2019/04/08(月) 09:08:14.77

>>302
jQueryMobileは単純にBootstrapとかにとって代わられただけじゃん

**デフォルトの名無しさん** · 2019/04/08(月) 09:15:13.85

>>307
どうせ使ったことないだけじゃね？

**デフォルトの名無しさん** · 2019/04/08(月) 11:34:53.34

>>301
そうなんだよね。オフライン対応って無理がありすぎるんだよね。
以前firebaseのrealtime database使ったが、オフラインからの同期処理に制限が多すぎて厳しい。更新が時系列を保証せず最終更新分だけ同期するとか、かなりクセがある。
WebworkerとindexedDBで効率よくキャッシュする方が当面は幸せになれそう。

**デフォルトの名無しさん** · 2019/04/08(月) 13:53:28.07

>>307
office365はアプリのように動作するウェブアプリであって
ウェブサイトじゃないんだよ

**デフォルトの名無しさん** · 2019/04/08(月) 13:57:09.46

まあこれでも読んで勉強して。IBMだからそれなりに信用できるでしょ？

第 1 回 Web サイトと Web アプリケーションの違い
https://www.ibm.com/developerworks/jp/web/library/wa-websiteapp/index.html

**デフォルトの名無しさん** · 2019/04/08(月) 14:49:09.97

excelで作ったドキュメントをなるべくそのままの形でhtml化する方法は無いでしょうか？
excelでhtml形式で保存すると裏側が汚いです
Gatsbyのプラグインにそれらしきモノがあったので試してみたら、色もセル結合もフォントサイズも全部落ちてしまいました

まぁ自分で自作すればいいんでしょうが、気が遠くなるくらいたくさん作り込まねばならず、皆さんはexcelドキュメントをそのままWeb化したいとか要望された事はありませんか？

**デフォルトの名無しさん** · 2019/04/08(月) 15:43:06.23

>>311
いやだから>>305でwebサイトという言葉の使い方がおかしいということなの？って聞いたのによくわからん回答されたから混乱してるんだが…
で、結局webサイトという言葉の使い方がおかしいってことなのね。

**デフォルトの名無しさん** · 2019/04/08(月) 15:49:10.83

要は、office365のようなものをwebサイトと呼ぼうがwebアプリと呼ぼうが話の本筋には何の影響もないのに、>>302の長文で謎の語りが入ったから話がグチャッとなっちゃったって事実に気づいて欲しい。

**デフォルトの名無しさん** · 2019/04/08(月) 15:51:36.81

>>313
スレチだけどレスすると、
htmlにせずGoogleDocsとかにインポートして公開した方がいいんじゃね
こういうの
https://www.howtonote.jp/google-document/open/index1.html

**デフォルトの名無しさん** · 2019/04/08(月) 20:15:16.81

オフラインデータはクッキーをいじり回すことしか出来ないのね
せめて画像を確実にローカルに保存できればオフラインでも動かせる
アプリが作れるだろうに

**デフォルトの名無しさん** · 2019/04/08(月) 20:22:17.47

>>317
Webストレージで画像保存できるじゃん

**デフォルトの名無しさん** · 2019/04/09(火) 07:41:13.08

reactは覚える事は少ないけども設計力が必要
宣言型プログラミングと同じで高い論理性が要求されるから苦手な人は多いかもね

**デフォルトの名無しさん** · 2019/04/09(火) 23:06:06.17

悲しいのはAngularの勢いが無くなり、横ばいのAngularJSの方が残りそうなところ
もうAngularはGoogle Graveyard入りだろ。どうすんだよAngularで作ってる新規プロジェクト

**デフォルトの名無しさん** · 2019/04/10(水) 00:47:58.78

Angular1の方が好評だったってこと？ｗ

**デフォルトの名無しさん** · 2019/04/10(水) 00:52:39.92

angular使うくらいならvueの方がええわなぁ
reactは論理性高いから日本人には不向きやろなぁ

**デフォルトの名無しさん** · 2019/04/10(水) 01:08:10.98

ググってみたけどreactはhtml側ではあまり小細工しない感じだねえ
論理的というのがいまいち分からないけど

**デフォルトの名無しさん** · 2019/04/10(水) 02:32:35.33

個人的にはbackbonejsが好きなんだけどなあ。自分で自由に作れるし
有名どころ使ってるのに、扱いが微妙

**デフォルトの名無しさん** · 2019/04/10(水) 10:00:46.62

そういえばchromium版Edgeのプレビュー出たけどおまえら使ってみた？

**デフォルトの名無しさん** · 2019/04/10(水) 10:11:11.18

>>320
これ以上進化する予定のないものが残るわけないじゃん

**デフォルトの名無しさん** · 2019/04/10(水) 12:23:01.13

>>326
進化させるのは自分の設計、コーディング次第なのがbackbonejsの思想だけど
フルスタックじゃないから足りない部分は自分たちで補えばいいし
そもそもbackbonejsは、つい最近更新されたばかりで死んでないけどな

昨今のフレームワークは全部入ってるから良いと思ってる
Railsやcakeみたいに作るのが簡単ならわかるけど、複雑化したら折角のフルスタックフレームワークがゴミになるだけ

**デフォルトの名無しさん** · 2019/04/10(水) 12:30:50.16

これ読むと良いかも。
フレームワークとライブラリの違いがわかってない人は特に

フレームワークは善か悪か，その両方か？
https://www.infoq.com/jp/news/2019/04/frameworks-libraries-axon

**デフォルトの名無しさん** · 2019/04/10(水) 13:13:49.79

>>327
AngularJSの話してんだけどアンカ先くらい見ようや

**デフォルトの名無しさん** · 2019/04/10(水) 13:50:22.69

>>327
> そもそもbackbonejsは、つい最近更新されたばかりで死んでないけどな

https://backbonejs.org/#changelog

1.3.3 ? Apr. 5, 2016 ? Diff ? Docs
～それから3年の月日が流れようとしていた～
1.4.0 ? Feb. 19, 2019 ? Diff ? Docs

ほぼ死んどるがなｗ
1.4.0リリース作業の前のコミットは2018年5月だし、
ドキュメントや些細なミスを除けば、機能追加は2017年じゃないか？

**デフォルトの名無しさん** · 2019/04/10(水) 16:27:07.49

>>328
ひと言で説明すりゃいいのにくどくどとしつこい内容だな

**デフォルトの名無しさん** · 2019/04/10(水) 22:25:31.68

>>322
その文からは、お前さんに論理性が無い事しか分からんな。

**デフォルトの名無しさん** · 2019/04/11(木) 00:19:20.16

フレームワークは、先に全体の構造が決まっていて、そこにはめ込む部品を作る。
全体の構造が決まっているから、プロ向き

ライブラリは必要な都度、組み込んで、部分から先に作っていくから、
全体の構造が最後まで決まらないので、スパゲッティ・泥団子になりやすいので危険！

**デフォルトの名無しさん** · 2019/04/11(木) 00:20:57.76

全体の構造なんて先に決めればいいだけやんｗ

**デフォルトの名無しさん** · 2019/04/11(木) 00:26:50.15

>>333
フレームワークに任せとけば安心って思考停止して、結局何と何が依存してるか
わからなくなってそのフレームに閉じ込められるパターン。

**デフォルトの名無しさん** · 2019/04/11(木) 01:02:55.46

>>335
Angularの悪口はそこまでだ！！

**333** · 2019/04/11(木) 02:29:16.00

全体の構造を、各人が決めたら、ダメ！
各人によって、構造に違いがあるから、他人と思いを共有できない

Aが作った構造を、Bが気に入らないなど、トラブルになる

だから、Rails などの既成のフレームワークを使う。
そのフレームワークの構造を共有できるから

多くのフレームワークも、Rails を基本としている

**デフォルトの名無しさん** · 2019/04/11(木) 02:33:37.60

nuxtの出力jsが乱数名みたいになるのなんとかならんのかな

**デフォルトの名無しさん** · 2019/04/11(木) 03:23:58.52

>>337
> Aが作った構造を、Bが気に入らないなど、トラブルになる
> だから、Rails などの既成のフレームワークを使う。

だからその「既成のフレームワーク」を作ったのAで
それを使うBが気に入らないってトラブルになってるんだろ？

**デフォルトの名無しさん** · 2019/04/11(木) 03:24:46.97

Rails 作ったやつは他人なんだから
思いを共有できないわな

**デフォルトの名無しさん** · 2019/04/11(木) 08:16:15.03

>>335
規約に則って書きさえすれば、チームのスキル差を減らして、一定の品質が担保できるのがフレームワークのメリットじゃない？

フレームワークに閉じ込められるって表現してるけど、それ単にチームで設けた規約に不満を述べてるだけかと。

もし今使っているフレームワークに不満あるなら、そもそも最初のフレームワーク選定時に意見を言うべきだし、
発言権のない立場なら大人しく従うか、転職なりしてプロジェクトから抜けるしかないんじゃないかな。

**デフォルトの名無しさん** · 2019/04/11(木) 08:17:20.21

思いは共有できなくても、実績があるフレームワークに従いましょう、ってことで平和に収まるって話だろ。
この効果は間違いなくある。

**デフォルトの名無しさん** · 2019/04/11(木) 08:18:25.70

ジャップのくせに

**デフォルトの名無しさん** · 2019/04/11(木) 14:38:55.28

japjs

**デフォルトの名無しさん** · 2019/04/11(木) 18:06:29.66

某個人アプリ制作者のブログで「5ちゃんのプログラミングスレはqiitaと比べて全然遜色しない内容だ」
って感じで書かれてるから初めて見に来たけど生産性のあるレスほぼなくてワロタ

**デフォルトの名無しさん** · 2019/04/11(木) 18:32:42.76

>>341
規約があればいいがほとんどない。
>もし今使っているフレームワークに不満あるなら、そもそも最初のフレームワーク選定時に意見を言うべきだし、
>発言権のない立場なら大人しく従うか、転職なりしてプロジェクトから抜けるしかないんじゃないかな。
そもそも選定時にはその会社にいないし選定してった奴は転職なりしてプロジェクトから抜けてるわけで
マジクソだよ。

**デフォルトの名無しさん** · 2019/04/11(木) 18:33:55.90

>>346
さっさ転職しろ

**デフォルトの名無しさん** · 2019/04/11(木) 19:27:20.19

>>345
このスレじゃなさそうだな。。今angularを勉強してるが、これじゃないとという理由が見つけられないでいる。学習曲線や人員的な問題は置いといて、明らかに有利な点や逆にangularで困る事があったら教えて欲しい。

**デフォルトの名無しさん** · 2019/04/11(木) 19:42:22.98

日本にいるとVue人気だから勘違いしそうになるがやっぱ採用実績はReactが圧倒してるんだな。475kサイト vs 64kサイトか……
しかしなぜかGitHubのスター数だけタメ張ってるｗ
Top JavaScript Frameworks For 2019
https://www.codementor.io/nikhil21tyagi/top-javascript-frameworks-for-2019-s8881i8ga

パフォーマンスについてはReactよりVueのほうがいいな。
AppRunってやつ速くて気になる。
しかしAngularいくらなんでも酷すぎる……
A RealWorld Comparison of Front-End Frameworks with Benchmarks (2019 update)
https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

**デフォルトの名無しさん** · 2019/04/11(木) 23:55:39.98

>>349
AngularJSは確かにダントツで遅いけどAngularは別に悪くないじゃん

**デフォルトの名無しさん** · 2019/04/12(金) 00:57:20.94

>>349
hyperAppもなかなか。

**デフォルトの名無しさん** · 2019/04/13(土) 12:59:41.28

SPAでログイン画面というかログイン機構作る場合はどうするのがベストプラクティス？認証用のアカウント情報はサーバー側のDBにあるとして

**デフォルトの名無しさん** · 2019/04/13(土) 13:42:39.23

>>352
使ってるフレームワークとやりたい事で変わるからなんとも。。
例えばログイン後は各ユーザ用の専用ページがあるって感じ？でなければセッションに保存して分岐するだけで済むはずだが。

**デフォルトの名無しさん** · 2019/04/13(土) 14:51:30.35

Angularは脂肪確定でよろしいか？
ReactかVue.jsの二つやっとけはいいのかな

**デフォルトの名無しさん** · 2019/04/13(土) 16:25:49.51

>>354
俺も悩んでる。普段reactとvue(nuxt)使ってて、今angular勉強中なんだが乗り換える必然性が見つからん。もちろんangularは力技使わなくても色々解決出来そうな感じで良さげなんだが。
ただもう少し勉強せんと冷静な判断できんわ。

**デフォルトの名無しさん** · 2019/04/13(土) 16:36:03.16

>>352
Firebase Authentication使えばよくあるGoogleアカウントでログインだのFacebookアカウントでログインなんかが出来るよ。

面倒くさいDBでのアカウント管理も全部Firebase上で出来るから実装に無駄な時間を掛けなくて済むよ。

**デフォルトの名無しさん** · 2019/04/13(土) 17:51:56.66

Google I/O 2019 (5月7日～9日)で
Angularと対立することになる Flutter for Web (Hummingbird) の新たな発表があるそうだから
Angularを考えるのはその後にした方が良いと思うよ

**デフォルトの名無しさん** · 2019/04/13(土) 21:46:54.35

>>357
Flutter面白そうだね。たしかにクロスプラットフォーム開発はスタンダードが無いから学習するなら狙い目なのかも。現状swiftとkotlinでゴリゴリ書いてるけどどうしてもrealmが必要なんだよね。
Webアプリの弱点の一つオフラインDBをある程度解決できるなら真面目に検討したいんだが。

**デフォルトの名無しさん** · 2019/04/13(土) 21:50:11.69

>>358
オフラインDBが弱点って具体的にどういうこと？

**デフォルトの名無しさん** · 2019/04/13(土) 22:53:34.64

>>359
ユーザデータを大量に保存してローカルで処理する系のアプリは現状webアプリだと厳しい。主に速度面で。
indexedDB+lovefieldみたいな組み合わせでsqlぽい事はできるけど、flutterがアプリ+webのクロスを狙うならソコどうするのかなって。DBの同期まではできなくても、一つのスキーマから全プラットフォームで動作するDB作れたら夢だよね。

**デフォルトの名無しさん** · 2019/04/13(土) 23:59:03.97

もういい加減 "ウェブアプリ" なんてやめればいいのに
ローカルでデータを大量に処理ってそれ、
ウェブである理由はアプリのインストールとアップデートのためだけじゃん

**デフォルトの名無しさん** · 2019/04/14(日) 00:10:50.46

サーバーでやっちゃだめなん？

**デフォルトの名無しさん** · 2019/04/14(日) 00:30:22.71

モバイル端末のストア経由っていうのが煩わし過ぎるからなぁ

**デフォルトの名無しさん** · 2019/04/14(日) 00:45:03.08

>>360
ごめん、おれの経験不足なのかやっぱわからん。

>>ユーザデータを大量に保存してローカルで処理する
↑
クライアントは1台だけなのに、速度が気になるほどデータを処理する例が全く思い付かない…

**デフォルトの名無しさん** · 2019/04/14(日) 01:13:17.48

バックエンド主義の人が強引に考えたついた難癖にしか見えない
フロント処理で充分

**デフォルトの名無しさん** · 2019/04/14(日) 08:24:48.36

いやまあ、別に現状でも工夫すればできるからブラウザのローカルDBにそこまでこだわっては無いよ。課題も多いし。ユーザがいつでも削除できるとか。
ただネイティブアプリとwebアプリが同じコードとロジックを共有するなら避けられない課題だろうなと。

**デフォルトの名無しさん** · 2019/04/14(日) 10:03:52.66

ユーザーが自由に削除できることが課題？？
世の中のソフトウェア殆どがそうだけど何か困るのか？

**デフォルトの名無しさん** · 2019/04/14(日) 11:45:21.51

ほんと早くMac死んでほしい

**デフォルトの名無しさん** · 2019/04/14(日) 13:07:21.11

>>367
indexeDBのことだよ。ブラウザのキャッシュクリアで簡単に消えちゃうだろ。間違えて消してクレームくるんだよ。

**デフォルトの名無しさん** · 2019/04/15(月) 12:25:48.71

Reduxわかんね

**デフォルトの名無しさん** · 2019/04/15(月) 18:58:19.12

>>370
大丈夫。俺もわからん
てか、あんなの小規模なWebアプリケーションにはいらん

**デフォルトの名無しさん** · 2019/04/15(月) 20:20:50.21

Reduxわからんの？
かわいそうに

**デフォルトの名無しさん** · 2019/04/15(月) 20:23:02.95

Reduxわかるの？
じゃあ、Reduxを使うことで、
どんなメリットがあったか教えて

**デフォルトの名無しさん** · 2019/04/15(月) 20:25:51.20

処理の流れが一方向なのでわかりやすい。

**デフォルトの名無しさん** · 2019/04/15(月) 20:33:46.03

> 処理の流れが一方向なのでわかりやすい。

文章がつながってない。
処理の流れが一方向なのはまだいいとして、
なんでそれで、わかりやすいということになるのか？

そもそも "処理の流れ" が一方向であるならば、
何を使っても一方向にしかならないはず。
Reduxを使うことで、一方向になるわけではない。

また双方向とか一方向というのは、局所的に見るか
全体的に見るかの違いでしかないのではないか？
例えば電話での会話だって、双方向に見えても、実際には自分の通話口から
相手のスピーカー、相手の通話口から自分のスピーカーへの一方向通信だ。
一方向も双方向も大した違いはない。

**デフォルトの名無しさん** · 2019/04/15(月) 20:40:44.13

まあ実際、説明の難しいところではある。
>また双方向とか一方向というのは、局所的に見るか
>全体的に見るかの違いでしかないのではないか？
これはその通りだがその違いが大きいとしか言いようがない。
treeをたどるロジックというのは一般に指定が複雑になりやすいとか、
ノード間のコミュニケーションがコールバックでつなぐと相当複雑になるとか
色々あるけれどその辺を単純化できてるようには思う。

電話の比喩を持ち込むならマイクとスピーカーが同じより違った方が良いとかになるのかな？

**デフォルトの名無しさん** · 2019/04/15(月) 20:43:17.24

もう少し具体的な例を出そう。

getterとsetterと言えば、俺が言いたいことが見えてくると思うが
Reduxが言いたいことは、単にgetterは値を取得するだけ
setterは値を入れるだけにしましょうってことだろう？
まあgetter/setterは別の批判も有るから、getter/functionの方が良いか？

もう一つの例としてRESTで例えるならば、GETは何度GETしても状態は変わらない。
単にデータを取得するだけ。POSTはデータを送信するだけ。
この考えかたと同じことだろう？

これをオブジェクト指向に当てはめるならば、このメソッドはデータを更新し、
このプロパティはデータを参照するという話でしか無い。
これは普通のオブジェクト指向のベストプラクティスとなんらかわりはないんだが、
Reduxを使う必要はあるのか？このメソッドはGETかPOST（相当）であると
ドキュメントに書けば済む話だろう？

**デフォルトの名無しさん** · 2019/04/15(月) 20:49:52.40

マイクとスピーカーで分けたほうが良いという考え方は
反対しないが、まともな設計能力が有るならば、最初からそうしているわけで、
Reduxを使う理由にはならない。

まともな設計能力がない人のための矯正器具=Reduxということか？
だが矯正器具はいつまでも使っているわけじゃあるまい？
まともな設計能力がついた人にとっては、邪魔な道具でしか無い。

**デフォルトの名無しさん** · 2019/04/15(月) 20:53:26.60

>>378
そうだね。あなたはredux使う必要ないと思うよ。
あなたの素晴らしい設計でやりくりすれば問題ないんじゃないかな。

**デフォルトの名無しさん** · 2019/04/15(月) 20:58:32.77

もちろん、Reduxが何の負担もなしに、もしくは低い負担で
ベストプラクティスを実現できるというのなら導入する価値はあるが、
一方向を得るために、Reduxのやり方で設計しろっていうのは負担が高すぎる。
Reduxのやり方はルールが多すぎて単純ではないからだ。

Reduxの設計方針を理解しないまま、Reduxを使うよりも
まずは知識をつけるのが先だろう？

このメソッドは書き込みを行うメソッド、このメソッドは読み込みを行うメソッド
明確に分けたほうが良いと。そしたらあとはメソッドのコメントに書けばすむだろう？
（普通はコメントで書くまでもなく、メソッド名からどちらであるかはわかる）

それだけのことなのに、それを矯正するためのフレームワークというのは
意味不明すぎる。便利にするためのものじゃない。矯正するためのもの
まったくもってReduxはわからん。

**デフォルトの名無しさん** · 2019/04/15(月) 20:59:53.90

スパゲッティになるならreduxは必須
でもそうならないなら本当に必要ない、とは思う
コード量多くなるからね

**デフォルトの名無しさん** · 2019/04/15(月) 21:02:11.16

>>379
> あなたの素晴らしい設計でやりくりすれば問題ないんじゃないかな。

だから聞いたんだよ
「どんなメリットが"あったか"教えて」

どんなメリットが "あるのか？" じゃない。"あったのか？" だ。
あんただってそれなりにまともな設計ぐらいできるだろう？

あんたの能力がどれくらいで、Reduxを使うことで
どういうメリットが、あったんだ？なにかを矯正されたんか？
俺は矯正が必要なほど設計が下手なつもりはないんだが。

**デフォルトの名無しさん** · 2019/04/15(月) 21:04:00.12

とりあえずメリットは書いたし、びっくりするほど文章読んでないのも理解できる。

**デフォルトの名無しさん** · 2019/04/15(月) 21:06:15.53

Reduxがやってるのって、

1. オブジェクト指向のクラスがあります。
2. クラスから読み込み専用メソッドを抜き出します。
3. クラスから書き込み専用メソッドを抜き出します。
4. クラスに残ったものはデータのみです。これを一つのオブジェクトとしてPublicにします。

オブジェクト指向のクラスが、
読み込み専用メソッド、書き込み専用メソッド、データの３つに分離されました。
ってだけだからな。

**デフォルトの名無しさん** · 2019/04/15(月) 21:07:20.84

>>383
いうだけなら誰でもできる。
コミュニケーション取ろうぜｗ

**デフォルトの名無しさん** · 2019/04/15(月) 21:33:29.21

処理をAPI化するイメージかな必ずその経路を経由して状態を変更するからグローバル変数みたいなどこからでもアクセスできるけどちゃんとアクセス経路は限定できるみたいな

**デフォルトの名無しさん** · 2019/04/15(月) 21:36:35.56

その "グローバル変数" をクラスにして、APIをクラスのメソッドにすれば
普通のわかりやすいオブジェクト指向設計になるんですが？
Reduxの存在意義って？

**デフォルトの名無しさん** · 2019/04/15(月) 21:40:15.54

そしてReduxは、クラスのメソッドを抜き出すだけじゃないからね

メソッド（関数）は普通にメソッドに引数渡して普通に呼び出せるが、
Reduxは「引数つきでメソッドを呼び出すため」のデータを作って
データを投げて、そのデータ解析して（←ここ自分で作る）
そしてやっとメソッドを呼び出すという無駄なことをしてる。

**デフォルトの名無しさん** · 2019/04/15(月) 21:46:24.27

結局の所 Redux はわかりやすいものではなくて
（わかりやすい = ただのセールストーク）
オブジェクト指向 VS 関数型（？）の戦いから
俺たちはアンチオブジェクト指向で行くぜ！という派閥から
生まれたものに過ぎない。

それ自体は考え方の違いでありだとしても、
Reduxの仕組みは、それを実現するためのルールが多すぎて
百歩譲ってわかりやすいとしても、そのルールに従って
コーディングするためのコストが大きすぎて小さいプロジェクトではペイしない
（大きいプロジェクトでもはたしてペイできるかどうか）

"設計方針の違いを反映させるためだけ" でしかなくて、
それしか得られない割に、コストが大きすぎる

**デフォルトの名無しさん** · 2019/04/15(月) 21:55:58.52

別にコールバックでdom treeたどるのが大変でないならredux使う必要ないわな。
それでいいと思うよ。
てか読んでないのにコミニュケーションを要求するとか
まともに設計できる人間じゃないことはわかるよ。

**デフォルトの名無しさん** · 2019/04/15(月) 22:15:47.71

一度Reduxで作ってみたら後は別のプロジェクトでも同じように作ればいいだけだから何も問題はない
最初だけ複雑に思うだけ

**デフォルトの名無しさん** · 2019/04/15(月) 23:37:35.47

確かにreduxのproviderとconnectの対応は暗黙な繋がりでわかりにくいところはあると思うんです。
reduxというかfluxの実装として他に方法はあるかもとは思う。

**デフォルトの名無しさん** · 2019/04/15(月) 23:45:03.60

vue公式からの引用で恐縮だが、、

もし、あなたが大規模な SPA を構築することなく、Vuex を導入した場合、冗長で恐ろしいと感じるかもしれません。そう感じることは全く普通です。
あなたのアプリがシンプルであれば、Vuex なしで問題ないでしょう。単純なストアパターンが必要なだけかもしれません。
しかし、中規模から大規模のSPA を構築する場合は、Vue コンポーネントの外の状態をどうやってうまく扱うか考える絶好の機会です。Vuex は自然な次のステップとなるでしょう。これは Redux の作者、Dan Abramov からの良い引用です:
Flux ライブラリは眼鏡のようなものです: それらが必要になったときに知るのです。

**デフォルトの名無しさん** · 2019/04/16(火) 00:27:12.19

まあ大きなもの作ったことない人にはわからん世界だと思うよ。俺も学生の頃はフレームワークの必要性とかさっぱり理解できなくて制作者の自己満足だと思ってたもん。
そして必要になったことがない人にはどんなに説明しても納得してもらえないもんだよ。

**デフォルトの名無しさん** · 2019/04/16(火) 00:30:35.35

今軽くReduxググってみたけど何がしたいのかさっぱり分からんｗ
jsにprivateが無いからsetter/getterのレイヤー作ってんの？

**デフォルトの名無しさん** · 2019/04/16(火) 00:42:55.64

いやfluxで調べたら少しわかった
オブジェクト指向でいちいち相互参照とか面倒くさいから
シングルトンにデータ全部詰め込んでおこうぜ見たいな話だな

**デフォルトの名無しさん** · 2019/04/16(火) 02:31:52.71

おまいら、vueの利点として、サイトの一部分のjQueryで
作っていた部分をちょこっと置き換えるのに良いって
言ってるくせに、それがいつか大規模なSPAに変わると思ってんの？

**デフォルトの名無しさん** · 2019/04/16(火) 02:40:36.60

>>393
こっちのほうがわかりやすくね？ｗ

Flux ライブラリはサスペンダーのようなものです: それらが必要になったときに知るのです。
（意味デブになれば必要な理由がわかる。だがそもそもデブになんかならねーし、デブなのが一番の問題）

**デフォルトの名無しさん** · 2019/04/16(火) 04:49:30.73

猫も杓子もreduxだけどほかのflux実装の感想聞きたいわ
それなりの規模で使用した、もしくはしてるみたいな人おらんの?
つかfacebookはfacebook/flux使ってるのかね
メンテされてる感じせんけど

**デフォルトの名無しさん** · 2019/04/16(火) 07:41:32.20

>>397
そんなこと書くと議論がすり変わりそうだぞ。
ID:IXPbMXJWが書いてくれたことで十分でしょ。それで納得できる人もいればできない人もいる。
万人が使うものでないことは間違いないわけだし。それはスレタイの3つがそもそもそうなわけだけど。

**デフォルトの名無しさん** · 2019/04/16(火) 08:31:26.34

よくまとまってる。
https://mizchi.hatenablog.com/entry/2018/10/04/101308

> Middleware に何を使うかで、 redux ユーザー同士の非同期のノウハウは共有できず、
> 分断されている(thunk, saga, steps, epic, no middleware)
これが一番の問題点。

**デフォルトの名無しさん** · 2019/04/16(火) 08:57:52.42

>>401
suspence来たら全部ゴミ。

**デフォルトの名無しさん** · 2019/04/16(火) 14:12:45.48

suspence見たけど状態管理をsimple-cache-providerに移動しただけな感じがする

明確なIDが無いリクエストみたいなのが渡ってくる場合だと
コンポーネントと非同期キャッシュの対応付けが面倒になりそう

コンポーネントインスタンス毎に一意ID生成してstateに保持だと本末転倒な感じだし

**デフォルトの名無しさん** · 2019/04/17(水) 11:15:37.77

静的サイトジェネレーターでBlog作りたいのだが情報少ないね。
VuePressがよさげなのだが