Vue vs React vs Angular vs Svelte Part.9

**デフォルトの名無しさん** · 2022/01/16(日) 16:06:14.27

Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
Svelte
https://svelte.dev/

※前スレ
Vue vs React vs Svelte Part.7
https://mevius.5ch.net/test/read.cgi/tech/1610901677/
Vue vs React vs Angular vs Svelte Part.8
https://mevius.5ch.net/test/read.cgi/tech/1621744952/

★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。

**デフォルトの名無しさん** · 2022/01/25(火) 15:04:21.85

>>141
ほんとそうかもしれない…
普通のやり方でやれば5分で終わる作業なのに
何時間もかけるのはアホらしい…

**デフォルトの名無しさん** · 2022/01/25(火) 15:16:41.58

Reactの達人では無いけど、
俺はわりとプレーンなコンポーネントを使うし、デザイン面は愚直に書けるTailwindCSSだより。
複雑なコンポーネントはデザイン用のインターフェイスだいたいある気がする

**デフォルトの名無しさん** · 2022/01/25(火) 15:59:12.23

下に記述してるstyleの宣言を上のSenderより上で宣言しないといけないんじゃないの？

**デフォルトの名無しさん** · 2022/01/25(火) 16:21:49.50

>>141
特にB2Bな案件だと自前で作るしかないねえ
ライブラリの罠に嵌まりたくもないし
メンテされなくなった時のリスクもでかい

**デフォルトの名無しさん** · 2022/01/25(火) 16:36:07.84

いきなりreactとUIライブラリの学習はキッツイだろ
reactに慣れてきてからUIライブラリ使いなよ

**デフォルトの名無しさん** · 2022/01/25(火) 16:42:44.81

ちょっとmaterial UIは諦めます
reactを覚えるだけでも大作業だわ…
親から子コンポーネントに
関数を渡すのに1時間30分かけて進展がない…
もう全部捨ててjQueryでやろうかしら…

Action Script、C/C++、Swift、SwiftUI、
processing、openFrameworks、
AVR(c)、とやってきたけど
初歩的なところでこんなつまづいたの初めてかもしれん…
やってられん…
Facebookが作るものはやっぱりFacebookクオリティか…

**デフォルトの名無しさん** · 2022/01/25(火) 16:45:43.61

>>147
context使えよ

**デフォルトの名無しさん** · 2022/01/25(火) 17:23:44.90

1時間半で諦める人には向いてないかも

**デフォルトの名無しさん** · 2022/01/25(火) 17:30:42.61

>>147
マテリアルUIは使ったこと無いから知らないけど、親から子に関数渡す超初歩的なことならドキュメントに書いてあると思うよ

**デフォルトの名無しさん** · 2022/01/25(火) 17:42:37.67

さすがにヘボすぎだろ

**デフォルトの名無しさん** · 2022/01/25(火) 18:38:47.07

Reduxほんとに使うこと無くなったね
もう2度と関わりたくないよ

**デフォルトの名無しさん** · 2022/01/25(火) 19:01:34.68

ゆうてまあここはReactについて答えられないやつばっかだしな
口だけなのよみんな

**デフォルトの名無しさん** · 2022/01/25(火) 19:17:30.98

React使えば凄いもの作れるかといったらそうでもないし
そもそもそんな凄いインターフェースなんか求められていない

インターフェースなんかHTMLとCSSで作ればいいんだよね
HTMLとCSSは随分と高機能になったから
そこにちょっとjQueryで動きをつければ十分なことが多い

イラストレータやCADソフトみたいなものはReactみたいなものが
便利だと思うけど、普通の管理画面インターフェースとかだとjQueryで十分

**デフォルトの名無しさん** · 2022/01/25(火) 19:26:48.23

>>136
ボタンを押したら白くなる……がちょっと意味わからんけど

&:hover {
}

を用意すればいいって話だったりするのかな

**デフォルトの名無しさん** · 2022/01/25(火) 19:31:01.82

>>153
上の方見ると詳しい人もいるし、単に余計な捨て台詞吐くから反感買ったんだと思う。

