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 だったらレス一個一個にコンポーネントマウントしないといかんのか？？

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

>>54
VueでもReactでもAngularでもそう

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

>>55
なるほど。内部的には各ボタンにイベントリスナーつけるわけだから当然と言えば当然ではあるか。
サーバ側ではレスをPHPでforeach で回して出力するけど、そのタイミングでvueがマウントするためのコードを生成する必要があるってことなのか？

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

>>53
noteなんかはVue使ってるしな

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

vue選んだ会社はどうするんだろうか
オワコンまっしぐらなのに

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

生田勇人(39)
高知市朝倉中学校卒業
恐喝と暴行、偽証、傷害容疑で逮捕、起訴。
://togetter.com/li/1227954
://pbs.twimg.com/media/DbUOGw1VQAAqJcx.jpg:large
://i.imgur.com/tuUldwv.jpg
://www.youtube.com/watch?v=UyNXI8usCrM
取り調べで「事実無根」と容疑を否認。
卓球所に松岡学(39)と出入りし賭け試合を被害者に強要、一回ミスったら1000円払えと発言。
2万円を取ろうとした。親にチクったらただじゃ済まんぞと被害者の胸倉をつかみ壁に叩き付け2000円を脅し取り、後日腹を複数回殴った疑い。
生田勇人の両親も被害者の親にたかっていた。

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

>>56
一例だけど、ページが読み込まれてCommentListコンポーネントがマウントされたタイミングでサーバからコメントを取得して
メニューを持ったCommentコンポーネントをcomments.mapで回す
この時のcommentひとつひとつをCommentコンポーネントのpropsに渡して描画していく

**デフォルトの名無しさん** · 2022/01/21(金) 00:48:10.29

Vueはそもそもの背景にAngularがあるのに
Composition登場以降、React寄りになったのが何とも
今のVueはどこに向かっているのか分からん

**デフォルトの名無しさん** · 2022/01/21(金) 00:54:42.07

>>54
https://codesandbox.io/embed/dark-dawn-0sk8t?fontsize=14&;hidenavigation=1&theme=dark
↑ でけたで！！！
VueじゃなくてReactやけども

みんなもよかったらコードレビューしてや！

これ思たんやが、メニューの中身共通やんか
ヤフコメの仕様に合わせて同時に複数開けるようにしたからこうしたけど、同時に複数開かなくてもいいっていう仕様やったらばよ
各コメントのカードの中にメニュー含めず、メニューは外に出して1個だけ記述する方が無駄なさげな気するんやがどないなん
コード的には同じもんが複数あるってイメージが湧いてしまうわけやが、基本マウントされてないから別にええんか
意味わからんかったらすまんやで

**デフォルトの名無しさん** · 2022/01/21(金) 02:20:49.29

その考え方で良いと思う
表示非表示といっても、仮想DOMのおかげで差分が更新されるだけなので
ひとつのメニューを座標などを保持してまで使い回すメリットがほとんどない

表示されているメニューをひとつだけとするなら
メニューを透明なBackdropと共に描画して、メニュー外がクリックされた場合はメニューを閉じるようにする
これはMUIのBackdropやMenuコンポーネントを参考にすると分かりやすいと思う
他にはグローバルステートにして、ひとつが表示状態となった場合、他が非表示となるようにする
これはReduxで複数のダイアログの状態を扱う場合なんかに使われたりする
規模感にもよるが、今だとRecoilで管理するのがシンプルでおすすめ
他にはonMouseLeaveで非表示にするのもアリかもしれない

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

>>60
やっぱりコメント自体を非同期で取得してくるしかないのかあ・・・。
現在の仕様やと、サーバ側でコメントをhtml生成してからレスポンス返しているから、作り直すの大変やなあ。
開閉メニューだけをvueでコンポーネント作ってってことをできんかと思ってたけど厳しいかもなあ。
ちなみに生JSで開閉メニューを作成済みなのだが、それをvue に書き換えたかった。

