Vue vs React vs Angular vs Svelte Part.8

**デフォルトの名無しさん** · 2021/05/23(日) 13:42:32.51

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/

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

**デフォルトの名無しさん** · 2021/10/20(水) 18:11:23.46

LaravelMix使うとwebpackの設定は割と簡単に書けるからオヌヌメ

**デフォルトの名無しさん** · 2021/10/20(水) 18:36:50.70

>>206
ざっくり理解すれば十分ってのは同意。よほど踏み込まない限りWebpackも難しいものでない

**デフォルトの名無しさん** · 2021/10/20(水) 19:04:13.89

Laravel使う現場って実在するのかよ
プログラミング教室でしか使わんだろと思ってたわ

**デフォルトの名無しさん** · 2021/10/20(水) 20:36:56.01

ParcelでWebpack要らなくなるとか言われてたけど結局こんなもんだな。

**デフォルトの名無しさん** · 2021/10/21(木) 21:00:18.94

laravelは割と主流派だぞ。
laravelmixは信者しか使っていないと思うが。

**デフォルトの名無しさん** · 2021/10/21(木) 22:00:40.93

ホームページ屋さんが頑張って使ってるミドルウェアな印象

**デフォルトの名無しさん** · 2021/10/22(金) 00:24:44.17

Reactできる人はみんなCSS作れるの？

**デフォルトの名無しさん** · 2021/10/26(火) 08:53:22.03

おまえらPage Insightの結果はどのぐらい当てにしてる？
SPAは評価悪くなるよな
評価上げるためにリファクタリングするのに疲れちゃったよ

**デフォルトの名無しさん** · 2021/10/26(火) 14:12:43.81

>>214
SSRとハイドレーションやろう
サイトによるがそもそも気にしないという選択肢は十分あり

**デフォルトの名無しさん** · 2021/10/26(火) 18:19:21.84

CSRだけだとページ表示ユーザ体感が悪すぎるしSEOも不利なので一般向け情報ページならば
SSR/SSG＋プログレッシブリハイドレーションが良いでしょう

**デフォルトの名無しさん** · 2021/10/26(火) 19:38:14.90

CSRって言うほど遅いか？

**デフォルトの名無しさん** · 2021/10/26(火) 19:50:13.16

規模によるとしか
旧来のサーバーサイドのルーティングで十数ページに渡るような内容をSPAにしてCSRにした場合等はえらいことに
まあ継ぎ足しロードとかにするんだろうけど

**デフォルトの名無しさん** · 2021/10/27(水) 17:31:41.81

そこまでするならそもそもSPAという選択が間違ってるような
よくあるコーポレートサイトやブログってSEO命なのにそれを犠牲にするってのは本末転倒

**デフォルトの名無しさん** · 2021/10/27(水) 18:10:31.77

それはそう
コーポレートサイトやブログのようにほとんど変化ない情報が掲示されるようなサイトはSPAの恩恵はほとんど受けられず悪い影響は被っていいとこない
向き不向きあるとは前から言われてたのに人は金づち持てば全部釘に見えるようで…

**デフォルトの名無しさん** · 2021/10/27(水) 18:23:58.28

逆にログインして操作する業務システムでSSRはあんまり意味無いと思うんだがやりたがる人結構居る、

**デフォルトの名無しさん** · 2021/10/27(水) 18:24:23.65

単純にSEOとページインサイトを考慮するならspaじゃなくて静的ページジェネレーターがベストだろうね
動的サイトとの間をとってgatsbyとかで自動化するのが今風な感じする

**デフォルトの名無しさん** · 2021/10/27(水) 18:26:01.69

>>221
逆にSPAを知らないんだろうね
何ができるか
なぜSPAなのかを

**デフォルトの名無しさん** · 2021/10/27(水) 18:31:22.35

>>221
なんでなんだろうね

**デフォルトの名無しさん** · 2021/10/29(金) 01:19:58.10

Nuxtはじめた＾＾
なんか注意事項とかあったらレスくださいね＾＾

**デフォルトの名無しさん** · 2021/10/29(金) 09:45:43.75

>>222
Gatsbyやってみたけどなんか…
電球一個取り替えるのに椅子に乗ってその椅子を４人で回すみたいな大ごとになってなんだかなぁと思ったわ
それほんとにGraphQL介す必要あるの？とか

