Vue vs React vs Angular

2018/12/21(金) 21:37:36.86

実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2019/02/27(水) 15:24:17.37

>>553
しかしflux概念は世界的に認められてるから広く使われるわけで、キミの主張vs世界中の開発者の同意でキミが勝てるわけないよね
そのへんどうすんの？

2019/02/27(水) 16:07:14.12

反論しないで、世界に広める方法を聞く
変なレスだなぁｗ

2019/02/27(水) 16:34:28.95

ところでさ、

function foo() {
　return { hoge: 1, hage: 2 };
}

expect(foo()).toEqual({ hoge: 1, hage: 2 });

みたいな意味のないテスト書いてないよな？

固定の連想配列返す関数のテスト書いても意味ないぞ
二度手間なだけで、それを避けるためにどうせコピペするんだろうし

2019/02/27(水) 17:20:11.35

>>553
メソッド実行するって具体的にはどういう形？

dispatchの前処理と後処理を自分で追加したメソッドを
ストア(↓)に生やすようなのをイメージしたけど合ってる？
https://github.com/reduxjs/redux/blob/master/src/createStore.js

2019/02/27(水) 17:45:18.46

>>557
ようするに、

Actionみたいな「処理の内容をパラメータ化したオブジェクト」を
いちいち作らせるのをやめてくれ、

Reducerみたいな、switchでActionのパラメータみて分岐して処理する
ようなおのをいちいち作らせるのやめてくれ

ってことだよ。

onclickにincrementメソッド書いたら、+1するincrementメソッドが呼ばれます。
でいいじゃねーか。直感的だろ？それで別にテストできないわけじゃないんだし

2019/02/27(水) 17:50:17.86

IOモナド不要論に近いものを感じる
単にReactを選択しなければいいだけなのにね
選択肢の中に一つでも気に入らないものが混じってると全否定を始めるんだからもう

2019/02/27(水) 17:53:11.18

IOモナド不要論というか、IOモナド至上主義じゃないってだけ
副作用排除は素晴らしいよ？でも複雑にしてまでやることじゃない。
バグは副作用でも増えるだろうが、複雑にしても増えるんだよ
書くものが増えれば増えるほど、書き間違いも増えテストも増えるんだから

2019/02/27(水) 17:58:32.64

>>558
その形なら単にReduxを使わなければ良いだけでは？
使用を強制されてるのなら何とも言えないけど

ちなみにうちは本開発でReduxを使ってない
別に嫌ってるわけでもなく、とりあえずバニラなReactでやってるうちに
Contextが来たのもあって特に入れたい状況にもならずって感じ

2019/02/27(水) 18:03:11.05

>>561
たぶんReduxは捨てろって流れになるだろうね。
それが可能になるContext

行き過ぎた関数型ブームなんだろうな。
だいたい行き過ぎて戻ってやっと最適な状態になる。

あと別に使用を強制されてない。
React自体使ってないものｗ

2019/02/27(水) 18:13:46.28

>>553
ていうかまず状態って言うほどサイト全体で持つ必要あるのか？って思うね
大体の場合はコンポーネントの中で閉じててもいい場合が多いし
本当にサイト全体で持ちたいデータはリロードとかて吹っ飛ばないようにlocalstrageにでも書いた方がいいんじゃないかとか

2019/02/27(水) 18:21:13.76

遷移して戻ってまだ編集内容が残ってると逆に気持ち悪い

2019/02/27(水) 19:19:39.92

どのコンポーネントが状態持ってるのか探す方がめんどくさいじゃん。

**デフォルトの名無しさん** (ｱﾒ MMc9-K3Le) · 2019/02/27(水) 19:36:24.78

reactは好きだけどreduxめんどくさい論は大賛成！
hooks + contextに大期待！！

2019/02/27(水) 20:01:14.80

>>565
その部品の情報がその部品で閉じてるなら探す必要ないじゃん？

2019/02/27(水) 20:20:53.09

Redux使わずcontextAPIのみでアプリ作ったけど、なかなか良い感じ
シンプルisベストだね

2019/02/27(水) 22:38:29.67

マルチページ+Vueがベスト

2019/02/27(水) 23:30:28.79

>>567
その部品で閉じるような状態ならな。
二つ以上の部品にまたがる状態だってあるだろ。

2019/02/27(水) 23:47:31.09

だから2つ以上の部品にまたがる所だけで良くなるだろ

2019/02/27(水) 23:49:27.29

reduxなんて面倒くさいレベルに入らないだろ
しょぼいシステムしか作ったことがないんだろうが

2019/02/27(水) 23:52:10.20

