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/03/09(土) 22:10:59.54

>>1 おつ

1. jQueryはシンプルに書けるVue・Reactは冗長

証拠 https://jsfiddle.net/t62b49mp/

JavaScriptのコードはこれだけ
$('.my-component [name="switch"]').change(function() {
　$(this).closest('.my-component').toggleClass('active', this.checked);
});

2. 信者「Vueならこれだけで動く！」

嘘1 isActive=false

嘘2 new vue({data:{isActive:false}})
https://codepen.io/anon/pen/MxmrjP （動かない）

嘘3
new Vue({
el: '#app',
data: {isActive:false},
})
https://codepen.io/anon/pen/XGgpZV （変な動きをする）

3. 結論
jQueryはシンプルに書けるVue・Reactは冗長

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

　
Vue vs React vs Angular その2
https://mevius.5ch.net/test/read.cgi/tech/1552122580/

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

実際vueの方がコードは長くなるわけで、
たった2行にバグが有るかどうかと
十数行にバグが有るかどうかでは
考えるまでもないな

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

次はonclickを使う例にしようか？
jQueryだとコードは増えないが
Vueだとさらにコードが長くなる

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

>>1
乙

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

>>1
乙

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

NG用にワッチョイくらいは欲しかったな

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

韓国人のつくったkQuery = Vue

**デフォルトの名無しさん** · 2019/03/10(日) 09:31:42.23

スレタイに入ってるけどAngularのアウェイ感が半端ない

**デフォルトの名無しさん** · 2019/03/10(日) 09:41:01.97

>>10
なんで？

**デフォルトの名無しさん** · 2019/03/10(日) 09:44:10.94

>>10
俺はangularはサンプルいじって放置してるよ。実務で使うシーンが限定というか予定にない。自社でも受注にもない。

**デフォルトの名無しさん** · 2019/03/10(日) 09:49:18.69

>>11
React、VueはJavaScriptでHTMLを作るものだから。
AngularはHTMLをベースにそこに特殊な属性をつける。

**デフォルトの名無しさん** · 2019/03/10(日) 09:50:04.54

>>1
乙！

>>2-5
死ね

**デフォルトの名無しさん** · 2019/03/10(日) 09:55:40.09

1から2への移行、というか再構築の苦労話見るとなあ。個人的に習得すべきかずっと迷ってる。

**デフォルトの名無しさん** · 2019/03/10(日) 09:56:45.26

>>11
今って言うか前スレで殆ど話題に上がらなかったなと

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

>>12
何でAngularってあまり使われないんだろうな。

自由に構成を変えられない分、チームとして協業した時に構成を統一出来るし、
ベースとなるTypeScriptで型宣言出来るから変数に違う型をぶち込もうとしてたらIDEが教えてくれるからバグも少なく書ける。

これだけ大規模開発と堅牢なコーディングに向いてて、何故どこの企業もAngularで開発しようってならないんだろ。

一度Angularで開発始めてしまうと後戻りできなくなるからとか、
そもそもHTML、CSS、Javasceiptしか出来ない人間にAngularは荷が重いからとか？

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

あとバージョン更新が速すぎる
7で安定すんのかな

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

>>17
用途が違うから。

Reactを使ってるのはウェブサイトじゃなくて
ウェブアプリを作ってる。
ウェブサイトはReactでは作りづらい

ウェブサイトはAngularが適しているが、
その程度の用途ならjQueryで十分

**デフォルトの名無しさん** · 2019/03/10(日) 11:18:18.33

>>18
もう8のBetaが来てる

**デフォルトの名無しさん** · 2019/03/10(日) 11:20:50.23

Angular使ってる部署は使ってるな
自分のところで使わないのは、
・大胆に仕様が変わる
・その割りに飽きてポイ捨てするgoogleの体質
で使ってないな
googleの信用問題な気がw

**デフォルトの名無しさん** · 2019/03/10(日) 11:35:33.25