**デフォルトの名無しさん** · 2021/10/29(金) 10:16:20.65

草
俺はなんかしっくり来ないなと思ってNextに行った。まぁ最終的には同じような事するわけだが

**デフォルトの名無しさん** · 2021/10/31(日) 00:31:15.09

react周りserver componentsだっけ？
なんかそういう頑張って良いとこどりしようとしてるけど、
開発者が追いきれてない感じがして混迷しつつあるように見える
やりたいこととやり方はわかるけど、結局自分らがどう選択していくの？がまとめずらい
選択肢が無尽蔵に増えそうで二の足を踏み続けそう

**デフォルトの名無しさん** · 2021/10/31(日) 10:26:35.06

○ 俺が追いきれてないので気に入らない
○ やりたいこともやり方も分からない
○ 俺が二の足を踏み続けている

**228** · 2021/10/31(日) 13:23:41.80

>>229
マジか、みんな迷わず選択できてんのか。。

**デフォルトの名無しさん** · 2021/10/31(日) 16:00:33.45

素直にVueやっとけばいいのにな
対して難しい事しなくてもやりたい事は大抵出来るし
新参にも教えやすい

**デフォルトの名無しさん** · 2021/10/31(日) 17:02:35.69

そういう用途だとSvelteの方がよくね？
と思ったけど、情報とか使える人が少ないかな？

**デフォルトの名無しさん** · 2021/10/31(日) 19:27:19.49

結局全部試すくらいの覚悟がないならフロントフレームワークなんて使うべきじゃないと思うよ

**デフォルトの名無しさん** · 2021/11/01(月) 17:25:47.13

今はある程度選択肢は固まってるし
まあReactで、と言えるだけ随分楽になったよ

ただ、根底にある思想みたいなのは
スレタイにあるvue,react,angulaのどれも共通部分が多いよ
実装が違うだけで結局やることはそう変わらん

**デフォルトの名無しさん** · 2021/11/01(月) 19:01:35.40

とりあえずreactでよくね

**デフォルトの名無しさん** · 2021/11/01(月) 21:06:39.51

でも状態管理めんどうじゃん

**デフォルトの名無しさん** · 2021/11/01(月) 22:19:00.30

そりゃ何使ったって面倒なのは変わらない

**デフォルトの名無しさん** · 2021/11/03(水) 20:12:21.93

結局Recoil使うのが一番シンプルだけどな

**デフォルトの名無しさん** · 2021/11/03(水) 20:22:47.27

個人的にはApollo clientでの状態管理が一推し

**デフォルトの名無しさん** · 2021/11/04(木) 18:05:57.56

SPAでもそんな複雑な管理をクライアントでやったりするのかなぁ

**デフォルトの名無しさん** · 2021/11/05(金) 20:20:10.24

SPAではせざるを得ないってとこだよね
本来は誰もやりたくない

**デフォルトの名無しさん** · 2021/11/05(金) 20:31:18.88

SPAはSPAで楽な部分もある

**デフォルトの名無しさん** · 2021/11/05(金) 20:33:19.00

ただ小規模なサイトであっても何かしらのフレームワーク使う事が大前提になった。以前のもメンテはするが

**デフォルトの名無しさん** · 2021/11/05(金) 21:04:41.58

JWTやマイクロサービスを踏まえるとクライアントで状態を持つのが前提になってきてるもんね
クライアントでの状態管理は必須

**デフォルトの名無しさん** · 2021/11/06(土) 01:35:43.68

Reduxは最近出ているReactの技術書では全く取り上げられなくなったな

**デフォルトの名無しさん** · 2021/11/07(日) 13:05:03.32

改版を期に削除されたりしてるよね

**デフォルトの名無しさん** · 2021/11/07(日) 16:59:15.63

狂信者はいるけどみんな大嫌いだったもんな
Context APIで全部解決出来れば楽なんだけどね
選択できる自由があって贅沢な悩みではあるけど

**デフォルトの名無しさん** · 2021/11/07(日) 23:09:54.55

useCentextよりもRecoidの方が明解でいいと思うけどな

**デフォルトの名無しさん** · 2021/11/07(日) 23:56:40.78

recoilじゃなく？

**デフォルトの名無しさん** · 2021/11/08(月) 00:01:11.85

ごめんタイポ

**デフォルトの名無しさん** · 2021/11/08(月) 08:32:50.39