>>571
その分け方がわかりやすいと俺は思わん。アドホックな部分が増える。

2019/02/28(木) 00:01:04.44

>>572
つまりあなたも面倒くさいって思ってるわけですよね？
このぐらいのレベルなら耐えられるって言ってるだけだし

2019/02/28(木) 00:13:22.40

Reactそのものが面倒だと思う
サーバーサイド一本の人が移動してきて、Reactのコンポーネント一つ任せたら、onclickで画面をエフェクトさせるのが出来ないとブーたれてた
cssと組み合わせてやるんですよと教えたけど、デザインとロジックが分離されてない糞フレームワークだと文句ダラダラ
結局Reduxのところだけ担当してもらった
サーバーサイドだけの人はこの世界では使い道がない

2019/02/28(木) 00:24:32.39

それはサーバーサイドしか知らないのに画面のエフェクトだデザインとロジックの分離だ言う
その人個人の問題なんじゃないかね。

2019/02/28(木) 00:30:03.58

デザインとロジックが分離されてないのは本当だろ

2019/02/28(木) 01:39:22.43

>>574
こんなのより何千倍も面倒くさいプログラミングしてきてるから面倒くさくねえ部類って言ってんの
頭イカれてんのか？

2019/02/28(木) 06:14:57.31

何千倍も難しいって、口調が前にどこかのスレで見たような気がする
確か自称ゲームプログラマーじゃなかったけ

私大文系はクズだのヴァカだの幾何学的計算が出来れば高卒でも理系とか意味不明な発言の人だった

2019/02/28(木) 06:16:05.22

バカじゃなくてヴァカという変な単語を連呼してたので覚えてる

2019/02/28(木) 06:50:50.42

てかテキストボックスのチェンジイベントでイチイチReducerだかDispatcherだかを経由してストアに書きに行くもんなの？
確定ボタン押した時でよくない？

2019/02/28(木) 06:55:29.34

>>577
デザインとロジックが分離してない上にVueみたいにコンポーネントとして独立するわけでもないっていう中途半端さがね

2019/02/28(木) 08:52:57.67

落ち着け、議論を飛び出してケンカになってるぞ。そこまでくると他の人に迷惑だから頼むから我慢して2、3日スレから離れて観て欲しい。

2019/02/28(木) 08:57:16.34

>>583
ビビんなよ。5chではよくあることだろ

2019/02/28(木) 10:41:44.71

ビジネスロジック→Service(バックエンド)
プレゼンテーションロジック→ViewModel(js)
デザイン→View(html/css)

サーバーサイドおじさんはプレゼンテーションロジックがお気に召さないらしい
ビジネスロジックとデザインだけで完結するMVCフレームワークが人気

2019/02/28(木) 10:50:58.35

>>585
そこに、ActionとAction CreatorとReducerとStoreは
どこに含まれるの？って話だよ

アーキテクチャ上、必要ないものが多すぎる

2019/02/28(木) 12:22:34.05

>>586
分類するなら全部プレゼンテーションロジックだろう
SPAとかいう誰得要件のせいでプレゼンテーションロジックが過剰に肥大化複雑化してしまった結果それらが産まれた
従来のマルチページに戻すだけでスッキリ解消される

2019/02/28(木) 12:46:03.68

誰得っていうけどブラウザアプリ作るならSPAの方がUXが劇的に向上するケースが殆どじゃないか？

2019/02/28(木) 12:49:53.87

UXが向上したということにしたいだけでは？
案外ユーザーはシンプルなMVCのほうが簡単で良いと思ってるものさ

2019/02/28(木) 13:05:42.47

シンプルなMVCかどうかの判別ってユーザーからできるの？ユーザーってもしかして顧客のこと？

2019/03/02(土) 15:08:24.35

年明けてから二ヶ月経過したけどなんだかんだ書籍出てるな
売れてるんかねぇ

動かして学ぶ！Vue.js開発入門 (NEXT ONE)／翔泳社／森巧尚／2019/1/15発売／ISBN-13: 978-4798158921
Vue.js & Nuxt.js超入門／秀和システム／掌田津耶乃／2019/2/5発売／ISBN-13: 978-4798056593
AngularによるモダンWeb開発基礎編第2版／日経BP社／末次章／2019/2/23発売／ISBN-13: 978-4822254537
React.js&Next.js超入門／秀和システム／掌田津耶乃／2019/3/8発売／ISBN-13: 978-4798056920

2019/03/02(土) 16:45:37.50