Reactもライフサイクルメソッドとか大幅に廃止になってたりするけどね

**デフォルトの名無しさん** · 2019/03/10(日) 11:46:45.99

まだまだ先とはいえ、GoogleはいずれAngularを捨てて
Flutter for Webを推していくようになると思うぞ

**デフォルトの名無しさん** · 2019/03/10(日) 11:49:48.39

それはReactも同じだよ。
Web Componentsがすべてを置き換える。

まあReactと互換性がないReact Nativeは別だけどな。
React Nativeはアプリ用であってウェブ用ではないし

**デフォルトの名無しさん** · 2019/03/10(日) 11:56:52.21

>>23
AngularDartってのもあるからな

**デフォルトの名無しさん** · 2019/03/10(日) 12:02:33.55

>>17
webの構成要素html、js、cssはとても壊れやすく脆い。altcss、altJSも結局はラップに過ぎん。そして動作するブラウザもどこかで不安定。

だからwebはライブラリやフレームワークが優秀でも堅牢とは言い切れない、どこか不安定な感じが拭えないんだよ。

その上流れの早い業界だから、速攻習得できて早く捨てられる。次に備える。そういうスタイルがwebに合ってる気がしてる。angularには腰が重くなる。

**デフォルトの名無しさん** · 2019/03/10(日) 12:19:44.77

>>26
html、js、cssは登場してから大きく変わることはなく安定してると思うけど？
壊れやすいのはその周辺技術。同じことを違うやり方をしては消えていく
生HTML、生JS、生CSSに近いものほど長く生きている

**デフォルトの名無しさん** · 2019/03/10(日) 13:50:12.38

生たって小規模ならともかくjsの長ったらしいのなんかメンテできないだろ
ちゃんとしたlintツールとかあってチームとかでメンテできるわけで

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

lintツール使ってもjs自体はjsそのものだろ

生じゃないjsというのは、jsをjsではないものにするってこと
例えばCoffeeScriptとかね。

HTMLで言えば、HAMLとかあったがあれも死んだ
HTMLではないからだ。XHTMLもほぼ死んだ状態

jsもAltJSは殆ど死んだ。残っているのはTypeScriptというjs+αという
互換性があるものだけ。

CSSも生き残ってるのは、CSSと高い互換性があるSASSぐらい

標準の構成要素は消えないし、標準から離れれば離れるほど死滅するのが早くなる
ウェブのフレームワークも標準のDOMとは違うやり方をするので、すぐ消えるよ

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

CoffeeScriptにしてもSassにしてもRails由来のものはあんま流行らなかったな
ScssはSassの一形式みたいに言われてるが本来のSass形式が受け入れられなかった結果だしな

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

>>30
俺が言ってるSassっていうのはプロジェクトの名前で
構文自体はScssだからね。

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

インデントスタイルのほうが絶対いじりやすいのに

**デフォルトの名無しさん** · 2019/03/10(日) 15:00:02.28

そんなものよりも互換性のほうが重要だし
テキストエディタの機能で小さな差は吸収される

**デフォルトの名無しさん** · 2019/03/10(日) 15:31:18.74

>>29
AltJsてことね、失礼
TypeScriptはやっぱ便利だね
Vueでもやりたいんだが周りがjsでやろうとするんだよな

**デフォルトの名無しさん** · 2019/03/10(日) 15:34:45.50

>>25
普通に考えれば
AngularはDartでやるべきなんだろうけど

**デフォルトの名無しさん** · 2019/03/10(日) 15:34:57.99

>>32
逆にインデント入れたらダメってルールはないし

**デフォルトの名無しさん** · 2019/03/10(日) 16:02:25.93

>>27
すまん言い方が大雑把だった。エンジンがどうこうじゃなく、最近は減っただけでブラウザ依存は無くなってないし、生cssやdomは貧弱すぎる。

本来の用途ではないのを時代の要求に合わせて無理やり実現してる感が凄い。それをフレームワークやIDEが必死の努力で隠してくれてる。