>>62
うおおおおおおおおすげええええ
でもreactわからん・・・・・・vueでも同様のことができるんやろなあ。
メニューの中身は共通やけど、yahooの例で言えば非表示と報告やからそのコメントを特定できるIDみたいなものをサーバに送るために仕込んどかんといかんのや。。。

**デフォルトの名無しさん** · 2022/01/21(金) 05:23:06.12

>>42
Railsは、GitHub, Airbnb, Disney, Hulu, SoundCloud, Shopify といった世界的に有名な企業や、
日本国内でも、note、クックパッド、freee、マネーフォワード、Progate、Qiita などで使われている

2021年10月には、Railsを使い続ける宣言をしている、GitLab が上場し、時価総額は約1.9兆円！

時価総額1兆円ぐらいまでは、Railsで行ける。
その後、Go へ移行する

ここで、URL を入力して、サイト分析できる
https://builtwith.com/

65 · 2022/01/21(金) 05:34:51.10

女の娘が1人で起業した、食べチョクは、Rails, React

食べチョクは、生産者と消費者を結ぶ、農林水産物の直販サイトだけど、
コロナで取引量が30倍になったとか

海外のRailsでは、ほとんどReactが多い

ただ日本は特殊で、YouTube で有名な、雑食系エンジニア・KENTA のサロンでも、
未経験者の転職用にはReactよりも、Vue.js を使うように指示している

65 · 2022/01/21(金) 06:17:34.93

Rails では、命名規約だけのフレームワーク・Stimulus もある。
イベントの書き方だけを決めている

Railsの作者・DHH が、デモなどでよく使う

1つのDOM に、コントローラーを複数設定できる
<div data-controller="hello goodbye"></div>

また、同じコントローラーを複数のDOMに設定できる
<div data-controller="hello"></div>
<div data-controller="hello"></div>

つまり、多対多

アクションはクリックで、helloコントローラーのgreet メソッドを呼ぶ
<button data-action="click->hello#greet"></button>

ターゲットを設定すると、this.nameTarget, this.outputTarget で、
ターゲットとなるDOMを取得できる

static targets = [ "name", "output" ]

greet() {
this.outputTarget.textContent =
`Hello, ${this.nameTarget.value}!`
}

ターゲットとなるDOM。helloコントローラーのname・outputターゲット
<input data-hello-target="name" type="text">
<span data-hello-target="output"></span>

**デフォルトの名無しさん** · 2022/01/21(金) 07:05:45.77

>>62
ややこしいstate管理してるな、コメントカードをコンポーネントにしてstate持たせりゃコード半分で済むやんけ、と思ったらメニュー使いまわそうとか考えてたのね。なるほど。
細かい所言うとfetchはPromiseな方がそれっぽい雰囲気になってええんちゃう、くらいかな。

>>64
html生成をjson生成に変えるだけだから楽なもんよ（悪魔のささやき）
Vue使う使わない以前に、コメントにはID付けた方が良いし、コメントは生htmlじゃなくてjsonあたりから都度生成の方が良いと思う。

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

プライベートなシステムの管理画面で複雑なReact使ってるけど重くもなくむしろ速い
どちらかというとサーバーにアクセスするAPIのほうが遅くてローディングアイコンくるくるしてる
閉鎖的なシステムだから業務ロジックはバックエンドではなくほぼtsで書いてるから処理は速い

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

>>53
お前のインターネットの世界には
それだけしかないのか？

**デフォルトの名無しさん** · 2022/01/21(金) 11:15:00.08

コンピュータ用語と関係ない用語で検索してTOP10のサイトが
どのフレームワークを使っているか確認してみればいい
例えば「ネコ」で検索するとかな

**デフォルトの名無しさん** · 2022/01/21(金) 11:46:13.84

殆どない、に対してのレスだから
適当に列挙してもこれだけあるよ？って話でしょ

**デフォルトの名無しさん** · 2022/01/21(金) 11:54:33.96

適当に列挙したと言う割に
有名なコンピュータ関連の会社に偏ってるから
ダメだって話をしてる

適当に列挙させるために
コンピュータ用語と関係ない用語で
検索したサイトで調べろと言ってる