このへんはredux一強から戦国時代に入った感じかな。大勢が決まるまでは情報収集しつつ様子見。

**デフォルトの名無しさん** · 2021/11/08(月) 16:26:00.60

このままrecoil一強になってreduxの息の根止めた方が世界の為
Reduxのあれをするにはあれやこれやが追加で必要でもっと勉強して下さいとかニートじゃないと対応出来ないって

**デフォルトの名無しさん** · 2021/11/09(火) 09:40:57.48

Reactの入門ググったら未だにRedux Toolkitとか勧めてる輩いるもんな

**デフォルトの名無しさん** · 2021/11/09(火) 09:57:30.93

記事が古いんじゃねえの

**デフォルトの名無しさん** · 2021/11/09(火) 14:28:44.10

ReactってTypescriptじゃないと人権ないの？

**デフォルトの名無しさん** · 2021/11/09(火) 14:40:58.21

そんな話聞いたこと無いが

**デフォルトの名無しさん** · 2021/11/09(火) 15:20:58.65

Typescriptなんて逆に消えそう

**デフォルトの名無しさん** · 2021/11/09(火) 15:39:50.35

typescriptはjavascriptに吸収されるんじゃね

**デフォルトの名無しさん** · 2021/11/09(火) 18:43:32.60

GraphQL使ってる？

**デフォルトの名無しさん** · 2021/11/09(火) 19:57:04.69

使ってない、RESTで事足りてしまう。
いつかGraphQLがバシッとマッチする用途でシステム組んでみたい

**デフォルトの名無しさん** · 2021/11/09(火) 20:35:24.40

直接は使ってないけど、実は間接的に使ってる

**デフォルトの名無しさん** · 2021/11/09(火) 22:15:56.16

RESTの倍ぐらいSQLクエリ走るの見ると使う理由あるのかな？って思っちゃう
リクエストは減るんだろうけど
プロジェクトによるんかね

**デフォルトの名無しさん** · 2021/11/09(火) 22:20:10.24

聞いてるとRDBと相性悪そうだね
ドキュメント型DBならどう？

**デフォルトの名無しさん** · 2021/11/09(火) 22:39:09.81

GraphQLの好き勝手なクエリに対応するのはドキュメント型じゃかえって厳しいだろ。

**デフォルトの名無しさん** · 2021/11/09(火) 22:47:37.81

カラム指向DBでは？

**デフォルトの名無しさん** · 2021/11/09(火) 23:15:01.32

カラム指向DBって最適化の方向が違うだけでデータモデル的にはRDBと変わらんじゃん。

**デフォルトの名無しさん** · 2021/11/09(火) 23:28:35.57

じゃ、じゃあグラフ指向DB！？

**デフォルトの名無しさん** · 2021/11/10(水) 06:54:57.52

>>257
TypeScriptの型は少量で滅茶苦茶雄弁なコメントみたいなもの。おかげで新しいライブラリもサクサク使えるし、バグに震えることなく安眠できる。

**デフォルトの名無しさん** · 2021/11/10(水) 09:23:53.75

>>263
どれも一長一短
テーブル結合ではなく複数のサービスからのレスポンスをjoinする目的の物だからどんなデータベース使おうが総クエリ数は増える
ただマイクロサービスには最適だしフロントエンド開発も楽
GraphQLに合わせるんじゃなくて各サービスに合わせたデータベースの選択が最適解じゃないかと

**デフォルトの名無しさん** · 2021/11/10(水) 12:56:42.12

>>268
どこで妥協するかだけの話
普通の強い静的型付け言語をしてきた人たちから見ればTypeScriptはヌルくて甘いとなるし
型なし言語をしてきた人たちから見ればTypeScriptは面倒くさい
公平に見ればTypeScriptは中途半端な妥協の産物

**デフォルトの名無しさん** · 2021/11/10(水) 13:05:43.43

>>269
あとは更新よりも読み出しが多いケースならば
読み出し毎に各DB各サービスに問い合わせるよりも
読み出しに合わせた複合DBを保持してそこも常に更新維持するなど
無駄なクエリを減らして高速化の方向もありますね

**デフォルトの名無しさん** · 2021/11/10(水) 16:04:43.59

もうrecoil使ってええか？

**デフォルトの名無しさん** · 2021/11/10(水) 17:57:01.79

