Vue vs React vs Angular vs Svelte Part.11

2022/08/20(土) 13:17:12.21

!extend:on:vvvvv:1000:512

Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
Svelte
https://svelte.dev/
solid.js
https://www.solidjs.com/

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

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

VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

2024/02/09(金) 11:26:08.14

>>115
そりゃ概念的には違うと思うが、実用面で大きく違うとは思わないけどなぁ…
型チェックの話されるなら理解もできるが

そもそもそんなの誰が決めたって話になるとフレームワーク全般そうなるんよ

2024/02/09(金) 15:04:22.44

>>116
全く違う

2024/02/09(金) 20:59:55.41

>>117
具体的に何が違う？

2024/02/09(金) 21:06:46.46

変数バインドできます
イベント処理できます

フレームワーク本体に求めてるのって結局これだけなんだよね
だけどVueはここがずっと迷走してるから辛いんよ

2024/02/17(土) 01:31:43.07

すいませんVue3（options）で確認したいのですが
v-forで複製した要素（コンポーネント）に
個別にDOM操作をかけたいのですが
$refsにindex指定とかで取得できたりしますでしょうか。

コンポーネントにpropsでデータをbindして渡して
コンポーネント側で変更処理させる事は複雑だと思い
親側で子のDOM操作すれば良いと思いました。

2024/02/22(木) 09:24:29.50

一通りやったけど、Angular一択だと思う。
Vueは論外。
Reactは予想不能な動作が多すぎる。
OnLoad時にサーバにアクセスしてデータを受け取るのを待って描画っていう一番ありがちなシチュエーションを簡単に書けないのもReact
だいたいScriptの中にHTMLが入り乱れるJSXとかあり得ない。

完全に分離できてるのがAngular
さすがGoogle様や

2024/02/22(木) 11:43:21.79

コード理屈わかって書けない人には
Reactは無理よ

UIライブラリーとかめちゃくちゃ作りやすい

プロ指向なのがReact
因みに日本人エンジニアにプロの割合はかなり低い

2024/02/22(木) 12:08:24.96

Reactはデータが更新されたら画面も更新するっていうシンプルな設計だから
画面に表示されたときにデータを取得するような設計は本来の使い方とは違うんだよね

2024/02/22(木) 12:25:12.98

正直すまなかった。
そもそもAngularとReactを比べるのは間違いなのね
Angularと比べるならNextjsか。
Reactに相当するものはAngularには無い

2024/02/22(木) 12:42:10.50

Angularとかvue.jsは
上位エンジニアの成果物を使って
下位エンジニアが作業するスタイル

が故に想定しているエンジニアの対象も異なる

2024/02/22(木) 14:00:09.56

フレームワーク使わなくてもjsxは使いたいって言われる時代なのに

2024/02/22(木) 16:27:07.37

jQueryの頃からライブラリで使われてる便利機能をバニラが落とし込む仕組みはやってるしね

prototypeでDOM操作はキツイ

2024/02/22(木) 17:01:06.42

俺はある程度の規模まではVueのoptions APIで良い派
規模がデカくなる場合はNuxtへ
間違っても単体のVueでコンポーネントは使うべきじゃない

2024/02/24(土) 02:20:28.64

このスレでMillion.js知ったんだけどこれ使うだけでReactのパフォーマンスめっちゃ上がるんだな
もうpreactいらないやん

2024/03/02(土) 08:44:21.68

React 19でやっとmemoしなくてよくなるみたいだな
ようやくsvelteに追いついたか

2024/03/02(土) 14:49:05.57

options APIなんぞ捨てろ。次の3.4で非推奨になる可能性大だ。setup書けるようになっとけ。初代composition APIよりずっと書きやすいし
理屈もわかりやすい。あとprovideとinjectとuseRouteとuseRouterだけは覚えとけ

refとreactiveの用途の違いがわからん？そんな奴はrefだけ使っとけばいい

>>130
そのSvelteは5でKITメインになってデフォルトでSSG化するみたいだが。Rune試そうとしたら、まずそこから理解しなくちゃなんないのでかなり焦った

2024/03/02(土) 15:02:30.77

>>128
むしろVueはLaravelのフロントで用いるケースが増えてる気がする。Vite+Vue+Vuetify+Laravel+αあたりが鉄板化してる。Laravelのフォーム制御、cakeよりショボいからうまく相互補完できてる
Reactは逆にNextのためのツールになりつつあるな。NextはViteにデフォルト対応していないのがむず痒いが（Turobopackはロードが遅くてモヤる）