>>154
jQuery使うくらいならバニラの方が楽だな。

**デフォルトの名無しさん** · 2022/01/25(火) 21:42:48.67

jQueryはバニラと混ぜて使えます。
バニラよりも簡単にかけるところだけ
jQueryを使えばいいのでバニラが簡単というのは
理論的にありえません。

**デフォルトの名無しさん** · 2022/01/25(火) 21:45:15.73

>>155

> &:hover {
> }
>
> を用意すればいいって話だったりするのかな

ありそうな話だな。CSSが苦手なくせに
CSSを勉強しないから、無駄なJavScriptコードを書く人が多い

そういうやつに限ってCSSをけなして
使えない自分を擁護している

**デフォルトの名無しさん** · 2022/01/25(火) 21:55:05.28

はいはい。自分で立てたスレでやってね

**デフォルトの名無しさん** · 2022/01/25(火) 21:56:02.66

ここでやるよ

**デフォルトの名無しさん** · 2022/01/25(火) 22:01:21.44

CSSの勉強とかする奴いるの？

**デフォルトの名無しさん** · 2022/01/25(火) 23:02:59.34

管理画面や業務システム系にはReactがベスト

**デフォルトの名無しさん** · 2022/01/25(火) 23:04:55.60

フロントエンジニアなのにcss設計ができないならReact使う意味ない

**デフォルトの名無しさん** · 2022/01/25(火) 23:19:08.31

>>162
わかる。fetch待ってあっちの状態を拾いつつこっちに同期して副作用見ながらElement差し替えて……とか考えずにサクッと組めてほんと楽

**デフォルトの名無しさん** · 2022/01/25(火) 23:42:58.03

漏れは、CSS は分からない。
Ruby on Rails で、SASS・Bootstrap しか知らない

>>136
Railsでは、React, Bootstrap, Bulma, Tailwind が多い

Material-UI, ElementUI は、あまり聞かない

**デフォルトの名無しさん** · 2022/01/26(水) 00:10:14.89

最近のシングルページアプリケーション大嫌いだから早く廃れてほしいわ

**デフォルトの名無しさん** · 2022/01/26(水) 06:29:00.55

いちユーザとしての嗜好をここに書かれてもなぁ。
SPAなんて15年位前からあるわけだし、スレタイのライブラリやフレームワークはSPA以外も作れるし。

**デフォルトの名無しさん** · 2022/01/26(水) 10:46:32.23

SPAがいいというか最初のロードで終わるから便利なのであって
今時ページ毎に読み込みとかダサいでしょｗ

**デフォルトの名無しさん** · 2022/01/26(水) 11:25:39.57

ページごとに読み込んでくれた方がリセットされる安心感がある
あと遷移前のページとは基本的に切り離して考えて操作すればいいのねということがよくわかるからマルチページのほうが良いと思う
マルチページのほうがハイパーリンクやRPAとの相性もいい

これはあくまでユーザー目線になった時にどっち使いたいか？って考えたときにそう思うってだけね
開発者の目線だとSPAの方がアーキテクチャが綺麗に階層化されててメンテしやすく実装が簡単なのでいいと思う

**デフォルトの名無しさん** · 2022/01/26(水) 11:26:22.51

安心感w

**デフォルトの名無しさん** · 2022/01/26(水) 11:29:29.66

>>168
ダサいとかいうお前の主観で判断するなや

**デフォルトの名無しさん** · 2022/01/26(水) 11:30:21.31

>>169
マルチページだと、それそれが担当する範囲が分離されていて
複数の人が並行で開発しやすくなる
大規模システムに向いてる

**デフォルトの名無しさん** · 2022/01/26(水) 11:31:05.53

ユーザー目線になった時SPAは「マルチページであるかのように見せる」
ということを徹底しなければいけない

本末転倒ｗ

**デフォルトの名無しさん** · 2022/01/26(水) 11:32:34.74

