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/21(木) 17:02:23.80

ヒステリーAPIを使え

2019/02/21(木) 17:08:39.36

ヒストリー使ってるんだけど

・createBrowserHistoryライブラリ（IE対応のため）
・redux
・react-redux
・connected-react-router

これら使ってなんとか構築してるんだが一つしか履歴残らん

てか解説サイトがほとんどない…

2019/02/21(木) 18:31:50.74

>>516
ヒステリーAPIは草

2019/02/21(木) 20:33:12.61

>>515
これのexampleの構成をよく見た方がいい
https://github.com/supasate/connected-react-router

2019/02/22(金) 03:02:07.44

>>516
まあまあ
落ち着けよw

2019/02/22(金) 12:59:46.42

とりあえずhistory直す
なんかわからんがLink使うとhistoryの履歴が3つ登録される
SPAはここがめっちゃめんどくせぇ
なんでブラウザの操作までjsで組まなきゃいけないんだか

2019/02/22(金) 13:22:14.53

てかｵｯﾍﾟｹってReactマスターやなかったんかい

**デフォルトの名無しさん** (ｱﾒ MMc9-K3Le) · 2019/02/22(金) 13:32:15.20

別にSPAにせず普通にページ遷移してもいいんだがな。誰もやらないだけで。したがってサンプルも転がってないｗ

2019/02/22(金) 14:06:18.79

>>522
すまん、App.jsのコンストラクタ内でthis.props.history.listen使ってしまっておった
これやめたら直りました
dispatchで初期化するのにつかってたのが間違い

2019/02/22(金) 21:03:06.66

>>519
サンプルここにあんじゃん

2019/02/22(金) 21:06:35.12

Reactはホント人によって使うフレームワークやライブラリが全然違うな。
ちょっと興味あったけど、これじゃどっから始めたらいいか全然分からん。

てか、ReduxだのNextだの、第三者が作ってるであろうフレームワークの開発なりサポートなりが終わってしまったら、代わりはどうすんだ？

2019/02/22(金) 21:14:42.59

極力公式か大きめの企業がメンテしてるものだけで作る
コミッタが少ないものは使わない
ライブラリへの依存が散らばらないよう自コードで軽くラップして使う

2019/02/22(金) 21:19:43.61

まぁ本当にSSR必要かってのもあるけどね
最近自分の関わってる案件だと会員サイトの認証済み領域の情報は一切検索エンジンにヒットさせる必要ないからSSRとは無縁なんだよな

2019/02/22(金) 21:24:17.86

スペシャルスーパーレア？

2019/02/23(土) 00:29:55.26

>>526
大丈夫。その前にReactが終わる。VueもAngularも
あと数年後は今存在してないフレームワークが使われてるよｗ

2019/02/23(土) 07:14:02.54

数年後も残ってるのはjQueryだけ
MVC+jQが正解なんだよ

2019/02/23(土) 09:37:08.18

いやreact vue angularについては長生きすると思う。ここ数年は本当酷かったフレームワーク戦争も落ち着いたしあと5年は使えるんじゃないか？ようやく腰を据えて安心して学べる状態になった。

2019/02/23(土) 10:08:06.99

あとたった5年（笑）

2019/02/23(土) 10:16:15.94

お前ら、RADツールって知ってるか？
ウェブの世界じゃあまり知られてないかもしれないが
デスクトプアプリの世界じゃ20年以上前から存在してるものだよ
VBとか有名だな

で、reactなどは近い将来RADツールに置き換わる。
RADはツールであってフレームワークではないから
正確に言うとRADツールを作りやすいフレームワークになるということ

コンポーネントは作ってパーツとして使える。
使いやすいコンポーネントが最初から揃っている。
GUIでマウスで操作するだけで簡単にコンポーネントが配置できる
まあここまではUIエディタ（HTMLエディタ、JSXエディタ）と
変わらんわけだがここからがJavaScript