ウチの会社でReactのアプリを独自UIの新規開発からロジック周りまで全部できるPGは一人しかいないわ
オフショア入れて百人以上PGいるけど、みんなFlexbox使って自分でUI書けませんとか、エフェクトのアニメーションを自作できませんとか、htmlとcssで躓いてる
デザイン系が得意なPGだと今度はDBやAPIが良く分かりませんという風になる

デザインとロジックの分離が不完全なので不器用な奴には使えない
結局Reactのアプリ制作はその一人が設計構造を考えて何人かで分担して作ってる
その一人がいなくなったら改修も容易ではない

2019/03/02(土) 16:52:47.42

>>592
そう最低限なんでもできるリーダーがいなきゃ初期導入すら始まらんもんな
浸透すらしてないのにフロントとバックを分業分業言い過ぎだとは常々思ってる

2019/03/02(土) 17:18:02.29

html5で独自属性を使うときはdata-*で命名する規則になってるけど
どのフレームワークも無視してるのはなぜ？

2019/03/02(土) 20:30:41.54

「知りません」は別に問題無いけど「やってみても分かりません」という奴は
PGとも呼べない半人前だと思う
でも多いんだよなそういうの

2019/03/02(土) 20:45:13.26

>>594
その属性はビルド後も残るの？

2019/03/02(土) 21:47:05.25

>>595
「よく分からないけど動いた」

2019/03/02(土) 21:51:40.27

>>592
フロント、バックエンド、DB、インフラからデザイン、写真加工、キャラ背景画作成、アニメーションまでできる俺は頂点に立てるかな？

2019/03/02(土) 22:08:26.00

>>593
> 浸透すらしてないのにフロントとバックを分業分業言い過ぎだとは常々思ってる

一人でなんでもにできる人が居ないから、分業にしないとだめって話なんじゃないの？
Reactでどうやって分業するのかしらんが。

Reactは設計レベルで分業がし辛いフレームワーク

2019/03/02(土) 22:12:30.11

rails、angular、vueなら分業しやすいとでも？

2019/03/02(土) 22:15:55.89

まあそうだね。

RailsのERBはHTMLに近いから編集してもらえるし、
AngularもHTMLベースだから。

ReactとVueはJavaScriptの中にHTMLの断片が埋まってるから
それを修正して思い通りのデザインを作ってもらうのは無理だろう

2019/03/02(土) 22:24:29.37

フロントとバックは分業したほうが楽だ
どっちもできる人は多くない
いたとしても負荷がかかるから無理強いするとブラック企業になってしまう
それに分業といってもAPI(作る|呼ぶ)だけだろう
難しいとこなんて何もない

2019/03/02(土) 22:33:41.00

>>599
逆に分業じゃなっきゃできんってヤツはわざわざ勉強してまで新しい技術を導入したいとかいい出すヤツは居ないっていう話だよ

>>600
なんでRailsねじ込んできた？

2019/03/02(土) 22:40:19.17

>>594
無視ってどういう意味で？少なくともReactのアプリで使えているけど。

2019/03/02(土) 22:46:45.64

阿部寛のHPを構築するならVue、React、Angularどれがいいの？

2019/03/02(土) 22:48:37.42

>>603
意味がわからん。

仕事を一人でやるのは大変だから、分業できるようにしないと駄目って話なんだが？
新しい技術であっても、それで分業ができればいいんだよ。
というか分業ができる技術を導入するべきだ。

2019/03/02(土) 23:11:54.68

この作業がそんなに難しいことだと思えないんだけど、そんなもんかね。
>ReactとVueはJavaScriptの中にHTMLの断片が埋まってるから
>それを修正して思い通りのデザインを作ってもらうのは無理だろう

2019/03/02(土) 23:27:02.72

>>607
難しいかどうかじゃなくてやり方が全く違う。
普通はHTMLとCSSで作るんだから

2019/03/02(土) 23:47:00.54

>>604
確かにReactの場合はそういう書き方やってないよね
独自属性でもclassName以外はonClickとか元の属性と見ても違和感ないし

>>594が言ってるのはvueのv-modelとかv-onとかv-bindとか
angularでもng-modelとかそういう独自属性があるのを言ってるんだと思う

>>594
ちなみにこの辺の独自属性ってフレームワークのコアライブラリで先に処理されて仮想DOMになるからなのか
ブラウザのデバッガでは存在しないものとして表示されないんだよね
今確認したけど<input v-model="msg" />みたいに書いた場合は
ブラウザのデバッガのElements(Chrome)やインスペクター(Firefox)で見ると<input>に変わってる
BootstapのNavbarなんかでよく使うdata-toggleやdata-targetはそのまま表示されてるから
html5の独自属性とは違う位置付けだと考えた方がいいんじゃないか

2019/03/03(日) 00:02:03.36