>>170
草生やしてるけど安心感ってめちゃくちゃ重要だと思うんだが？
特にエンドユーザーはITのことなんてよく知らんから安心感が何より大事
「あっ、これはよくある普通の素朴なホームページだ、これなら簡単に使えそうだ。ホッとするね」って思ってもらえたら勝ちよ
逆に「な、なんだこれは。ブラウザなのにまるで業務用のデスクトップツールみたいに複雑だぞ。ひえ～、動かし方が想像できない。う～ん、こりゃ困ったぞ」って思われたら負け

**デフォルトの名無しさん** · 2022/01/26(水) 11:38:28.35

spaを何だと思ってるんだ？
twitterが複雑で使いづらいとか聞いたことないが

**デフォルトの名無しさん** · 2022/01/26(水) 11:46:40.80

ひょっとしてSPAだとルーティング出来ないと思ってるのでは？

**デフォルトの名無しさん** · 2022/01/26(水) 11:53:28.56

>>174
お、そうだなおじいちゃんw

**デフォルトの名無しさん** · 2022/01/26(水) 11:55:32.37

>>175
一例だけで全体を押し測るのはどうかと思う

>>176
従来のページ遷移に見せかけてるだけであって別の概念
やっぱり全てリセットほどの安心感はないね

**デフォルトの名無しさん** · 2022/01/26(水) 11:56:49.13

>>177
俺はまだおじいちゃんじゃないけど、世の中おじいちゃんおばあちゃん、おじさんおばさんがどんどん増えてるんだから、彼らに最適化したシステムを作るべきなんだよな

**デフォルトの名無しさん** · 2022/01/26(水) 11:57:50.70

>>174
それは見た目(デザイン)の問題であって
シングル/マルチとは関係なさそう

**デフォルトの名無しさん** · 2022/01/26(水) 11:59:54.06

IE使ってそうなおじいちゃんだなw

**デフォルトの名無しさん** · 2022/01/26(水) 12:01:00.51

>>178
概念が違っても見かけが同じなら気づかなくね？
例えば、ユーザーはTwitterのタイムラインとツイート単独画面を別のページだと思ってるでしょ

**デフォルトの名無しさん** · 2022/01/26(水) 12:03:56.46

>>180
デザインの違いじゃなくてあの遷移するときのいったんリセットしてロードし直してる感が良いんだよ
あれがあるとすごく安心するんだ

**デフォルトの名無しさん** · 2022/01/26(水) 12:04:33.05

>>181
Chrome、EDGE、時々Safari使ってる

**デフォルトの名無しさん** · 2022/01/26(水) 12:10:01.72

>>182
気付いてはいるだろう
あれリロードされないぞって

**デフォルトの名無しさん** · 2022/01/26(水) 12:16:09.14

それ、ただの遅いサイトでは……。
じゃあロード画面でも表示しますか

**デフォルトの名無しさん** · 2022/01/26(水) 12:16:30.19

現代の大半の人間はYouTubeやTwitterとかLINEやTikTokとかのアプリを長い時間使ってるし、それらのアプリはSPAの動きするから現代の人間にとってはSPAの方が慣れていると思うぞ
ゆえにページ移動の度に画面が一瞬真っ白になるのって「なんやこれ？」ってなる

**デフォルトの名無しさん** · 2022/01/26(水) 12:23:35.09

>>186
ロード画面はいいかもね
あとは上から徐々にレンダリングされていくあの感覚
あそこまで再現できれば安心感を演出できるかも

**デフォルトの名無しさん** · 2022/01/26(水) 12:25:11.75

>>187
ないない
そんなのごく一部の例外だって
世の中のほとんどはまだSPAになってないし今後もならないだろう
ユーザーはよく使うマルチページのほうが親しみがある

**デフォルトの名無しさん** · 2022/01/26(水) 12:28:05.87

どこまでネタかわからん

**デフォルトの名無しさん** · 2022/01/26(水) 12:28:56.83

あとね
SPAに慣れるってことは基本的にないんだ
SPAで作った特定のアプリに慣れることはある
だけどそれに慣れたとしても別のアプリには慣れない
だってSPAのアプリは個性的でそれぞれ違う動きをするから