コンポーネントを選ぶんで書きたいイベントを選ぶとイベントハンドラが生成される
自分で紐づけとかしなくて良いんだよ。JSXとか書かなくていい。
イベントハンドラ名もデフォルトで自動生成、プログラマはイベントの中身を書くだけ
データのバインドとかもRADツールで紐付けるべきものの名前を書くだけ

20年前のVBはすでにこういった世界だったんだよ？

2019/02/23(土) 10:34:55.14

だが滅んだ

2019/02/23(土) 10:55:53.84

マウス1つでレスポンシブデザインまで対応出来るなんて
夢みたいなツールじゃん

2019/02/23(土) 11:17:14.46

レスポンシブはブレークポイントを複数定義して
デフォルトからの差分みたいな感じでデザインするんだろうね

2019/02/23(土) 11:17:41.85

選択肢の一つをあたかも統合されるかのような詭弁はNG。
ポトペタASP.NETが密結合過ぎてわざわざOSS界隈に歩み寄った歴史を思い出せ。

2019/02/23(土) 11:25:13.71

技術がなく判断できない企業はノンプログラミングという言葉に騙されやすいのだろうね

2019/02/23(土) 11:32:23.19

>>539
WIXはそんなに悪くないが一般的には酷いの多いよね

2019/02/23(土) 12:15:44.69

>>539
ノンプログラミングはだめだろうね。
今のRADはGUIのエディタで作ってもいいし、
コードで書いたとしてもGUIに反映されるようになってる

2019/02/23(土) 12:23:17.31

>>538
Web Formsね

**デフォルトの名無しさん** (ｱﾒ MMc9-eq4B) · 2019/02/23(土) 12:37:28.79

WebFormは一瞬でページ作れるから
ものによっては便利だが

2019/02/23(土) 12:41:54.25

単純なページはスキャフォールディングでええやんけ

2019/02/23(土) 12:45:12.12

スキャフォールディングはページを作るものではなくて
ベージの一番最初のコードを生成するだけです。
その後に生成したコードを修正して作っていかなければいけません。

2019/02/23(土) 12:52:56.11

修正すればええやんけ
ポトペタより簡単でソースも綺麗やで
ポトペタなんてマウス操作とアイコン探しの悪魔的苦行の繰り返しやないか
あれが楽とかマゾでもよう言わんで

**デフォルトの名無しさん** (ｱﾒ MMc9-eq4B) · 2019/02/23(土) 13:01:24.38

いやちゃんとしたい時はMVCなんだが
WebFormの存在理由もそれなりにある

**デフォルトの名無しさん** (ｱﾒ MMc9-eq4B) · 2019/02/23(土) 13:09:09.75

さすがにVueとかにはくっつけられないから
スレ違いだったな
RazorPagesはくっつくかな

2019/02/23(土) 21:37:53.78

>>538
MVCやSignalRも知らないおバカさん

2019/02/24(日) 02:35:29.23

>>549
RADの話が出たからWebFormsみたいなクソが消えた歴史を考えろっつってんのに、何がSingnalRだよ。文脈読め。

2019/02/24(日) 02:58:24.82

>>550
ASP.NET=Web formsっていう発想自体が頭おかしいんだよ

2019/02/24(日) 03:19:47.26

お、お、お、おちけつよ！

2019/02/27(水) 15:11:35.98

Reactというかredux？見てて思うのは、
お前らネットワークプロトコルでも作ってるのかよって話

普通にメソッド実行すればいいのに、
パケットデータ作って、そのパケット解析して処理実行する
メソッド一つ実行すりゃ終わりなのに

関数型にしたいのかどうか知らんが、目的を履き違えてる。
バグを減らすために関数型にする。そのために複雑にしてバグを作りやすくしてどうする
関数型じゃなくていい、バグを減らすためにシンプルにしろよ

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なんてゴミを使ってるヤツが居ることに驚きなんだか