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/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に関しては妙に使いにくくなっちゃったね感はあるけど……。

**デフォルトの名無しさん** · 2021/11/12(金) 07:04:38.91

へーーWebComponentsってどの辺りがダメ？

**デフォルトの名無しさん** · 2021/11/12(金) 08:02:45.29

継承やShadowDOMとかでコードが長く複雑になって気軽にコンポーネントを作りにくい。
気軽に作るのに役立ちそうなtemplateタグがHTML importが無くなっちゃった関係で疎結合化し難く使いにくい。
他にも使っててなんかあったけど忘れた。

まぁその代わり強力なカプセル化出来るし、ネイティブだから速いしどこでも使えるとかって利点も強いけどね。

**デフォルトの名無しさん** · 2021/11/12(金) 08:35:54.75

>>308
普通React使ってるだけだから良くわからんけど、
WebComponentsってネイティブとか関係あるの？wasmじゃなくて？

**デフォルトの名無しさん** · 2021/11/12(金) 09:22:51.94

Web Components
https://developer.mozilla.org/ja/docs/Web/Web_Components

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

いずれreactがラッパーになりそう
ある意味なってるのか既に

**デフォルトの名無しさん** · 2021/11/12(金) 21:27:22.77

>>309
DOM APIのラッパー＝jQuery
WebComponentsのラッパー＝React

**デフォルトの名無しさん** · 2021/11/12(金) 21:53:59.00

SPAで開発するとバックエンドはやることないよな

**デフォルトの名無しさん** · 2021/11/12(金) 22:35:56.03

ユーザの権限管理とか、セキュリティとか、スケールするシステム構築とか、キャッシュ管理とか、データ破損に備えたりとか、いっぱいあるんじゃね？

**デフォルトの名無しさん** · 2021/11/12(金) 22:56:05.85

>>314
あるねーー
クライアントにlogic持ち込みたくないわー！

**デフォルトの名無しさん** · 2021/11/13(土) 12:01:16.35

バックエンドこそSPAの根幹でしょ
いわゆるホームページならSPAだけで成り立つけど

**デフォルトの名無しさん** · 2021/11/13(土) 12:14:40.79

>>313
こいつの作ったSPAはセキュリティー保ててんのか？

dev toolsでゴニョゴニョしたら
見えちゃいけないものも見えたりすんじゃね？

**デフォルトの名無しさん** · 2021/11/13(土) 12:36:25.50

まぁFirebaseとか使えばセキュリティとバックアップの類以外はフロント側に持ってこれるけど

**デフォルトの名無しさん** · 2021/11/13(土) 13:02:56.15

Nuxt3はいつですか

**デフォルトの名無しさん** · 2021/11/13(土) 14:21:20.97

SaaS使ったところでバックエンドのロジックをフロントエンドに持ってくる訳ねーだろ
どんな設定だよ

**デフォルトの名無しさん** · 2021/11/13(土) 15:38:37.16

むかしのくらさばみたいなこーどかいてんだろ

**デフォルトの名無しさん** · 2021/11/13(土) 15:53:50.44

>>320
究極的にはフロントエンドで直接DB読み書きリクエストしてロジック全てをフロントで持つケースもある
現実のサービスのほとんどが様々な理由でその体系を取っていないというだけに過ぎない
・企業サービスロジック問題
・セキュリティ問題
・効率問題など