TypescriptはAltJSとして生まれたもの
実際JSより格段に安全に組みやすくなったしそれで十分
TSが選べる環境ならJSを使う理由は一切ない
生のCSS組んでる奴なんてとっくに全滅してるやろ

**デフォルトの名無しさん** · 2021/11/10(水) 18:13:52.95

>>273
Wasm上でのフレームワークも進化していてJavaScriptを使わずにフロントエンドが組める時代になりつつあるので
中途半端な立ち位置のTypeScriptをいずれ使わなくなるかもね

**デフォルトの名無しさん** · 2021/11/10(水) 18:26:43.21

WasmはWasmだけで完結できないので……

**デフォルトの名無しさん** · 2021/11/10(水) 18:35:53.64

というか他の言語使おうが結局DOMを触る必要があって、余程上手にラップしないとJS的なフワフワ世界に突っ込む上にオーバーヘッドが出る。それなら最初からTS|JSでええやんってなる（なってきた）。
今後のことはわかんないけどね

**デフォルトの名無しさん** · 2021/11/10(水) 18:42:00.78

wasm自体が未完成だから未来の覇権は誰にも読めない
それこそTS→wasmが可能になってるかも知れんし

**デフォルトの名無しさん** · 2021/11/10(水) 18:54:14.88

TS使っても現状anyだらけで、意味あるんかいなって思う

**デフォルトの名無しさん** · 2021/11/10(水) 19:25:27.12

>>278
そうはならんやろ……。たまにas使ったりはするけど

**デフォルトの名無しさん** · 2021/11/10(水) 20:10:18.31

>>275
既にWasmだけで完結できるようになっている
JavaScript部分はWasm呼び出す固定コード

>>276
もちろんDOM操作のみだとVanilla (生JavaScript)がWasmより速い
ところがDOM操作以外の処理が多いと逆転してしまいWasmが速い

さらにVanillaではなく仮想DOM系フレームワーク(ReactやVueなど)と比べると実DOM操作以外の処理が多いためWasmが圧勝になっている

**デフォルトの名無しさん** · 2021/11/10(水) 20:14:12.10

>>280
お、マジ？
ソース出してソース

**デフォルトの名無しさん** · 2021/11/10(水) 20:20:33.04

>>281
各フレームワーク比較ベンチマーク
https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html

**デフォルトの名無しさん** · 2021/11/10(水) 20:23:51.07

ベンチ
https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html
を見ると素のJSが一番速い
ついでなんだかよく分からんフレームワークを2つ挟んで、
solidっていう非vDOM系のJSフレームワーク、
ついでやっとwasm-bindgen
wasm-bindgenってのはRustでwasmやる基礎ライブラリだからフレームワークまで行かない（素で使うのはキツイ）
Rustスレでドヤ顔で貼られてたdominatorってフレームワークはそれよりずーっと右（遅い）

DOMのAPIがwasm側に提供されてない現状でUIフレームワークにwasmベースのものを選ぶのはバカのすること

DOMの関わらない演算ヘビーな処理に特出しでwasmモジュールを使う、といったやり方が当面は賢いだろう

**デフォルトの名無しさん** · 2021/11/10(水) 20:36:42.87

>>282
ありがとう。
しかしえらいプリミティブな内容だな。
並んでるフレームワークも機能がバラバラ過ぎてWasmが速いとは一概に言えないよ……。
てか普通にVanillaが最速じゃないか

**デフォルトの名無しさん** · 2021/11/10(水) 21:00:19.65

結局tsなんていらんかったんや

**デフォルトの名無しさん** · 2021/11/10(水) 21:58:30.80

>>282
Reactがあまりにも遅すぎなんだな
しかしそれでもReactがこれだけ使われてるということはDOM操作の速さは気にしなくて良いってことか
つまりWasmでも全く問題ないという結論になってしまうな

**デフォルトの名無しさん** · 2021/11/10(水) 22:17:09.49

>>286
いや、ベンチマークテストの内容見ればわかるけど、Reactでそんな処理しないだろみたいな内容あるよ。苦手な処理がいくつか刺さった感じ。コードの小ささに降ったPreactより結果が悪い事からもそれが読み取れる。
遅いWasmで問題無いという結論の持って行き方もちょっと筋道立ってないように感じる。