これとは対照的にマルチページアプリはどれもウェブの作法を守ってるので異なるアプリでも共通点が多い
なのでマルチページアプリに慣れるってのは大いにあり得る

**デフォルトの名無しさん** · 2022/01/26(水) 12:34:01.00

慣れるも慣れないも時代によって使われる技術は変わるだろ
頭カッチコチの老人かよ

**デフォルトの名無しさん** · 2022/01/26(水) 12:34:24.78

視野が恐ろしく狭い

**デフォルトの名無しさん** · 2022/01/26(水) 12:40:35.07

>>189
スマホ持ってないの？
お年寄り用とか子ども用のスマホなら持ってる？
それならYouTubeとかTwitter使えないかもしれないけども
言うてもネイティブアプリってSPAになってるやつしか見たことないな

**デフォルトの名無しさん** · 2022/01/26(水) 12:41:06.07

>>192
変わるものもあれば変わらないものもある
HTML、HTTPはず～～～っと昔からあってあまり変わってない
SPAの方が異端なんだよ明らかに

**デフォルトの名無しさん** · 2022/01/26(水) 12:41:39.99

親しみのあるガラケー使ってんだろ

**デフォルトの名無しさん** · 2022/01/26(水) 12:42:31.75

前にいたjqueryおじやろw

**デフォルトの名無しさん** · 2022/01/26(水) 12:42:53.80

>>194
ネイティブの話はしてないよ

**デフォルトの名無しさん** · 2022/01/26(水) 12:44:09.89

>>195
HTMLもHTTPも時代に合わせて変わってるけど？
変わってないのはお前の頭だけな

**デフォルトの名無しさん** · 2022/01/26(水) 12:47:38.52

>>196
流石にモバイルはとっくにスマホだよ
三輪車と自動車ぐらい差がつく物なら流石に自動車を選ぶ
それは当然の選択だろう

でもSPAとマルチページアプリってそこまで差がないと思うなー
普通の自転車とロードバイクぐらいの差かなー？
つうか差がないどころか使い勝手はマルチページアプリの方が良いとすら思ってるよ
自転車の例えで言うと「あのー速いのはわかったんですけど、ロードバイクのハンドル持ちにくいんでね。普通のハンドルにしてくれませんか？」みたいな感じ

**デフォルトの名無しさん** · 2022/01/26(水) 12:48:21.26

>>199
あまり、って言葉が見えなかった？

**デフォルトの名無しさん** · 2022/01/26(水) 12:49:54.45

>>175
> twitterが複雑で使いづらいとか聞いたことないが

え？スクロールした後、進むとか戻るで
スクロール位置がリセットされて使いづらいって聞いたこと無いの？

**デフォルトの名無しさん** · 2022/01/26(水) 12:50:10.88

>>197
いや開発者の立場だったらreactおじさんだよw
ユーザー目線の使いやすさはともかく開発するだけならSPA途轍もなく簡単だからね
開発者なら楽な方を選ぶのが正解だ

**デフォルトの名無しさん** · 2022/01/26(水) 12:50:45.25

Googleの検索なら、ページがあるから
10件単位ぐらいで位置を覚えてくれるから便利

**デフォルトの名無しさん** · 2022/01/26(水) 12:51:23.72

個人の感想過ぎる

**デフォルトの名無しさん** · 2022/01/26(水) 12:51:54.58

不便でもそれに慣れてしまうと、不便だって気づかない良い例だな

**デフォルトの名無しさん** · 2022/01/26(水) 12:53:39.85

>>198
①アナリティクスとかアドセンス使ってればユーザーがアクセスしているデバイスが分かるけど、多くのWebサイトやWebアプリはスマホユーザーがめっちゃ多い
②スマホユーザーってのはYouTubeとかTwitterとかのLINEとかのネイティブアプリを長い時間かけて使っていると考えられる
③ネイティブアプリってのはほぼSPAな動きをするから、ネイティブアプリを長い時間使ってるユーザー＝SPAの挙動に慣れてる、と推測できる
よってWebサイトにせよWebアプリせよSPAの方が、スマホユーザーにとっては体験がいいんじゃないの、ってことよ