2024/03/02(土) 15:17:16.26

>>121
Angularも17になって脱テンプレートで、かなり書き方変わってますますAngularJS、Vue.jsとの血脈が薄くなったと思った
いよいよ、次の18でクラスコンポーネント解体に向かうんじゃないかと思ってる

2024/03/08(金) 14:16:16.50

規模を考えるような規模の時点でVueを使うこと自体がストレス要素にしかならんわ
コンポーネントって単語が頭を過ぎった時点で選択肢から外したほうが確実

2024/03/09(土) 09:29:45.78

規模を考えるほどのプロジェクトになったらもはやAngular一択では。Reactは少人数で開発するにはいいけど共同開発を考えて設計されてない
あとデザイナーから煙たがられてるし

Vueは自由度が高い反面、高すぎて素人がトンデモ開発して世界中から嫌われてた一時のPHPみたくなってる気もする
縛りが少ないから、設計能力のない人が触ると絶妙なスパゲッティになるのも共通してる

2024/03/09(土) 14:49:57.15

>>132
Next使わないならReact使うメリットが薄くなってきたね
完全にサーバーサイドフレームワークになりつつある
エコシステムも周りに合わせる感じがなくなってきた

2024/03/09(土) 15:02:14.04

>>135
テンプレート廃止マジ？
JSXみたいな感じになる訳？
うーむテンプレートの何が嫌なのか理解できない
サーバーサイドではテンプレートが至高という結論が出て実際それが1番描きやすいのに

2024/03/09(土) 15:35:22.55

ほぼジジイだけどLaravel＋vueとReact＋NextでWebアプリ作ったらフリーランスで生きていけるかな？

サンプルとなるWebシステムのポートフォリオ作って応募に出せば採用してくれそう？

2024/03/09(土) 16:52:48.97

>>135
一択と言われてもな
新規にAngular採用してるの見たことないが

2024/03/09(土) 17:08:21.45

>>135
素人さん？

2024/03/09(土) 18:10:19.70

>>137
JSXというよりSvelteとかLaravelみたいな式埋め込みになってる
ng-templateが煩雑だったからそこをスッキリさせてる。廃止というより脱却というスタンスだからどっちも使えるけどね

2024/03/18(月) 17:12:36.82

実際やってみれば？

2024/04/06(土) 09:57:29.12

今まではお互いライバルだったけど、axios出てきてから完全に本来の本分を果たす独自進化の段階に入ってる
Vue→Laravelとタッグでフロントエンド専
React→Vercelと蜜月で、サーバーサイド専
Angular→単体アプリ専

【以下はチラシの裏】
Vue→フォーム制御がPHPでは限界があった。簡単にフォーム制御できるAngularJS作ったけど、ソースがスパゲッティ
Googleは大規模化したAngular2にしたけど、簡潔さがなくなった→開発者の1人がVueを作った
一時はReact、Angularに対抗して状態管理のVuexとか作ったけど、大規模化には限界がある
ECMA5に対応するためにcompositionAPI、TypeScriptに対応するためにsetup、
更にシェアを増やすためにVite作った。爆速起動ビルドすげえってことで欧米で、Vueも注目を浴び始めた
処理の遅いLaravelがVueに目をつけてタッグを組んだ（標準ライブラリ化）。他のバックエンドもVueと連携できるように
今のVueはLaravelだけでなくRails、DjangoにJAVAなどまで対応した万能フロントエンドツールへ

React→自社で作ってたFacebookの制御用、フォーム制御というより細かなステート管理用に作った。けど、ビルド遅かった
Next.jsが出てきてから遅い問題クリア。デプロイ不要なんでSSG最高や！Herokuとか最初からいらんかったんや！！
GatsbyにAstroも出てきて、サーバーサイド一択、React Nativeも過去の遺物になりつつある

Angular→AngularJSはもうあかん→JSフレームワークだけでフルスタック化→操作が複雑でReactにシェア奪われていく
12のバグで致命的に→13からリベンジ開始（13でフォーム制御改善、14でスタンドアロン化、15でインジェクタ実装、
16でシグナル、17で脱テンプレ）
モジュールの互換性uzee→最初から一通り揃ったAngular、実は悪くないんじゃね、という見直しの動きもちらほら
大規模な専用アプリ開発用に特化

2024/04/06(土) 11:06:16.32

vueとangularはいつからかパフォーマンスめっちゃ速くなってる
仮想DOMはオーバーヘッドなんて言われたりするけど仮想DOMを使ってるsvelteとかと大差無くなってきている
まあシェアナンバーワンのReactがまだ遅いんですけどね
React 19で改善するといいね