それは凄く有難いし新技術はワクワクするしvue reactは楽しい。でも独自記法が象徴する様に「コレは一時的なものです。今はこう書きます」というキナ臭さ凄い。ガッツリコミットできない。

**デフォルトの名無しさん** · 2019/03/10(日) 16:28:15.01

でも、なんかこのスレ見てたらangular勉強する気が湧いてきたわ。しばらく独学して判断するよ。

**デフォルトの名無しさん** · 2019/03/10(日) 16:31:35.17

>>38
これからGoogleMapもPWAになるって聞くしな

**デフォルトの名無しさん** · 2019/03/10(日) 20:26:48.77

Vue.jsは仕事で使ったけどイマイチな感じがした。
ちょっと入院するからreact native勉強するつもり。
このままサーバサイドエンジニアに追い込まれて終わらんよ

**デフォルトの名無しさん** · 2019/03/10(日) 22:13:45.27

>>40
どんなところがイマイチ？

**デフォルトの名無しさん** · 2019/03/10(日) 22:13:50.36

>>40
そうだね、pwaは必須になると思う。よりネイティブアプリに近づく流れは避けようがない。
あとスレタイにある様に、現時点でjsフレームワークは3種類に絞られたと言って良いと思う。松茸梅じゃないけど、いい感じに出揃った。腰を据えて松のangular学んで良い時期なのかなと。

**デフォルトの名無しさん** · 2019/03/10(日) 22:15:05.06

ごめん安価間違えた。>>39へのレスでした。

**デフォルトの名無しさん** · 2019/03/10(日) 22:19:55.62

Angularに詳しい人に質問。

個別のコンポーネントで管理されてる状態を表す変数（例えばユーザーが入力した文字情報や、サーバーから取得したJSONデータ）を
コンポーネント間で共有したい場合、どこで保管するのが適切？

最初は単一のserviceに全ページの状態を示す変数をぶち込んで、単一のservice↔各コンポーネント間でデータのやり取りやデータバインディングやってたんだけど、
ページ数が増えるに連れて変数の管理がし辛くなっていったわ。

あと、データがserviceなんかにあるもんだから、データバインディングする際にも各コンポーネントのhtmlにクソ長い名前付けなきゃならなくてかったるい。

実現したいポイントは、

①コンポーネント間のデータ共有
②どのデータがどのコンポーネントの状態を示すのかを明確にする
③データバインディングのコードの書きやすさ

なんだけど、なんかアイディアない？

**デフォルトの名無しさん** · 2019/03/10(日) 22:23:07.40

PWAの実行環境としてウェブブラウザは最適なんだろうか。

**デフォルトの名無しさん** · 2019/03/10(日) 22:29:16.09

前スレでAureliaってのが出てたから試してみたけど
cliでプロジェクト作っても初期状態でnpm startすら碌にできんとか
流石にスレタイの3フレームワークとは同列じゃないなって思った

**デフォルトの名無しさん** · 2019/03/10(日) 22:32:21.87

>>45
PWA=実行環境だよ

ブラウザをベースとしてOSがアプリのように
見える仕組みを追加する拡張されたブラウザ機能のこと

素のウェブブラウザが最適ではないからこそ
OSがその機能を追加してる

**デフォルトの名無しさん** · 2019/03/10(日) 22:41:57.30

>>44
すまん横槍なんだけどangularだけの問題じゃないので。
ネイティブアプリでもwebでもRxを使うのがトレンドだと思うんだが、それではダメ？

**デフォルトの名無しさん** · 2019/03/10(日) 22:57:26.28

>>48
えぇ…駄目って事は無いと思うけど、RxJSで一度取得した情報をページ遷移ごとに再度取得したり、ユーザーが仮で入力した入力情報を一々RxJSで送るって、面倒臭過ぎない？