Vueの独自属性はHTML5準拠やで
なのでdata-*にしなきゃいかんルールなどない

2019/03/03(日) 00:05:23.14

Chromeのvue dev-toolで確認できるんじゃないの

2019/03/03(日) 00:10:23.09

>>611
それ使えば確かに見れるけどElements側に出ないって事は実DOMとしてはレンダリングされてないって事だと思う

2019/03/03(日) 00:17:30.72

単にインスペクターが無視してるだけだ
正しい属性なんだからレンダラが無視するわけにもいかんだろ

2019/03/03(日) 00:43:00.34

>>609
＞v-modelとかv-onとかv-bindとか
そうそう。data-＊ではないカスタム属性ってEclipseに警告だされてすっきりしない
だから実行時に消えるとしてもhtml5のカスタム属性としてはよくない気がする

本来ならxhtmlの名前空間みたいに*:*でカスタム属性を命名できれば良かったんだけどね

2019/03/03(日) 00:48:58.18

未だにEclipseなんてゴミを使ってるヤツが居ることに驚きなんだか

2019/03/03(日) 01:03:17.04

eclipseww

**デフォルトの名無しさん** (ｱﾒ MM3b-zhdC) · 2019/03/03(日) 01:41:00.89

実際レンダーする前のリソースなんだから
しょうがないんじゃないの
VSCodeとかでVue拡張使えばいいじゃん

2019/03/03(日) 01:46:51.51

>>613
v-ifとv-showの違いとか読んだことない？ないものはないんだよ

2019/03/03(日) 08:28:07.07

なんだ、レンダリング前のテンプレートの話か。ならHTML5に準拠してないのは当たり前じゃん。
たしかにXHTMLならその規格に準拠した中で拡張できるけどHTML5はそれと決別したしねぇ。

2019/03/03(日) 09:22:56.48

>>618
正しくDOMとして評価された後にDOMを消してるだけ
拡張属性は正しく評価されてる

2019/03/03(日) 09:29:26.03

>>620
だからその評価がBlinkやGeckoみたいなレンダリングエンジンで評価されるか
V8やSpiderMonkeyみたいなJavaScript実行エンジンエンジンで評価されるかの違いだって

2019/03/03(日) 10:40:12.55

>>608
そこまで違う作業とあんまり思ってなくて、
やってもらうとしてそんなに反感食うもんかなという風に思ってるのだが。
かなり勝手に思ってるだけだから実際の現場感覚はわからんけど。

2019/03/03(日) 11:31:27.74

UIが劇的に切り替わる様な要件じゃ
デザインとロジックを完全に分離とかそもそも不可能じゃないの

2019/03/03(日) 13:57:28.79

デザイン
プレゼンテーションロジック
↑JS+HTML+CSS
--------
↓API
ビジネスロジック

デザインとロジックを分離するって言った場合、分離するのはビジネスロジックのこと
プレゼンテーションロジックを分離するという意味ではない

2019/03/03(日) 15:00:36.37

WebまではHTML+CSSだけ分離も可能だけど
スマホWebアプリ／スマホアプリになってくると動きも含めてのUXという性質が強くなる

UI用ロジックや機能性まで考慮する「UXデザイナー」と
静止画の用意で終わるデザイナーとの差は大きい

Reactは後者のデザイナーとは相性悪いだろうね

2019/03/03(日) 15:07:16.96

デザインもUIもUXもフロントも全部やればいいじゃん
そもそもなんでできないのか不明
フロント勉強してできるようになったのならデザインも勉強すりゃいい

2019/03/03(日) 16:31:53.99

>>626
何でも一人でやる時間があればそうする

2019/03/03(日) 16:40:53.54

少なくとも難しいから分業してるわけじゃないだろうね。効率の問題。

2019/03/03(日) 17:40:54.12

>>627
時間があればじゃなく、必要だからやらなきゃいけないんだよ
最近世界的にもその必要性が言われてる

>>628
効率悪いから一人でやるべきなんだろ

・フロントデザイナはコーディングできない

・フロントエンジニアはデザインできない。デザイン貰ってもセンスゼロだからコーディングで表現できない

https://postd.cc/the-death-of-front-end-developers/

2019/03/03(日) 17:56:55.95

>>629
開発の規模とか体制によりけりだろ。
例えば自分が所属してるとこだと、フルスタックにやれる人にはデザインなんかに凝ってる時間があったら別の仕事やらせたい。

2019/03/03(日) 18:01:05.79

効率でいうなら複数のサイトを作業区分毎に分業するよりも１サイト１人でやる方がよっぽどいいと思うけどね

2019/03/03(日) 18:15:09.19