**デフォルトの名無しさん** · 2021/11/10(水) 22:18:43.57

どういうDOM操作を行うかあらかじめわかっているならよけいなオーバーヘッドがないvanillaが速いのが道理だけど
このベンチマーク自体はどういう意味があるんかね。

**デフォルトの名無しさん** · 2021/11/10(水) 22:30:50.49

>>287
なるほど
Wasmで問題ないと思ったのはそのReactの件だけでなくて
素のJSであるVanillaとWasmの差がわずか6%しかない点も含めてそう思った
DOM操作のオーバーヘッドがあるからWasmは使えないという意見が嘘だと分かったことが大きい

**デフォルトの名無しさん** · 2021/11/10(水) 23:46:06.12

そうなんだよ
DOMの操作でのWasmの不利は誤差範囲
もちろん歴史の深さの差があるから今すぐではないけれどTypeScriptの天下は長く続かない可能性大

**デフォルトの名無しさん** · 2021/11/10(水) 23:48:34.79

wasm使ったWebアプリが未だに実用的に見たことがないんだが

**デフォルトの名無しさん** · 2021/11/11(木) 00:22:14.37

バニラJSはえぇえ
やっぱ最強のフレームワークやな

**デフォルトの名無しさん** · 2021/11/11(木) 04:16:04.08

バーニラJSって体感でそれくらい変わった？

**デフォルトの名無しさん** · 2021/11/11(木) 07:22:47.47

>>289
あぁそうか、Wasmに速度を求めるわけでなくてオーバーヘッド食ってでもJS|TS以外の言語で使いたいって視点なら、それはそうか。
まぁでも、まだまだこれからだね。
現状では他の言語使うモチベーションがフルスタックフレームワークぐらいしか無さそう。

**デフォルトの名無しさん** · 2021/11/11(木) 07:58:22.18

>>294
SSR/SSGをCSRと同一コードでDOM生成(HTML生成)させる言語も
JavaScript/TypeScriptよりRust等の方が圧倒的に速くてサーバーコストも下がりそうね
もちろん強力な静的型付け言語を使えて今よりさらに開発効率と質も上がるメリットもあるけれど

**デフォルトの名無しさん** · 2021/11/11(木) 08:09:17.44

流石にRustでWeb系を書きたくないなぁ（パフォーマンスが求められる局所なら良いけど）。平衡して考えなきゃいけないレイヤーが増えすぎる。
静的型付け言語のメリットはTSで十分補えてるから俺は要らないかな。

**デフォルトの名無しさん** · 2021/11/11(木) 08:43:10.77

c#でいいじゃん
VS使えばアホみたいに簡単に作れる

**デフォルトの名無しさん** · 2021/11/11(木) 08:56:20.67

C#おじさんであったか

**デフォルトの名無しさん** · 2021/11/11(木) 09:29:06.96

じゃあRust使ってろ

**デフォルトの名無しさん** · 2021/11/11(木) 10:11:28.40

流石にC#で作るとオーバーヘッドが半端ない事になるなぁ

**デフォルトの名無しさん** · 2021/11/11(木) 11:08:54.97

新しいflash作ってるって話？

**デフォルトの名無しさん** · 2021/11/11(木) 12:25:53.19

.NET, Web, Flash...!!

Silverlightは死んだんだ
いくら呼んでも帰っては来ないんだ
もうあの時間は終わって、
君も人生と向き合う時なんだ

**デフォルトの名無しさん** · 2021/11/11(木) 16:10:58.43

Silverlightは死んでもいいけど光るちゃんは残して

**デフォルトの名無しさん** · 2021/11/11(木) 16:41:04.31

海ちゃんと風ちゃんは？

**デフォルトの名無しさん** · 2021/11/12(金) 00:58:17.93

ブラウザ自体が根本的に変化しないとこれ以上は無理やろ
結局はDOM JS CSSが最小単位でフレームワークが力技で現代風な開発環境を整えてくれてるだけだし

**デフォルトの名無しさん** · 2021/11/12(金) 06:33:55.07

ブラウザは頑張ってるよ。あんな複雑なアプリケーションなかなか無い。現代的な開発環境ってのは常に変化するからいちいち対応してたらブラウザのさらなる肥大化を招きそうに思う。
鳴り物入りで導入されたWebComponentsに関しては妙に使いにくくなっちゃったね感はあるけど……。