ただ、②のスマホユーザーが「ネイティブアプリ触ってる時間は1日の内わずかです、割合で言うとWebサイトを閲覧してる時間の方が多いです」ってなったら上の理論は成り立たないよ

**デフォルトの名無しさん** · 2022/01/26(水) 12:53:51.96

>>206
SPAに慣れちゃったらそうなるのかなー？

**デフォルトの名無しさん** · 2022/01/26(水) 12:56:24.92

>>207
さっきも言ったけどSPAに慣れるってことはないんだよ
共通の作法がないからアプリごとに固有の見た目と動きがある
なのでネイティブのアプリに慣れたとしてもそれでSPAに慣れたということにはならない
SPAの個々のアプリについてそれぞれ練習が必要で習熟には時間がかかる

**デフォルトの名無しさん** · 2022/01/26(水) 12:58:31.67

>>207
続き

君が言ってることはつまりこういうこと
「YouTubeやLINEのネイティブのアプリに慣れたらVSCodeにも慣れたことになるよね」

そうはならんやろ？

**デフォルトの名無しさん** · 2022/01/26(水) 12:58:49.67

SPAでMPAの動作を苦労して作る
なら最初からMPAを使えば？

**デフォルトの名無しさん** · 2022/01/26(水) 13:01:08.23

>>211
苦労したくないからSPAで作る
ユーザーには御免なさいだけど使いにくいものを使ってもらう
仕事だからね
信念とは違うこともやらんといかんのよ

**デフォルトの名無しさん** · 2022/01/26(水) 13:01:30.33

頭が固かったり、自分だけの意見を曲げられなくなってて意固地になったり、
長文だったり、連投したり、例えをしだしたり、
典型的な前時代のおっさんじゃんw
ずっとブラウザリロードしてろよw

**デフォルトの名無しさん** · 2022/01/26(水) 13:03:09.96

SPA大嫌いジジイを見てると、日本が何で発展しないかよく分かるわ
既存のやり方に固執して、変化する世界には目を背けて「今までこれでうまくやってきたからいいんだよ！」と開き直る
日本の中枢にいるやつらってこんなんばっかりだもんな

**デフォルトの名無しさん** · 2022/01/26(水) 13:03:33.05

>>213
中身への言及がない時点でお察しのレス

**デフォルトの名無しさん** · 2022/01/26(水) 13:04:07.74

>>215
そういうとこw

**デフォルトの名無しさん** · 2022/01/26(水) 13:06:20.85

なんか最近やたらNuxtからNextに移行しましたみたいな人増えたけど、これただreact使いたいだけだよねえ

**デフォルトの名無しさん** · 2022/01/26(水) 13:08:51.44

>>214
日本は世界でも有数の先進国だが？
国内にいると世界が見えないとよく言うがまさにそれだね
良いものは良いものとして長く使う
本当に良いものは取り入れて改良する
日本は今も昔もそうやって世界をリードしてきたんだよ

SPAだと開発が簡単なところは評価している
なのでうちもSPAを開発に取り入れている
発展はしているのだ
それがユーザーの利便性に繋がるかはまた別の話
全てはコスト・パフォーマンス

**デフォルトの名無しさん** · 2022/01/26(水) 13:11:54.93

jQueryおじさんと芸風が同じだな

**デフォルトの名無しさん** · 2022/01/26(水) 13:12:25.00

>>213
MPAはリンクをクリックした時にページが自動的にロードされる
わざわざブラウザをリロードなんかしない
そんなことも知らないのか？

**デフォルトの名無しさん** · 2022/01/26(水) 13:31:42.79

>>220
ん？ID:qAyrcykqと同じ人？
MPAがどうだなんて絡んだつもりないぞw
IEでjqueryおじがブラウザリロードしてそうだからw

**デフォルトの名無しさん** · 2022/01/26(水) 13:44:37.41

4〜5年前からSPA前提の案件しかやならくなったけどなー
てかMPAで済むような案件安くて割りに合わなくない？
Nuxt使って開発中の機能プレビュー出来るようにしたら
客が気に入っちゃって毎回Nuxt指定で発注くるわw