>>630
>デザインなんかに

そこの認識なんだよなあ
プログラマはデザインわかってないからデザインなんかにという言葉が出てくる

2019/03/03(日) 18:45:41.76

>>632

2019/03/03(日) 18:47:22.33

>>632
うーん、なんか噛み合わないな。デザインは大事だと思うから分業して欲しいと思うんだよね。そしてエンジニアが楽しいからってデザインに凝るのをよくないと思ってる。

2019/03/03(日) 18:49:08.31

>>632
まぁ例えば
プログラミングレベルが１０で
デザインレベルが５とかの人材の場合
どちらかと言えばデザインよりコーディングやって貰った方が効率いいってはあるんじゃない？

2019/03/03(日) 18:51:32.92

>>631
それは否定しないがその人材を安定して確保しようとするといくら払えばいいの？という話にならないか？

2019/03/03(日) 18:54:01.18

>>636
確保するんじゃなくて育てようって気がないのかね
これだから衰退するんだよ

2019/03/03(日) 18:54:24.45

>>634
デザイン凝るっていう判断はどこでしてるの？
仕様として必要ならやるよな
それともそのフルスタックエンジニアの独断でやってるのか、デザインわかってない奴が決めてるのかにもよる

2019/03/03(日) 18:58:26.46

>>637
育てること考えると余計に分業したくなるだろ。2人を両方フルスタックにするのと、それぞれ専門持たせて育てるのどっちが現実的なのか考えてくれよ。
なんか理想論でマウントとられても困る。

2019/03/03(日) 18:59:34.47

人材云々の話は経営者が判断すべき問題であって
勉強しなくていいとかそういう問題じゃないでしょ

2019/03/03(日) 19:01:59.76

>>592みたいに1人が抜けたらヤバイっていう状況はホントにヤバイから
できるうちに育てた方がいいよホント

2019/03/03(日) 19:03:05.35

>>638
まあそれはそうだ。
仕様がガッチリ決まってるようなデザイン作成ってのを見たことないから故の思い込みかもしれんが、UIとなると必要以上に時間がかかってしまうという思い込みが自分のなかにあるのは確かだ。

2019/03/03(日) 19:04:53.82

>>640
勉強すべきかどうかという話だったの？だとしたら俺も勉強すべきだと思うよ。

2019/03/03(日) 19:08:50.10

ちなみに俺は>>630で体制によりけりと書いてるように、少数のとこならエンジニアのスキルや素質に合わせればいいと思ってる。少数でイキのいいベンチャーとかなら有能が多数派ってこともあるだろうしね。
おそらく仕事量に対する有能人材の割合が重要なんだと思う。

2019/03/03(日) 19:17:40.56

規模が大きくて大人数じゃないと作れませんねぇ、じゃあどこで分担しましょうか？

って考えればいい。

2019/03/03(日) 19:35:22.77

業務系だとそういう場合はレイヤーじゃなくてコンテキストで分けるのが主流だね
レイヤーで分ける企業はかつて見たことない

2019/03/03(日) 20:04:17.44

規模が大きくて大人数じゃないと作れませんねぇ、じゃあどこで分担しましょうか？

え？分担したら効率が悪いだろって？

じゃあ、2人で2ヶ月の仕事を、あなた1人で2ヶ月でやってくださいね。
効率がいいんだから2倍ぐらいやれるでしょ？
でも給料は変わりませんから。

2019/03/03(日) 20:12:49.02

>>647
そうなる
エンジニアスキルはできない奴に比べて何倍も差あるからな
だから給料もそれに比例する

2019/03/03(日) 20:33:30.24

> だから給料もそれに比例する

夢見るのやめとけｗ

2人で2ヶ月も、1人で2ヶ月も
働く期間が2ヶ月なら給料は同じだ

2019/03/03(日) 21:11:25.76

スケールしない作業だと言われればそうかもなとしか言えんな。
できるなら起業しとる。

2019/03/03(日) 21:42:00.62

Rails と、Node.js + Express は、全く同じ。
Bundler と、npm, yarn も、全く同じ。
ERB と、EJS も、全く同じ

Webデザイナーの仕事を楽にする! gulpではじめるWeb制作ワークフロー入門、中村勇希、2018/5/29

Node.js超入門、掌田津耶乃、2017

Junichi Ito (伊藤淳一)
Rails 5.1で作るVue.jsアプリケーション～Herokuデプロイからシステムテストまで～
https://youtu.be/ycOeM2umXkY

2019/03/03(日) 22:00:40.86

>>651
死ね

2019/03/03(日) 22:01:29.06

Heroku使うメリットってなに？