**デフォルトの名無しさん** · 2022/01/21(金) 12:09:01.10

ま～たあんたか。今日もご苦労さん

**デフォルトの名無しさん** · 2022/01/21(金) 12:16:03.07

そんな謎調べ物させる前に重いサイト列挙すりゃ済む話やろ

**デフォルトの名無しさん** · 2022/01/21(金) 12:45:58.84

ループ内でuseState使えるようにはできないのかなー
これ完全にフレームワーク設計の欠陥だよね

自分も>>62みたいな書き方をよく書くけど配列から子コンポーネントに渡すpropsに変換する手間がかかって面倒くさい
しかも配列の1要素を変更しただけで配列全体が変更されたとみなされてイベントハンドラが更新されて子コンポーネントも更新されるのが気になる

純粋な子コンポーネントをラップしてstateを持たせたコンポーネントをプライベートスコープに書いて
そのラップコンポーネントを使うって手も有るけどこれはこれでめんどくさい

かと言って子コンポーネント自体に副作用を持たせるとテストがめんどくさくなって再利用性も下がる

**デフォルトの名無しさん** · 2022/01/21(金) 12:54:15.65

>>73
“殆どない”に対して”あるけど？”ってことなんだが大丈夫か？

**デフォルトの名無しさん** · 2022/01/21(金) 13:00:10.73

>>76
いや、仕組みを考えればなぜそういう仕様なのかはわかるよ

**デフォルトの名無しさん** · 2022/01/21(金) 13:00:46.06

ListやListItemなら再利用前提だけど
CommentListやCommentListItemとかになる固有だったりするから内部に状態を持たせたらいい
テストが大変、ってことならカスタムフックでロジックを分離すればいい

**デフォルトの名無しさん** · 2022/01/21(金) 13:10:35.79

>>78
仕組みの問題なのはわかるけど
利用者の立場を考えたインターフェースデザインになってないのはフレームワークとしては残念ポイントだね
本当に良いフレームワークはまず使いやすいインターフェースがあってそこに実装を合わせていく
「実装の都合のせいで関数トップレベルにしかフックかけません」ってのはそう言う意味では怠慢かな
「どこでも書けるように実装の方で勉強しました」こういう姿勢が必要

**デフォルトの名無しさん** · 2022/01/21(金) 13:12:23.42

>>79
固有になるかどうかは場合によるよね

**デフォルトの名無しさん** · 2022/01/21(金) 13:16:50.88

>>76
状態を呼び出されたインデックスで管理してるんだからむしろわかりやすいと思うが
「副作用の内容」は全く意識しなくて良いのよ
そこはreactに丸投げできる
これこそHooksの素晴らしさ
わかりにくいと感じるのは副作用を意識してなさすぎるから
react難しいと言ってる人は関数型言語などの副作用、参照透過性、冪等性、(できればモナド)などその辺りを勉強し直した方が良い

**デフォルトの名無しさん** · 2022/01/21(金) 13:20:29.63

>>80
そういう意見もわからんでもない。
ただ、俺はそういう制約はあえてやってると感じるな。一見不便な制約だけど、それがある事によってコードが統制される。React的に正しい書き方に矯正される。

**デフォルトの名無しさん** · 2022/01/21(金) 13:46:47.17

ドキュメントにフックがトップレベルでしか呼び出せない理由って説明されてるけどな

**デフォルトの名無しさん** · 2022/01/21(金) 13:58:56.69

CommentListも再利用前提ならプレフィックスを付けてArticleCommentListにしたらいい
ファイル数は増えていくが、コンポーネントをシンプルに保つ恩恵の方が圧倒的にでかい

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

結局はチームで統一されてれば良いって話ではあるけどね

**デフォルトの名無しさん** · 2022/01/21(金) 20:32:48.44

>>68
axios で投稿一覧取得して vue で表示する処理を書いたけど、
サーバ側でphpのforeachで回してた時htmlspecialcharsでエスケープしたり文字列操作したりしてたことをvue側でせないかんってことだよな？
なかなかめんどくさい気がしてきたがこのあたりどうしてるんだろうか

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