2024/04/06(土) 15:59:17.06

>>143
素晴らしいまとめthx

2024/04/06(土) 16:57:58.83

>>143
基地○の妄想？

2024/04/06(土) 18:30:38.08

>>143
文章見直した方が良いぞ
チラシの裏でももう少しまともな日本語を使う

2024/04/06(土) 19:31:09.24

>>143
チラシの裏だから校正するのめんどかっただけ。まとめた結果が上の三行

ReactはNextで動かす分にはパフォーマンス問題ない気もする。特に13になってからすごいわかりやすくなった

2024/04/06(土) 19:34:29.93

それよか中身が...

2024/04/06(土) 21:15:42.28

どのフレームワークもパフォーマンスはテンプレートエンジンのように使えば大差ないんだよな
問題はDOM操作よ
Reactはこれがとんでもなく重い
Million.JS使おうね

2024/04/07(日) 15:44:46.52

このスレで Alpine.js 検討している人いる？
GitHubの星数すごいし
CDNでサクッと使える簡易版Vueみたいな印象。

個人的にはJQueryの後継になるのではと
期待している。

2024/04/07(日) 20:06:56.53

>>151
大規模になった時厳しそうだけどねー

2024/04/07(日) 23:37:46.02

alpineは小さいだけでパフォーマンスは最悪だぞ
こんなんで大規模アプリなんて作るな

2024/04/08(月) 01:04:29.84

ちなみに alpine linux もサイズを小さくしてるだけで、パフォーマンスはDebianなどより良いわけではない。
Debianならスリム版があるので通常ではコンテナはそちらを選ぶほうが良い。

2024/04/08(月) 05:30:39.80

ん？

2024/04/08(月) 15:54:10.06

solid.jsが最強ってことでよろしい？

2024/04/08(月) 17:43:57.35

まず使われているサイトを見たことがないsolid.js
litはそこそこ広まってきてるけれど

2024/04/14(日) 10:12:53.83

海外ではInferno.jsとかPreactとかVanillaとか日本ではあまり名前も見ないまま消えそうなものも多い。Alpineも二の舞になりそう
Laravelに全部駆逐されたPHPフレームワークみたいに、泡沫JSライブラリも山程

Solidも普及率がせめてSvelteぐらい数字出てこないと覚える気になれん
SvelteもSSGデフォルト化しようとしたり、Runeがα版のまま開発止まってたりで迷走してるし
日本だとR社がSvelteに力入れてたけど

2024/04/14(日) 16:02:57.09

>>156
個人的に最強だと思ってるんだけど
なぜか全く流行らない

2024/04/14(日) 22:50:06.55

似たような語法のライブラリは覚えやすいどころか、知識が混濁するリスクがあるから手を付けにくい
Reactで得た知識と紛れやすいから自分はあまり手を出したくない
AstroとGatsbyも同じ理由で手を付けにくいんだよな

2024/04/15(月) 00:11:50.10

スレチかもしれないんだけど良かったら答えてほしい
nodejsでWebAPI作る場合、Webフレームワークはなに使うのがいいと思う？
expressで作るのが一般的みたいだけどnestjsの方が機能も豊富だし応用効かせやすそうなので迷ってる
それともNextjsとかRemixみたいなフレームワークでWebAPIも作ってたりする？
単純なAPI機能だけを想定してる

2024/04/15(月) 00:37:49.38

個人的にはRemixが第1候補でnestjsが第2候補
理由は、今後Webアプリを作る時にRemixを使おうと思っていて、トータルの学習コストが低くなることを期待してWebAPIもRemixで作れると嬉しいということ
nestjsはRemixに比べて早いとかなにかメリットがあるならnestjsもありかと思ってるけど、なにかメリットデメリットあったら教えてほしいです

2024/04/15(月) 00:40:52.36

nestjsはexpressの資産を使えるのがいいのかなと思って候補にあります
Remixがセキュリティをどうやって担保しているのかわかってないので迷っている感じです

2024/04/15(月) 13:48:01.48

nestjsなんてもうほぼメンテされてないだろ
使うのはない
かと言って生expressもない
消去法でnextjsしかない
しかしこのフレームワークはWebAPI用のフレームワークではないから
気軽に使えるものではない
Reactを使う前提のフレームワークだ
WebAPIを簡単に作りたいなら他言語の方が良いのではないかと思う
どうしてもJSが良いのなら止めはしないが