俺は一度取得したデータや入力したデータはコンポーネント外のどこかに保管して、
データの更新がある時に再利用する、という方法が良いと思うけど。処理的にも通信量的にも。

もちろん、作るものによってデータの扱いは異なるだろうから、俺の考えが絶対に正しいとは思わないけど。

**デフォルトの名無しさん** · 2019/03/11(月) 00:23:57.94

>>49
それは結構範囲が広い問題だねえ。設計思想にも関わってきそうな。ただデータの再利用部分なんだけど、単に通信量を減らすキャッシュ的なもの？なら簡単だろうけど、なにやら複雑そうだね。

**デフォルトの名無しさん** · 2019/03/11(月) 00:26:48.86

>>41
描画し終わった後に呼ぶメソッドはアレとか、前だとコレとかとっつきにくい。
まあriotよりはマシだが

**デフォルトの名無しさん** · 2019/03/11(月) 00:36:16.62

>>44
それがfluxなんじゃないの？

**デフォルトの名無しさん** · 2019/03/11(月) 10:44:37.63

>>49
ブラウザのデータ永続化も絡んでる？

**デフォルトの名無しさん** · 2019/03/12(火) 00:33:48.58

>>53
いやそこまでは。精々ユーザーが使っている間、具体的にはブラウザタブ開いている間くらいで考えてる。

JSONにしてsession storageにぶち込もうかとも思ったけど、データバインディングもしたいから
今んとこはserviceで管理するのが一番無難かなぁと。

**デフォルトの名無しさん** · 2019/03/12(火) 02:23:44.41

Model(Application/Data) <----> View Model (JQuery/AnimeJS/DOM) <----> View(HTML/CSS)

**デフォルトの名無しさん** · 2019/03/12(火) 09:34:20.66

>>54
5chじゃ詳しく話せないと思うんだけど少し範囲が広すぎるから、なにが具体例があると分かりやすい。今までの内容から、storeやrxやstorage,indexedDBでも解決に至らない問題って事だよね。

>データバインディングする際にも各コンポーネントのhtmlにクソ長い名前付けなきゃならなくてかったるい。

ここが核心で他は不便ではない、という事なら解決方法は全然違ってくると思うし。

**デフォルトの名無しさん** · 2019/03/12(火) 10:16:12.94

>>51
俺の場合はReactNativeを仕事で使って、同じようなとっつきにくさを感じたから、今はVueやってる。たぶん大差無いんじゃないかな。

**デフォルトの名無しさん** · 2019/03/12(火) 12:10:25.68

vueのtsサポートってどんな感じ？
普通に使える？

**デフォルトの名無しさん** · 2019/03/12(火) 12:47:29.02

>>58
俺は普通に使ってる。特に問題ないよ。

**デフォルトの名無しさん** · 2019/03/12(火) 22:43:17.38

Fluxってsetterで値をセットし、getterで値を取得しましょうってことでいいの？

それともsetterの代わりに、メソッドで連想配列に値を入れて
getterは使わず、内部構造の連想配列をそのまま取得ってこと？

**デフォルトの名無しさん** · 2019/03/13(水) 00:03:24.50

>>56
「解決に至らない問題」というとちょっと違ってて、やりたい事は出来るんだけど、「もう少しシンプルで書きやすく、分かりやすい書き方はないか」と悩んでる。
今やってる事の目的と具体例を出すと、次の様な感じ。
【やりたい事とアプローチ】
コンポーネント間で画面遷移しても画面の状態が保持されるようにしたい。
そこでコンポーネントではなく、サービスにサイトの状態を保持させる。
【具体例】
『component』
・A.component.ts / html
・B.component.ts / html
『service』
・test.service.ts
　public val: any = null; // Aの状態を保持するメンバー変数。
　
１）TestServiceをA、Bそれぞれのコンストラクタで読み込む。
２）Aのcomponent.tsでデータを取得し、serviceのvalに格納。
this.testService.val = result; // 中身は { res : "OK" }