マスタッシュ構文ならふつうにエスケープしてくれるはずだが

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

>>87
逆に今時それを自動でやらないフレームワークなんてあるのか？

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

dangerouslySetInnerHTMLとかいう長くて物騒なパラメータ名大好き

**デフォルトの名無しさん** · 2022/01/21(金) 23:16:24.74

>>69
>サーバーにアクセスするAPIのほうが遅くて
そりゃ、データベースの外部キーとか、インデックスの張り方による。
N + 1 問題とか

Ruby on Rails の単一テーブル継承とか、多対多・1対多・1対1 とか、
高度資格のdatabase specialist みたいな国家資格とか

>>76
>配列の1要素を変更しただけで配列全体が変更されたとみなされて
Vue.js では、key を付ければ、他の要素に影響がないけど、
React には、そういう機能が無いの？

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

>>77
まったくないじゃなくて
殆どないって言ってるんだから
あるのは最初からわかってるだろ
お前ゆとり蚊？

**デフォルトの名無しさん** · 2022/01/22(土) 06:18:54.77

はいはい、そうだね。がんばってね

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

NextAuth.jsって使ってる人いる？

**デフォルトの名無しさん** · 2022/01/22(土) 09:02:27.22

>>93
もう終わったよｗ
ほんと有名な事例だけ上げて
それが全てだと思ってるからアホやで

**デフォルトの名無しさん** · 2022/01/22(土) 09:08:30.48

日本語でおk

**デフォルトの名無しさん** · 2022/01/22(土) 17:28:48.01

最近はReact優勢らしいけど個人での小規模開発でもVueオワコンなの？
転職用のポートフォリオの為にGoとVueでウェブアプリケーション作ってるんだけど今からでも変えた方がいいのかしら

**デフォルトの名無しさん** · 2022/01/22(土) 17:30:01.75

>>97
優勢というかほぼ決着はついた
Reactにしとけ
vueは未来がない

**デフォルトの名無しさん** · 2022/01/22(土) 20:09:13.48

Vueは結局一回も触らんでオワコンなった
我ながら良い選択をしたね
今後メンテナンスしなきゃならん人はご愁傷様

**デフォルトの名無しさん** · 2022/01/22(土) 20:19:21.52

今からVueとか罰ゲームかよ

**デフォルトの名無しさん** · 2022/01/22(土) 21:56:09.98

https://zenn.dev/ytr0903/articles/d0a91f6180d34e
↑
reactばっか使ってるわしはこれ読んで良さようやんって思ってんけどな
vueは具体的に何がオワコンなんだい

**デフォルトの名無しさん** · 2022/01/22(土) 22:36:32.62

アジア圏でしか使われてない
Angularとずっとシェアがトントン

**デフォルトの名無しさん** · 2022/01/22(土) 22:56:29.72

>>101
現在のvueのベストプラクティスと言われてる書き方を見てみな？
ほぼReactでしょ
つまりそういうこと

**デフォルトの名無しさん** · 2022/01/22(土) 23:09:14.68

>>101
そもそもbetter angularというコンセプトの元
人気が出たvueだがその記述方法がオワコン化するに従って
Reactの機能を取り入れ始めた
そして全てがReactになる

**デフォルトの名無しさん** · 2022/01/22(土) 23:18:25.01

別にvueでもいいと思うぞ
ここでオワコン言ってるやつは、そいつがそうなってほしいだけ
まあ、時間がそのうち決めるだろうさ

**デフォルトの名無しさん** · 2022/01/23(日) 00:34:43.39

単一ファイルコンポーネントはわりと好きだった

**デフォルトの名無しさん** · 2022/01/23(日) 00:38:59.45

これからはSvelteが流行るって聞いて勉強してるんだがそろそろReactもオワコン扱いしていかないか？

**デフォルトの名無しさん** · 2022/01/23(日) 00:58:41.28

Svelteが殺してしまうのは多分ReactじゃなくてVueなんだろうな……

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