2024/04/15(月) 20:06:28.68

なるほど
JSでやるならNextjsか
Remixはまだ情報少なすぎる感じですか？
NextjsはWeb標準じゃないから気乗りしないんですよね

2024/04/15(月) 20:36:14.22

Remixは流行るかどうかも未知数過ぎる
情報もnextjsに比べたら少ないので変なところハマるとキツイ

2024/04/15(月) 20:36:54.19

Nextjsだとt3スタックとかtRPCとかもできるみたいだけどWeb標準じゃないのだけが本当にネック

2024/04/15(月) 20:42:34.96

確かにそれは大きいですよね
大人しくNextjsやるかな…

2024/04/15(月) 20:44:09.28

nextjsですら致命的なバグがちょこちょこ見つかってるからな
どのフレームワークにしてもリスク込みで使うべし

2024/04/15(月) 20:55:59.55

そうですね
Nextjsにします
ありがとうございました！

2024/04/16(火) 00:40:02.11

remixはもうsvelteと同じくらいには使われてそうだけどな

2024/04/18(木) 17:47:13.83

これからNextjsやろうとするなら13以降と12以前は別ものと心得るべし。でないと混乱するぞ

>>171
RemixよりはまだGatsbyでは？

2024/04/18(木) 23:42:20.94

Gatsbyってもう新規に採用する理由が無い気がするけども
Remixより多いなんてことあるのかな
既存システムも含めるならそりゃGatsbyのほうが多いだろうけど

2024/05/14(火) 21:18:21.28

NextのApp Routerがなんか合わなくてRemixに移行するってのが最近多い

2024/05/17(金) 02:56:17.23

合わないとは

2024/05/18(土) 08:07:42.99

app routerでよく言われてるのはCDN使おうとすると微妙みたいな
勝手にキャッシュして制御できないから

2024/05/26(日) 18:55:43.66

Nextは次のバージョンでキャッシュをデフォルト無効にするみたいだぞ

2024/05/27(月) 13:42:07.90

SolidStartが遂にバージョン1.0になった
これでsolidが伸びてくるかもしれない

2024/06/22(土) 01:00:25.01

angularのシェアがvueに抜かれたらしい
vueが伸びたというよりangularが落ちてるせいだが

2024/06/22(土) 09:36:49.45

Angular はv18になって少しマシになった感じ
だが進化が遅すぎたな

2024/07/11(木) 09:55:22.23

この手の言語は仕様がコロコロ変わって長期開発に向かないんだよなぁ
１～２ヶ月で運用開始して１年以内に終了する様なサービスにしか使えない

2024/07/11(木) 14:38:29.13

next使ってたけどremixの方が圧倒的に使いやすいわ

2024/07/11(木) 15:05:16.30

フロントエンドはReactで良いと思うけどフルスタックでNextjsまで使おうと思うと将来性とかで不安覚える

2024/07/11(木) 15:24:54.75

将来性なんてどれ取っても１０年後には全く別のパラダイムが開かれてんだから気にすんな

2024/07/11(木) 15:26:28.05

五年後…三年後…明日かもなw

2024/07/11(木) 15:27:49.37

今サクッと作って無事動けばそれが正解だろ

2024/07/11(木) 16:06:56.50

バックエンドは枯れた技術のasp.net core　+ C#で鉄板
フロントはReact。フロントエンドにフレームワークは要らない

2024/07/11(木) 18:48:44.65

Vueまじ辛い
コンポーネント跨いだ時にひっそり変更検知死ぬパターンが多すぎる

2024/07/17(水) 09:53:06.27

>>182
たとえばどんなところが?
両方使ってる人の意見を参考にしたい

2024/07/17(水) 14:46:43.65

>>189
Remixはload, display, actionの流れが決まってるからそれに従うだけで良くて考える事が少なくなる
React側でデータ取得にuseEffectとかuseQueryとか使う必要がなくてuseLoaderだけ使えばHTTP処理のことをあまり考えなくて済む

またそれらの処理を画面単位で一つのファイルに記述するから画面単位の開発がかなり楽
これは一長一短あるけどファイルを分けたかったら別ファイルに処理を書いて関数呼び出しだけ画面ファイルに書けば良い

後は起動とかビルドが速いから開発が捗るとか、Vercel縛りみたいな機能とかがないのが良い

とりあえずパッと浮かんだのはこんな感じかな

2024/07/17(水) 15:55:25.56

Remixが流行りだして、猫も杓子もSPAって流れが少し変わってきた気がする

