Vue vs React vs Angular Part.2
■ このスレッドは過去ログ倉庫に格納されています
実際どうなん？
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房が書き込んでも無視してください >>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は冗長 実際vueの方がコードは長くなるわけで、
たった2行にバグが有るかどうかと
十数行にバグが有るかどうかでは
考えるまでもないな 次はonclickを使う例にしようか？
jQueryだとコードは増えないが
Vueだとさらにコードが長くなる スレタイに入ってるけどAngularのアウェイ感が半端ない >>10
俺はangularはサンプルいじって放置してるよ。実務で使うシーンが限定というか予定にない。自社でも受注にもない。 >>11
React、VueはJavaScriptでHTMLを作るものだから。
AngularはHTMLをベースにそこに特殊な属性をつける。 1から2への移行、というか再構築の苦労話見るとなあ。個人的に習得すべきかずっと迷ってる。 >>11
今って言うか前スレで殆ど話題に上がらなかったなと >>12
何でAngularってあまり使われないんだろうな。
自由に構成を変えられない分、チームとして協業した時に構成を統一出来るし、
ベースとなるTypeScriptで型宣言出来るから変数に違う型をぶち込もうとしてたらIDEが教えてくれるからバグも少なく書ける。
これだけ大規模開発と堅牢なコーディングに向いてて、何故どこの企業もAngularで開発しようってならないんだろ。
一度Angularで開発始めてしまうと後戻りできなくなるからとか、
そもそもHTML、CSS、Javasceiptしか出来ない人間にAngularは荷が重いからとか？ >>17
用途が違うから。
Reactを使ってるのはウェブサイトじゃなくて
ウェブアプリを作ってる。
ウェブサイトはReactでは作りづらい
ウェブサイトはAngularが適しているが、
その程度の用途ならjQueryで十分 Angular使ってる部署は使ってるな
自分のところで使わないのは、
・大胆に仕様が変わる
・その割りに飽きてポイ捨てするgoogleの体質
で使ってないな
googleの信用問題な気がw Reactもライフサイクルメソッドとか大幅に廃止になってたりするけどね まだまだ先とはいえ、GoogleはいずれAngularを捨てて
Flutter for Webを推していくようになると思うぞ それはReactも同じだよ。
Web Componentsがすべてを置き換える。
まあReactと互換性がないReact Nativeは別だけどな。
React Nativeはアプリ用であってウェブ用ではないし >>23
AngularDartってのもあるからな >>17
webの構成要素html、js、cssはとても壊れやすく脆い。altcss、altJSも結局はラップに過ぎん。そして動作するブラウザもどこかで不安定。
だからwebはライブラリやフレームワークが優秀でも堅牢とは言い切れない、どこか不安定な感じが拭えないんだよ。
その上流れの早い業界だから、速攻習得できて早く捨てられる。次に備える。そういうスタイルがwebに合ってる気がしてる。angularには腰が重くなる。 >>26
html、js、cssは登場してから大きく変わることはなく安定してると思うけど？
壊れやすいのはその周辺技術。同じことを違うやり方をしては消えていく
生HTML、生JS、生CSSに近いものほど長く生きている 生たって小規模ならともかくjsの長ったらしいのなんかメンテできないだろ
ちゃんとしたlintツールとかあってチームとかでメンテできるわけで lintツール使ってもjs自体はjsそのものだろ
生じゃないjsというのは、jsをjsではないものにするってこと
例えばCoffeeScriptとかね。
HTMLで言えば、HAMLとかあったがあれも死んだ
HTMLではないからだ。XHTMLもほぼ死んだ状態
jsもAltJSは殆ど死んだ。残っているのはTypeScriptというjs+αという
互換性があるものだけ。
CSSも生き残ってるのは、CSSと高い互換性があるSASSぐらい
標準の構成要素は消えないし、標準から離れれば離れるほど死滅するのが早くなる
ウェブのフレームワークも標準のDOMとは違うやり方をするので、すぐ消えるよ CoffeeScriptにしてもSassにしてもRails由来のものはあんま流行らなかったな
ScssはSassの一形式みたいに言われてるが本来のSass形式が受け入れられなかった結果だしな >>30
俺が言ってるSassっていうのはプロジェクトの名前で
構文自体はScssだからね。 そんなものよりも互換性のほうが重要だし
テキストエディタの機能で小さな差は吸収される >>29
AltJsてことね、失礼
TypeScriptはやっぱ便利だね
Vueでもやりたいんだが周りがjsでやろうとするんだよな >>25
普通に考えれば
AngularはDartでやるべきなんだろうけど >>32
逆にインデント入れたらダメってルールはないし >>27
すまん言い方が大雑把だった。エンジンがどうこうじゃなく、最近は減っただけでブラウザ依存は無くなってないし、生cssやdomは貧弱すぎる。
本来の用途ではないのを時代の要求に合わせて無理やり実現してる感が凄い。それをフレームワークやIDEが必死の努力で隠してくれてる。
それは凄く有難いし新技術はワクワクするしvue reactは楽しい。でも独自記法が象徴する様に「コレは一時的なものです。今はこう書きます」というキナ臭さ凄い。ガッツリコミットできない。 でも、なんかこのスレ見てたらangular勉強する気が湧いてきたわ。しばらく独学して判断するよ。 >>38
これからGoogleMapもPWAになるって聞くしな Vue.jsは仕事で使ったけどイマイチな感じがした。
ちょっと入院するからreact native勉強するつもり。
このままサーバサイドエンジニアに追い込まれて終わらんよ >>40
そうだね、pwaは必須になると思う。よりネイティブアプリに近づく流れは避けようがない。
あとスレタイにある様に、現時点でjsフレームワークは3種類に絞られたと言って良いと思う。松茸梅じゃないけど、いい感じに出揃った。腰を据えて松のangular学んで良い時期なのかなと。 Angularに詳しい人に質問。
個別のコンポーネントで管理されてる状態を表す変数（例えばユーザーが入力した文字情報や、サーバーから取得したJSONデータ）を
コンポーネント間で共有したい場合、どこで保管するのが適切？
最初は単一のserviceに全ページの状態を示す変数をぶち込んで、単一のservice↔各コンポーネント間でデータのやり取りやデータバインディングやってたんだけど、
ページ数が増えるに連れて変数の管理がし辛くなっていったわ。
あと、データがserviceなんかにあるもんだから、データバインディングする際にも各コンポーネントのhtmlにクソ長い名前付けなきゃならなくてかったるい。
実現したいポイントは、
①コンポーネント間のデータ共有
②どのデータがどのコンポーネントの状態を示すのかを明確にする
③データバインディングのコードの書きやすさ
なんだけど、なんかアイディアない？ PWAの実行環境としてウェブブラウザは最適なんだろうか。 前スレでAureliaってのが出てたから試してみたけど
cliでプロジェクト作っても初期状態でnpm startすら碌にできんとか
流石にスレタイの3フレームワークとは同列じゃないなって思った >>45
PWA=実行環境だよ
ブラウザをベースとしてOSがアプリのように
見える仕組みを追加する拡張されたブラウザ機能のこと
素のウェブブラウザが最適ではないからこそ
OSがその機能を追加してる >>44
すまん横槍なんだけどangularだけの問題じゃないので。
ネイティブアプリでもwebでもRxを使うのがトレンドだと思うんだが、それではダメ？ >>48
えぇ…駄目って事は無いと思うけど、RxJSで一度取得した情報をページ遷移ごとに再度取得したり、ユーザーが仮で入力した入力情報を一々RxJSで送るって、面倒臭過ぎない？
俺は一度取得したデータや入力したデータはコンポーネント外のどこかに保管して、
データの更新がある時に再利用する、という方法が良いと思うけど。処理的にも通信量的にも。
もちろん、作るものによってデータの扱いは異なるだろうから、俺の考えが絶対に正しいとは思わないけど。 >>49
それは結構範囲が広い問題だねえ。設計思想にも関わってきそうな。ただデータの再利用部分なんだけど、単に通信量を減らすキャッシュ的なもの？なら簡単だろうけど、なにやら複雑そうだね。 >>41
描画し終わった後に呼ぶメソッドはアレとか、前だとコレとかとっつきにくい。
まあriotよりはマシだが >>53
いやそこまでは。精々ユーザーが使っている間、具体的にはブラウザタブ開いている間くらいで考えてる。
JSONにしてsession storageにぶち込もうかとも思ったけど、データバインディングもしたいから
今んとこはserviceで管理するのが一番無難かなぁと。 Model(Application/Data) <----> View Model (JQuery/AnimeJS/DOM) <----> View(HTML/CSS) >>54
5chじゃ詳しく話せないと思うんだけど少し範囲が広すぎるから、なにが具体例があると分かりやすい。今までの内容から、storeやrxやstorage,indexedDBでも解決に至らない問題って事だよね。
>データバインディングする際にも各コンポーネントのhtmlにクソ長い名前付けなきゃならなくてかったるい。
ここが核心で他は不便ではない、という事なら解決方法は全然違ってくると思うし。 >>51
俺の場合はReactNativeを仕事で使って、同じようなとっつきにくさを感じたから、今はVueやってる。たぶん大差無いんじゃないかな。 vueのtsサポートってどんな感じ？
普通に使える？ Fluxってsetterで値をセットし、getterで値を取得しましょうってことでいいの？
それともsetterの代わりに、メソッドで連想配列に値を入れて
getterは使わず、内部構造の連想配列をそのまま取得ってこと？ >>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}}
を書くのが面倒。
何かズラズラと書き上げてて、だんだん設計がよろしく無い気がしてきたわ。いっぺん設計を考え直してみるわ。 >>61
ちょっと俺もangular勉強中だから近日中に答えるわ。
ただ気になるのが4)のA>Bに遷移した後、リロードが発生したら表示できなくなる気がするんだけど。。urlが同じならAに戻るだけだから問題ないと言えば無い。のかな？
または、A>Bへの遷移後Aは破棄されず再び更新が発生した場合サービス側で注意深く処理しないとせっかくのBのバインドが外れてしまう。
ごめん実装と例は違うんだろうけど、パッと見て気になったところ。 それ
リロードが発生するとデータが消えるのは論外なのでリロードしても大丈夫なようにしないといけない 名前が長くなるのはいやがらない方がいいと思うけどな。シンプルな名前にすると背後に潜む仕組みがわかりにくくなって逆に不安になったりしない？ {{this.TestService.val.res}}
こう書いてあると、他の人が見たときにわかりやすくてよい名前だと思う。 ReduxならlocalStrageのミドルウェアがあったな 現段階での改善案なんだけど、
1:Aのロード部分はサービスへ。
2:AB共にサービスからrx経由で取得。
が基本だと思う。要はコンポーネント内で直接ロードしない。この修正だけで随分見通し良くなると思うよ。
あとはサービス側でキャッシュなり永続化なりお好きな様に。 頑張らなくっちゃ～ 頑張らなくっちゃ～
うんちもプリップリッ おしっこもジャージャー
頑張らなくっちゃ～ 頑張らなくっちゃ～ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) ・サービスの根幹に関わる部分はflux概念で管理
・その部分はどのページでリロードしても破綻しないように管理する
・見た目とかリロードで変更されても問題ないstateはそれぞれのコンポーネントで管理
こんな感じかね リロードしてもステート変わらないの？
何のためにリロードするんだろうな。
そんな糞サイト二度と行かないわ 何のためにリロードするのかってユーザーが勝手にリロードするからだろ
糞サイトだろうが優良サイトだろうがリロードするやつはリロードする
そんなことすら理解できないバカを自己紹介すんな 何を期待してリロードするのかということなんだが…
リロードしてもリロード前とステートまったく変わらないの？
そんな糞サイト二度と行かないわ >>72
お前がバカだから理解できないのはわかった 馬鹿と馬鹿が言い争っていてワロタ
jQueryおじさんの俺が説明してやろう
リロード自体が要求になってるんじゃないんだよ。
重要なのはURLに対応した表示になるということだ
例えば、誰かにこのページ見てくださいってLINEかなにかで送った時、
相手もそれを同じ内容で見れるということが重要なんだよ。
それが出来てれば自然とリロードにも対応する
それから進むと戻るな。ブラウザで進むや戻るを押したとき
URLが変わるが、内容もそれに対応して変わらないといけない
これもURLい対応した表示ができるならば自然と実装できてることになる
リロードした時に表示内容が変わる変わらないは関係ない
データが更新されりゃそりゃ変わるだろ。それは問題ではなく
URLに対応して表示がされてるということが重要なんだよ。 >>72
逆だよ逆。リロードしてもステートは基本変わっちゃダメなんだが。。別の何かと勘違いしてない？ URLに乗っけるべき情報（ステート）と
そうでない情報を明確に区別して考えてるかい？
それぐらいSPAの基本になってるはずだろう？
なんかそういう前提基礎知識無いまま
フレームワーク使ってる！SPAが得意！俺SPAやってる！
みたいな馬鹿多そうだよね だからlocalStrage使う方法調べりゃいいだけしゃね？
どのフレームワークの話かはしらんけど 今angular入れて色々弄ってるんだけど、思ってたより分かりやすかった。これは食わず嫌いだったかも知れん。lonic2も良い。 今入院中でこの暇な時間使ってmacbookでreact nativeの開発環境構築したんだが、再起動しようとしたらmacOsの更新で引っかかってtimemachineで今朝に戻ってまたやり直しだよ。
Iphoneのデザリングは思わぬところで使えないな。
今日だけでパケット使用量が27.5GB超えたわw >>67
あぁそうか。コンポーネント基準で状態を保持するんじゃなく、RxJSを基準に取得した情報の管理をすりゃいいのか。なんとなく分かったわ。
あと、サイトのリロードについては特に書いてなかったけど、リロード時にはクエリにレコードのidでも埋め込んで、
ABそれぞれでTestService呼べばいいか。
>>65
説明が悪かったわ。変数名が長いのが「めんどくさい」の根本原因じゃなく、
VS Codeでコンポーネントのhtmlに変数を書く時に補完が掛からないからいちいち変数部分だけコンポーネントで書いて、
それをhtmlにコピペするって作業してるけど、その作業がめんどくさいんだよ。
htmlにクソ長い変数名貼り付ける際にコピー範囲間違えて、貼り付けた内容の間違いに気付かなくて、
serveして動かねー！なんて事も結構あったから、何か予防出来る良い方法（出来れば補完を効かせる方法）無いかなぁと。 Angularの人多そうだね
自分はReact派なので話がよく分からないわ >>85
ロードはそれで良いと思う。
あと補完部分だけど、俺はwebstorm使ってるからすまんけどvscodeだとどうなるのか分からない。でもそれ補完できるのが普通だから設定でどうにか出来そうな気がするんだけどね。。 >>85
まだangular初心者なんで勘違いしてるかも知れんけど、webstormだと補完効いてる様に見える。少なくともコンポーネントのpublicな変数がhtmlで補完効かないという事は無い。注入したサービス内のプロパティも補完効く。
一度試してみたら？30日のトライアルあるし。インスコしてプロジェクト読み込むだけですぐ確認出来るよ。少し高いが。。サブスクだし。 >>86
俺もreact vue派だよ。ただ聞いてた様なangularの急な学習曲線は無いと、現段階では思う。まだ全体を比較できるほど知ってる訳じゃないけど。 ふと思ったんだけど、vscodeにangularのextension入れて無いから補完効かないとかじゃ、、違ったらすまんね。 nuxtとかVuepress使ってる方いたら、使用感とか不満点とか教えてください。 >>93
Nuxtでssrにexpress使用する場合って事？仕事で使ってるよ。
create-nuxt-app で pwa, express, vuetify 指定。
色々世話焼いてくれるのは良いけどカスタムしようとすると少しトリッキー。ルータ周りとか。元が緩いから常に複数のやり方がある。たまにコレで正しいの不安になる。不満点としてはそんなもん。 職場のとなりのおっさんが秀丸でAIのフロント作ってた
設計もデザインもコーディングも全部一人で完結させてた
Reactも丸暗記してるみたいで秀丸で手打ち
手練れの人ならvscodeなんて要らない Webstormと違ってVSCodeは無料なんだから、そこまで嫌わなくてもいいだろう 一方俺はVS Codeでバグが見つかり一時間考えてもわからず人に聞いたらただの変数名の間違いだった ■ このスレッドは過去ログ倉庫に格納されています