>>108
多分そうなると思う
結局Reactの素晴らしさはコンポーネントとHooksとJSXの連携なのだから
そこを避けようとするフレームワークはどこまでいってもReactになれない

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

laravelとVueは中国語のドキュメントが充実している

65 · 2022/01/23(日) 05:44:45.01

日本は特殊で、YouTube で有名な、雑食系エンジニア・KENTA のサロンでも、
未経験者の転職用にはReactよりも、Vue.js を使うように指示している

誰か、Vue.jsがオワコンかどうか、KENTAに聞いてみてくれ

PHP, Scala は、KENTAがオワコン認定したから、もう新規プロジェクトは無い。
ZOZO はLaravel だけど、創業者の前澤が、会社の株を孫正義に2千億円で売って逃げた

**デフォルトの名無しさん** · 2022/01/23(日) 05:51:50.36

KENTA？
誰？

**デフォルトの名無しさん** · 2022/01/23(日) 07:22:45.53

ケンタはフロントが絶望的にできないからお呼びではない

**デフォルトの名無しさん** · 2022/01/23(日) 17:21:31.55

中国人ならvue
それ以外ならreact

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

これからはvue3 x Nuxt 3だよ
Reactなんて外国にカブれてる奴が使ってるだけだろ

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

中国被れがなんか言ってるぞ

65 · 2022/01/24(月) 04:23:26.19

KENTA・勝又健太は、YouTube のRuby on Rails 初心者向け有料サロンの主。
月千円で、日本6位の3千人が入っている。
1位は、キングコング西野の数万人

Vue.js 日本ユーザー会も3千人で、1つのRailsサロンと同じ人数

KENTAは、日本にプログラミング教育革命を起こした。
1年ぐらいの勉強で、10年以上のプログラマーよりも上

最も短時間の勉強で、給料を上げる方法を見つけた人。
それが、Rails のバックエンドエンジニアになる事

KENTAの普及により、今じゃ未経験者でも、
Bootstrap, Heroku, Docker, CircleCI が当たり前

今や、AWS Fargate, GitHub Actions, Terraform,
TypeScript, React, Vue.js 出来ないと差別化できない

今の未経験者は、それぐらいハイレベルな領域で戦っている。
10年以上の化石プログラマーは、太刀打ちできない。
使っている道具が違うから

ツルハシで掘っている土方と、巨大なメカで、トンネルを掘っているのとの違い。
それに初めて気付いて、教育革命を起こした

**デフォルトの名無しさん** · 2022/01/24(月) 08:40:30.54

いつもKENTAの宣伝しにくる人のレベルを見るとKENTAのレベルの低さが如実にわかる

**デフォルトの名無しさん** · 2022/01/24(月) 20:21:01.57

svelteはvueの正当進化系
vue3の中身がsvelteでもおかしくないはずだった

**デフォルトの名無しさん** · 2022/01/24(月) 20:38:11.48

じゃあvue君次はsvelteにすり寄ればええやんけ

**デフォルトの名無しさん** · 2022/01/24(月) 20:56:17.77

vueって仮想DOM使ってないんだったっけ？
マイナーだからよく知らんが

**デフォルトの名無しさん** · 2022/01/24(月) 21:27:03.91

この指摘は結構的確
https://www.youtube.com/watch?v=td6cX0en4oI

**デフォルトの名無しさん** · 2022/01/24(月) 22:04:02.46

フロントは各自が好きなもの使えばいい
そのためにバックエンドと切り離したんだからね
明日オワコンなってもすぐに乗り換えられる安心感

**デフォルトの名無しさん** · 2022/01/24(月) 23:08:34.60

KENTA の天敵・モローは消えた

モダンな自社開発系Ruby on Rails のKENTA vs
旧態依然のJava 土方を集める、SES のモロー

みずほ銀行の2千億円・統合プロジェクトも終わって、Java土方の仕事が無くなった。
それで、みずほ銀行はバグってばかり

可読性も悪いし、巨大すぎて直せない

**デフォルトの名無しさん** · 2022/01/24(月) 23:48:28.66