2024/07/17(水) 20:34:22.23

ニコ動の仮はRemixで3日で作ったらしいけどそういうのに向いてるの？とにかく開発スピード重視的な

2024/07/18(木) 00:03:57.48

Remixは単純に覚えることが少ない
ReactでWEB開発したことかある人ならすぐに使えると思う

2024/08/21(水) 09:09:06.23

tsのReact使う時に画像はどこに格納してる？
publicディレクトリ内かsrcディレクトリ内か、好みなんかな？

2024/08/21(水) 22:12:24.59

>>194
個人開発ですんません
静的SVGは全部コンポーネント化して管理してる。なので自動的にsrcフォルダ内。
機能関心で分類してるので、共通素材でなければ普通にその機能フォルダのコンポーネント、パーツの一つとして扱う
それ以外のpngだのjpgだのは、フレームワーク使ってると、そのまま静止画として使う機会はどんどん減るというか自動生成の割合も多いので、publicに入れて動的素材と同列に管理してます

2024/08/22(木) 11:46:41.73

>>195
ありがとうございます、SVGだけsrcは頭になかったなあ

2024/08/24(土) 00:37:06.14

基本的には頻繁に更新しない静的ファイルはpublic、コンポーネントごとに管理したい画像はsrcに置くことが多い

2024/09/05(木) 12:15:35.87

chatGPTがNext.jsからRemixになった

2024/09/05(木) 18:13:19.98

Remix使ったことないんだけど、どうせキャッシュするんだしもう全部SSRの方が簡単だしよくね？っていうことなの？

2024/09/07(土) 12:24:44.47

vueの入門書いくつか読んだけどvue cliの解説ばっかで、vite系のcreate-vueの動作について解説してる本見たことない

2024/09/09(月) 00:16:33.26

そら関係ないからな

2024/09/14(土) 11:17:19.02

まあでも使うのはviteなんだよね

2024/09/14(土) 20:18:06.43

Webフレームワーク未経験でVueが学習コスト低いと聞いたので本買ってきたけどさっぱりわからん
PHPでちょっとしたバックエンドは書いたことあるけれど
フレームワークってトレンドで次から次に変わっていくわけでしょ？
もうフロントエンドもバックエンドも一本のフレームワーク（言語）でできるやつを出してくれよ

2024/09/14(土) 20:18:19.74

Webフレームワーク未経験でVueが学習コスト低いと聞いたので本買ってきたけどさっぱりわからん
PHPでちょっとしたバックエンドは書いたことあるけれど
フレームワークってトレンドで次から次に変わっていくわけでしょ？
もうフロントエンドもバックエンドも一本のフレームワーク（言語）でできるやつを出してくれよ

2024/09/14(土) 20:31:55.73

>>204
Blazorやれば。

2024/09/14(土) 22:56:46.41

未経験だとvueが学習コスト低いってことはない
vueは従来の開発と似ていたから学習コストが低いと言われていただけ
従来のを知らないならべつに

2024/09/15(日) 00:20:21.09

js 一本でやればいいだけ

2024/09/15(日) 14:58:39.57

frontにjsは外せ無いから
backもjsでやるだけだろ

2024/09/17(火) 08:51:08.78

backはgolangでやりたい侍
前回のプロジェクトで採用したけど、あの言語の設計思想は大人数で開発するのにすごく向いてるわ
googleが作っただけはある
アサイン人数が数十人規模になって自己主張強めの問題児が入ってきてもコードが破綻しない

2024/09/17(火) 11:02:44.94

あとはバックエンドの処理時間の問題だけどDBの最適化がちゃんと出来てればPHP8みたいな速いとされる言語でもJS系のバックエンドでも変わんないのかなと思うようになってきた

2024/09/17(火) 12:44:47.46

元からかわんねーーだろ
大半の処理をDBでやってれば

2024/09/17(火) 12:51:30.76

DBのノードは単価が高いんで、処理内容によっては安いバックエンドのノードに寄せたほうが時間が延びても安く上がったりするよ
俺も新人の頃は速さのことしか考えてなかったけども

2024/09/17(火) 14:56:40.30

>>210
PHP8は従来のPHPと比べたら速いってだけでNodeと比べたら遅いぞ

2024/09/17(火) 15:12:06.30

pythonはc並に速くなるように改良中

2024/09/17(火) 16:15:34.56

最初からC並に速い言語使えばいいのでは？🤔

2024/09/17(火) 17:16:40.26

>>214
で、それが実現すんのはいつよ？