**デフォルトの名無しさん** · 2022/01/26(水) 13:54:40.62

単価は分からんけどちょっとそこはなんとも言えない気もする
大規模ECのPC版サイトはいわゆるMPAが多い気もしていてそこが安いとも思えない
あと古い業務システム（の保守とか）はまだ多くて、人こないから高くなってそう

後者の会社の人にSPAバリバリのページ見せると目が輝くw導入はまた別の話だけどもw

**デフォルトの名無しさん** · 2022/01/26(水) 14:32:09.32

このおじさんに名前つけようぜ

**デフォルトの名無しさん** · 2022/01/26(水) 14:36:23.23

結局Reactが一番無難？

**デフォルトの名無しさん** · 2022/01/26(水) 16:11:57.51

またこいつ暴れてるのかよ
まあ好きにしろ
それでジョーカーを防げるなら安いものだ

**デフォルトの名無しさん** · 2022/01/26(水) 17:07:36.34

>>225
Reactがしっくりくるならreactでいいんじゃない
初学者が独学でフロントエンド学ぶってならユーザーフレンドリー強調してドキュメントとかに力入れてるvueでいいと思うけど

**デフォルトの名無しさん** · 2022/01/26(水) 17:17:45.06

表題のフレームワーク・ライブラリは全部ドキュメント充実してると思う。良い時代だ

**デフォルトの名無しさん** · 2022/01/26(水) 18:21:10.66

なんか荒れてて草

**デフォルトの名無しさん** · 2022/01/26(水) 22:43:34.74

>>224
レガシーに縛られてるしかなりの石頭な上に自分から動くことももうできないみたいだから、化石とか？

**デフォルトの名無しさん** · 2022/01/27(木) 04:10:57.05

angularでプログレスバーの進捗率を操作してやってる良いサンプルコード無いですかね？

**デフォルトの名無しさん** · 2022/01/27(木) 23:44:42.37

ReduxやRecoilはコンポーネントの凝集度を上げ、疎結合とすることに意味があるのに
すぐバケツリレーの是非の話に置き換えて議論してるのを見かける
本質はそこじゃないだろって毎回思う
バケツリレーが辛いとか辛くないとかどうでもいいんよ

**デフォルトの名無しさん** · 2022/01/28(金) 12:25:41.63

コンポートがreduxやらrecoilといったインフラストラクチャに依存してたら嫌だな
疎結合を謳うならコンポートは純粋にして全ての副作用をpropsで渡すのが正解

**デフォルトの名無しさん** · 2022/01/28(金) 13:08:31.65

reduxとかは再描画抑えるってのが重要なのでは

**デフォルトの名無しさん** · 2022/01/28(金) 13:34:23.09

Hooksが当たり前になってから状態管理ライブラリそのものが必要なくなってきたけどね

**デフォルトの名無しさん** · 2022/01/28(金) 13:45:11.84

redux持ち上げてたやつ反省しろ

**デフォルトの名無しさん** · 2022/01/28(金) 14:21:14.42

パフォーマンスに取り組もうとするとuseCallback地獄になってコードの見通しが最悪
依存性指定は間違えやすいのに間違えるとデバッグしにくいバグになって現れる
困ったものだ

**デフォルトの名無しさん** · 2022/01/29(土) 07:46:05.80

こういうパターンがあるのか。良さげ

コンポーネントをカスタムフックで提供する
https://engineering.linecorp.com/ja/blog/line-securities-frontend-3/

**デフォルトの名無しさん** · 2022/01/29(土) 08:42:38.68

普通のカスタムフックに見えるけど
うちのにもuseが大量に転がってるぞ
カスタムフックだらけだ

**デフォルトの名無しさん** · 2022/01/29(土) 08:55:48.59

結構使われてるのか～

**デフォルトの名無しさん** · 2022/01/29(土) 09:12:06.81

>>240
関数が関数を帰す事をやってない人からみたら
目新しく見えるだけ