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/16(日) 16:06:33.48

こっちが本スレ

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

乙

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

ざまぁあぁｗｗｗ

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

どういう連鎖アボン正規表現入れたら快適になるかな？

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

Next.jsはええぞ。SSRもSSGもISRもSPAも行ける

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

SPAでいるか？

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

そもそもvsだから変なの湧くんじゃね
普通にタイトル4つの総合でいいやん

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

このスレが、いつもの荒らしが立てたもの！
いつもテンプレに、自分が有利なように追加してる

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

多くのPython のスレでも、いつもテンプレを変えている。
>・当スレにRubyのソースコード類を書くことを禁ず
>・Ruby等、Pythonではないプログラミング言語での回答類・質問を書くのも禁止
>・「Ruby では」「Rubyでは」「Rails」正規表現→「^クソチョンw$」をNGワード登録推奨

多くのJavaScript のスレでも、
jQuery, Lodash を禁止とか書いている

いつも、この荒らしがスレを立てて、テンプレを変えてくるので、
漏れらは荒らしの立てたスレから、正規のスレへ誘導してきた

9 · 2022/01/16(日) 23:21:41.36

このスレの削除依頼を出して、下の正規のスレへ移ってください！

Vue vs React vs Angular vs Svelte Part.9
https://mevius.5ch.net/test/read.cgi/tech/1642316327/l50

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

ここで良い
向こうのスレは無関係なjQueryが唐突に入れられている

**デフォルトの名無しさん** · 2022/01/17(月) 00:11:09.64

向こうのスレは荒らしが立てた事を証明する捨て台詞がご丁寧にも書いてあるしね

**デフォルトの名無しさん** · 2022/01/17(月) 12:41:22.76

Reactはいいフレームワークだけどフロントって非同期使いまくるのに非同期の扱いが残念なのがちょっとね
他のSPAフレームワークって使った事ないけど非同期はどうなんだろう

**デフォルトの名無しさん** · 2022/01/17(月) 12:48:41.83

>>13
まず最初にお前が理想のフレームワークをいえ
Reactが残念なんじゃなくて
お前が非同期処理を理解できないだけだろ

まるでプログラミングを勉強したくないけど
なんか凄いものを作りたい、簡単に使える言語ないの？って
言ってるようだ

**デフォルトの名無しさん** · 2022/01/17(月) 13:01:07.87

>>14
レベル低すぎて相手するのも面倒なレスだけどreactが非同期ニガテなのは常識だよ
今までずっと正解らしい正解がみんなで共有できてなくてuseState、useEffectで分かりにくい処理を地道に書く、それらをラップするオレオレフックを作る、別のサードパーティフレームワークを付け足して使う、などなどそれはもう、迷走しまくってた
reactが世に出てもう何年経ったかわからんが、最近になってようやっと公式が重い腰を上げて、Suspenseに取り組み始めたけど、これだって今までよりはマシかもって程度であって、けして非同期が楽だとは言えない代物

そんで楽してすごいものを作りたい、というのはフレームワークの存在意義そのものであって、それを否定するのは何も理解してない車輪の再発明マニアだけだ

**デフォルトの名無しさん** · 2022/01/17(月) 13:01:29.47

>>13
そうかなぁ、useEffectで非同期拾ってstate変えたら全部スパッと変わるんだから、やりやすいと思う。useEffectは非同期関数食ってくれないけども

**デフォルトの名無しさん** · 2022/01/17(月) 13:09:21.87

と思ったけどそういうレベルの話ではなさそうだな

**デフォルトの名無しさん** · 2022/01/17(月) 13:13:12.62

>>16
いや、あれはわかりにくい
依存関係とか諸々含めて、誰でもすんなり理解して間違いなく使える仕様とは思えん
必ずどこかでハマるように出来てる
つうか、完全に理解したとしても冗長な記述が多すぎる

reactの仕様を大きく変えてasync JSXタグをサポートするべきだと思うんだよな
例えばこういうの↓
const FooView = async () => {
try {
const foo = await fetchFoo();
return <View>
<Text>{foo.name}</Text>
<Text>{foo.age}</Text>
<View>
}
catch (e) { return <ErrorView error={e} /> }
}

もし仮にここまで出来れば俺は「reactは非同期が楽」と言っていいと思うぞ

つーかこんなんreactの開発者レベルならとっくに気付いてる筈なんだが
怠慢なのかわからんが、非同期をずっと放置し続けてきた

**デフォルトの名無しさん** · 2022/01/17(月) 14:23:54.47