サーバーサイドはPHPが一番分かりやすい
Rubyなんて論外ｗ遅いし見にくいｗ

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

わかりやすい≒使いやすい、ではないと思う。それはそれとしてPHPもすごく進化して昔とは別物らしいな。使ってないから知らんけど。

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

>>126
いいなぁ

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

Rubyは遅いし世界的に廃れているしな
イキってた残りカスがそこら中でケンタと一緒に宣伝してるがそもそも言語として論外

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

いつものRubyガイジがやたらとKENTAに言及してるのなんでだろう？と思ってたんだが
そのKENTAとやらがRubyを推してるっていう理由だけなのか

この板についてはRubyもKENTAもNGWordに突っ込んでおけば万事解決だな

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

ReactのHookはsvelteのstoreの

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

ことかな？

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

フック船長はなんでもありな感じ
Reactの純粋さにとって都合が悪いものをまとめて隠蔽するヤバい奴

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

当方、svelteでwebアプリのフロントエンドを学んでいるが

javascriptの型無し && スレッド意識せず && 引数の参照渡し && エラーマネジメント皆無

で、すぐ迷宮になりそう。
こんな言語仕様でよくチームで組めますね…怖い

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

TSにすること
入力を常に信用しないこと(型が付いてても)
出力も信用しすぎないこと
OSSライブラリは間違っている前提でラップする事
関数を盲信せず普通にオブジェクト指向すること
typeフィールドで望まないダックタイピングを抑制すること

これがフロントエンド開発のコツやね

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

>>133
大丈夫、JavaScript怖くないよ！

> javascriptの型無し
TypeScriptとバリデーションで解消
> スレッド意識せず
WebWorker使わなきゃスレッド関係ない。非同期の話なら他の言語でも使われてるから慣れた方がいいかと。
> 引数の参照渡し
なんか問題ある？
> エラーマネジメント皆無
TypeScript使ってれば殆どの実行時エラーは潰せるので、あとはサーバとの通信時くらいになる。そのへんはPromiseなのでcacheメソッドで処理する（RustのResultみたいに）

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

ReactとMaterialUIを昨日から始めたんだけど
既に挫折しそう…

https://i.imgur.com/x7ii8B0.png

ボタンの色を変えたいだけなんだけど
色んなページを見ながらやっていて
これで色は変わったんですが
ボタンを押したら指定した色ではなく
白色にボタンが変化してしまいます

なんか設定が間違ってるんでしょうか？

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

ちなみにvariant="contained"を消した場合
ボタンを押したらボタンが消滅します
リロードすればまた緑色のボタンとして復活します

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

jQueryでやりたい…泣

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

結構色んなサイトを見て
やり方とかimportする内容が違ったりするんですが
色々なパターン試してみた結果
色を変える事が出来るんですが
やっぱりボタンを押すと色がトンチンカンな色になります
sxプロパティで赤色に変えた時は
クリック後に青色になります
もう意味が分からない…

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

これ消えてるわけじゃないのか
materialUIってもしかして背景が黒の場合が
全く想定されていないUIなのか…

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

個人的な意見だけど見た目をカスタマイズしたい要件があるときはサードパーティコンポーネントは使わずにゼロから作る方が楽だと思う
便利な機能を持ったサードパーティコンポーネントが使えなくなるのは残念だ
だけど見た目の変更の仕方がわからなくなって何時間もハマるのはもっといやだ
サードパーティコンポーネントでやると決めたら拘りは捨ててコンポーネントを並べるだけで最後まで突っ走る

この見た目の定義がコンポーネントに隠蔽されてるのでカスタマイズしにくい問題をreactの達人はどうやって解決してるんだろう？

**デフォルトの名無しさん** · 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とマルチページアプリってそこまで差がないと思うなー
普通の自転車とロードバイクぐらいの差かなー？
つうか差がないどころか使い勝手はマルチページアプリの方が良いとすら思ってるよ
自転車の例えで言うと「あのー速いのはわかったんですけど、ロードバイクのハンドル持ちにくいんでね。普通のハンドルにしてくれませんか？」みたいな感じ