３）Aのcomponent.html上でデータをバインディングで表示。
{{this.testService.val.res}}

４）AからBに画面遷移。
５）component.tsで、取得したデータをオブジェクトの一部に格納。
var result = { res : this.testService.val.res, num : 123 }

結論としては↑のやり方でAで取得したデータをBで参照する事には成功したが、次の問題が出て来た。
・TestServiceにもっと多くの変数があると、どの変数がどのページの状態を示すかが分からなくなる。
・VS Code だとhtml編集時にtsの補完が効かず、htmlのバインディングの構文
{{this.TestService.val.res}}
を書くのが面倒。

何かズラズラと書き上げてて、だんだん設計がよろしく無い気がしてきたわ。いっぺん設計を考え直してみるわ。

**デフォルトの名無しさん** · 2019/03/13(水) 01:32:34.62

>>61
ちょっと俺もangular勉強中だから近日中に答えるわ。
ただ気になるのが4)のA>Bに遷移した後、リロードが発生したら表示できなくなる気がするんだけど。。urlが同じならAに戻るだけだから問題ないと言えば無い。のかな？
または、A>Bへの遷移後Aは破棄されず再び更新が発生した場合サービス側で注意深く処理しないとせっかくのBのバインドが外れてしまう。
ごめん実装と例は違うんだろうけど、パッと見て気になったところ。

**デフォルトの名無しさん** · 2019/03/13(水) 06:45:39.95

それ
リロードが発生するとデータが消えるのは論外なのでリロードしても大丈夫なようにしないといけない

**デフォルトの名無しさん** · 2019/03/13(水) 07:00:36.64

名前が長くなるのはいやがらない方がいいと思うけどな。シンプルな名前にすると背後に潜む仕組みがわかりにくくなって逆に不安になったりしない？

**デフォルトの名無しさん** · 2019/03/13(水) 07:03:11.66

{{this.TestService.val.res}}

こう書いてあると、他の人が見たときにわかりやすくてよい名前だと思う。

**デフォルトの名無しさん** · 2019/03/13(水) 08:57:38.95

ReduxならlocalStrageのミドルウェアがあったな

**デフォルトの名無しさん** · 2019/03/13(水) 09:40:05.85

現段階での改善案なんだけど、
1:Aのロード部分はサービスへ。
2:AB共にサービスからrx経由で取得。
が基本だと思う。要はコンポーネント内で直接ロードしない。この修正だけで随分見通し良くなると思うよ。
あとはサービス側でキャッシュなり永続化なりお好きな様に。

**デフォルトの名無しさん** · 2019/03/13(水) 11:07:16.09

頑張らなくっちゃ～　頑張らなくっちゃ～
うんちもプリップリッ　おしっこもジャージャー
頑張らなくっちゃ～　頑張らなくっちゃ～ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)

**デフォルトの名無しさん** · 2019/03/13(水) 11:20:41.84

・サービスの根幹に関わる部分はflux概念で管理
・その部分はどのページでリロードしても破綻しないように管理する
・見た目とかリロードで変更されても問題ないstateはそれぞれのコンポーネントで管理

こんな感じかね

**デフォルトの名無しさん** · 2019/03/13(水) 12:36:13.64

リロードしてもステート変わらないの？
何のためにリロードするんだろうな。
そんな糞サイト二度と行かないわ

**デフォルトの名無しさん** · 2019/03/13(水) 12:56:53.92

何のためにリロードするのかってユーザーが勝手にリロードするからだろ
糞サイトだろうが優良サイトだろうがリロードするやつはリロードする
そんなことすら理解できないバカを自己紹介すんな

**デフォルトの名無しさん** · 2019/03/13(水) 13:27:25.76

何を期待してリロードするのかということなんだが…
リロードしてもリロード前とステートまったく変わらないの？
そんな糞サイト二度と行かないわ

**デフォルトの名無しさん** · 2019/03/13(水) 14:00:09.36

>>72
お前がバカだから理解できないのはわかった