>>18
あーなるほど。確かにそこまでサポートされてれば楽かもな～。
待ってる間はFragmentが入るようになってれば（多少柔軟性は落ちても）同期部分とも連携は取れると。
俺はそこまでは要らないかな。でもなるほどね

**デフォルトの名無しさん** · 2022/01/17(月) 14:33:09.18

>>18
いや待て、そこでfetchしたら駄目じゃね？

**デフォルトの名無しさん** · 2022/01/17(月) 15:31:40.92

>>20
機能を提供するのはよいぞ
どう使うかは宗教のもんだい

**デフォルトの名無しさん** · 2022/01/17(月) 18:31:36.68

fetchFooが何度も走るからその場所はマズくね？

**デフォルトの名無しさん** · 2022/01/17(月) 18:44:23.62

useSWRを使ってみるとか
(まだ使ったことないけど)

見た感じそれなりに使いやすそう?

import useSWR from 'swr'

function Profile() {
const { data, error } = useSWR('/api/user', fetcher)

if (error) return <div>failed to load</div>
if (!data) return <div>loading...</div>
return <div>hello {data.name}!</div>
}

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

>>23
単純なケースでしか通用しない気がするけどいけるんかな？

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

>>18
コンポーネントにガッツリ副作用入れてどうすんだよw

**デフォルトの名無しさん** · 2022/01/17(月) 23:06:59.06

はっはっは、だから言ったろ
お前が非同期処理を理解してないって

想像した通りに動いてくれるわけじゃないのだよ
不可能なことは、不可能

**デフォルトの名無しさん** · 2022/01/17(月) 23:11:50.20

>>18
そんなバグの温床になりそうなコード書くくらいなら、
componentDidMountでfetchして、素直にsetStateしとけ
それで済む話だろ

9 · 2022/01/17(月) 23:50:21.01

このスレは、荒らしが立てたスレです。
まともな人は、移動してください！

>>9-10
を参照

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

>>26
具体的な事言わずに批判だけするとか……老害かな？

**デフォルトの名無しさん** · 2022/01/18(火) 00:30:02.59

>>22
パラメータが変わらなければ同じpromiseが再利用されるので問題ない

**デフォルトの名無しさん** · 2022/01/18(火) 15:39:09.53

>>30
fetchFooは（シングルトンみたく）何度呼び出しても同じPromiseを返すって事か。それなら確かに問題ない。
そう云うPromiseを作るhookと待ってる間はFragment（か何かをDOMに接続）、あとエラー時用のインターフェイス（Promise関連だからcatchメソッドで良いか）が必要、と。
う～ん、俺はuseEffectでいいやw

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

>>31
そうじゃない
react側で不要な再実行を避けてpromiseを再利用するように作るだけ

**デフォルトの名無しさん** · 2022/01/18(火) 20:36:42.52

FooViewが発行したPromiseインスタンスを再利用するという事？

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

lazyとSuspense、ErrorBoundaryを使う
データ単位で制御したいならRecoilを組み合わせる（Atomのdefaultやselectorで非同期処理）
>>13はRecoilとConcurrentModeがまさにそれ
あと>>16の"非同期関数食ってくれない"という表現が良く分からないのだが、即時関数を使えば良いという話ではないのだろうか

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

>>34
useEffectの引数に直接async function入れられなくて少し不便ってだけの話で特に特に問題無いから無視してええよ

**デフォルトの名無しさん** · 2022/01/19(水) 20:05:38.12

<ErrorBoundary onErrorComponent={ErrorView} >
<Suspence fallback={<Loading />}>
<Text>{props.foo.read().name}</Text>
</Suspence>
</ErrorBoundary>

一見すると良さそうだけど間違ってる
Textをラップするコンポーネントを作ってやらんとダメ
なんか書くものが多くてめんどくさい
後は純粋に醜い
処理フローの制御をタグで書きたくない

recoilって正直なとこContext APIやReduxより多少スマートだけど根本的なとこはあんま変わってないと思う
というかrecoilって基本は状態管理ライブラリだし非同期のめんどくささとはまた別の話では？

**デフォルトの名無しさん** · 2022/01/19(水) 21:22:56.22

ラッパー高階関数なりhookでも書けばええんちゃうか……。
目的を最小のコードて書けるライブラリは用途特化ライブラリであって、汎用たり得ないと思うんだ。

**デフォルトの名無しさん** · 2022/01/19(水) 22:03:34.62

Suspenseでラップされたコンポーネントで使われているAtomで
非同期処理を実行している間はfallbackが呼ばれるため、loading stateが不要であったりと
RecoilはConcurrent Modeを意識した作りになっている
というのを踏まえた上で、Reactはv18から非同期でコンポーネントを扱う場合は
Suspenseでラップする形を押していくようなので
その手法が嫌なら何とも言えない（あなたの提案が悪いというわけではなく、Reactの方針的に）

**デフォルトの名無しさん** · 2022/01/20(木) 02:46:03.95

そうやって過剰な設計をするならReactとかの
フレームワークは重くなるんですよね

**デフォルトの名無しさん** · 2022/01/20(木) 07:10:36.24

重いってのは色んな要素や意味があるし、かなり曖昧表現だな。
スピードテストベンチマークも増えて、一時期に比べればみんな速度を意識しだして、Webって早くなってきたよ。

**デフォルトの名無しさん** · 2022/01/20(木) 12:12:04.67

>>40
帯域制限中の格安スマホ

**デフォルトの名無しさん** · 2022/01/20(木) 12:21:04.70

ここ数ヶ月で重すぎてブラウザバックした記憶はqiitaだけだな
あれは何のフレームワーク使ってるんだろ

**デフォルトの名無しさん** · 2022/01/20(木) 12:25:07.74

qiitaはスマホが発熱するレベルで熱くなる

**デフォルトの名無しさん** · 2022/01/20(木) 12:47:36.33

>>41
なる程。となると容量だな。
帯域制限状態を256kbpsとするとminify+gzipなReact(ReactDOM含む)で36KBなら1.125秒か。時間かかるっちゃかかるけど、この速度域だと画像すら重すぎてそれ以前の問題だなw

**デフォルトの名無しさん** · 2022/01/20(木) 12:52:08.95

結局のところ単純で速い方がいい
reactでゴテゴテに装飾したSNSより伍ちゃん戦ブラが良いんだな

**デフォルトの名無しさん** · 2022/01/20(木) 12:58:52.80

今のSNS大抵レスポンス良いぞ

**デフォルトの名無しさん** · 2022/01/20(木) 13:02:02.17

そもそも目的や規模感、場合によってはチームの習熟度で不足にも過剰にもなる
結局は毛嫌いせず、状況に応じて使い分ければ良いだけの話

**デフォルトの名無しさん** · 2022/01/20(木) 16:56:37.93

>>42
あれフレームワークっていうより遅延ローディングの問題な気がしてる
バックエンドが詰まってる印象

**デフォルトの名無しさん** · 2022/01/20(木) 20:33:47.49

>>42
> ここ数ヶ月で重すぎてブラウザバックした記憶はqiitaだけだな

普通にネット見ていてもReactのような
重量系フレームワークを使ってるところなんて殆どないからね
QiitaはReact使ってるみたいだけど、一体あれのどこに必要なんだろうか

**デフォルトの名無しさん** · 2022/01/20(木) 20:53:35.92

とりあえずSSG使ってCDNにpushすれば解決するのだがそういう改良する人材もいないんだろうな
元々優秀な技術者集団がいたはずだけど
技術のコモディティ化でその人たちも凡人になったのか
人がいなくなったのか

**デフォルトの名無しさん** · 2022/01/20(木) 20:54:50.03

何をもって『重量系』？

**デフォルトの名無しさん** · 2022/01/20(木) 21:04:59.02

>>50
Qiitaの親会社の偉い人に合った事あるけど、技術や技術者の事なんてどうとも思ってなさそうな人だったよ。それからしばらくしてあの炎上騒ぎが起きて、さもありなんと思った。

**デフォルトの名無しさん** · 2022/01/20(木) 23:08:25.65

>>49
Zenn、Twitter、Instagram、Facebook、LINE、Yahoo、ZOZO、はてなブログ、AmazonのAWSの管理画面などなど
これらはフロント全体もしくは部分的にReactだけど？
Googleは多くのサービスでAngularだし

普段ネットで見てんの？

**デフォルトの名無しさん** · 2022/01/20(木) 23:31:12.23

掲示板のレスの1つ1つに開閉式のメニューをつけるのってどうやるんだ？
下はyahooニュースだが、レス一覧の「非表示・報告」ってとこ押したら出てくるような奴
https://news.yahoo.co.jp/articles/5d52fe0f406f1aa3e9f2263f58966858786bf8a0/comments
vue だったらレス一個一個にコンポーネントマウントしないといかんのか？？