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/31(月) 02:44:02.27

何も考えたくないならangularだね
Googleで使われてるし少なくとも数年後に捨てることはまずないし
捨てたとしても移行ツールは用意されるはず

9 · 2022/01/31(月) 05:14:19.99

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

>>9-10
を参照

**デフォルトの名無しさん** · 2022/01/31(月) 05:26:45.90

そのスレお前すら使ってないじゃん
先にお前が移動しろよ

**デフォルトの名無しさん** · 2022/01/31(月) 06:59:29.82

このスレになってから明らかに内容が良くなったし、あっち行く理由がない

**デフォルトの名無しさん** · 2022/01/31(月) 20:04:14.52

>>233
使い回さないページ固有のコンポーネントにContainerやカスタムフックで分離して注入する
あと、propsですべてを渡すのは変更や修正に弱い
影響範囲なんて狭いに越したことはないだろ？

>>237
だから結局は小規模でもRedux(RTK)やRecoil使って上位で疎結合にしたら良い
下位は使い回すこと前提だから純粋な状態を保つようにする

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

上位に副作用を集約して下位に流し込んでくだけ
特に変更に弱かった事例にもあたったことないな
これが変更に弱かったらreact以外の関数型も全部変更に弱いってことになる

**デフォルトの名無しさん** · 2022/02/01(火) 10:33:40.98

https://engineering.linecorp.com/ja/blog/uit-baseline-for-front-end-development-in-2022/
↑
みなさまこれは読まれまして？
jおじが喜びそうな内容になっておりますわよ

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

簡易で軽いサイトほど低機能や低レベルなライブラリ、プラグイン等で事足りてるってことは普通じゃないか

**デフォルトの名無しさん** · 2022/02/01(火) 12:08:16.92

だから僕はPreact！

**デフォルトの名無しさん** · 2022/02/01(火) 13:07:04.03

WebはMVCでいいじゃん
VSCodeのような複雑なブラウザアプリケーションを作るときだけSPAを使えばいい
SPAを使うこと自体が目的になってちゃダメだ

**デフォルトの名無しさん** · 2022/02/01(火) 13:26:35.91

また何もわかってないゴミクソが吠えてるのか

**デフォルトの名無しさん** · 2022/02/01(火) 14:52:45.60

ちょっと複雑なフォーム作ることになった時点でもうReact使った方が楽

**デフォルトの名無しさん** · 2022/02/01(火) 15:49:19.28

すまんが当社ではうちのフレームワークで作ってもらう規則なんだわ
物ができればいいってだけの10画面程度の小規模じゃないんだし好きにやってもらっちゃ困るよ

**デフォルトの名無しさん** · 2022/02/01(火) 16:08:54.24

>>283
ダメェ？

**デフォルトの名無しさん** · 2022/02/01(火) 16:37:39.30

>>283
うちのって言ってるあたり独自で不便で何なら遅いやつなんだろうな……

**デフォルトの名無しさん** · 2022/02/01(火) 16:41:51.56

なんかesbuild使うのがこれからの常識になるのかな
まだプラグイン周りが充実してないから
足りない部分自作しなきゃいけないのが辛い

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

このご時世にjQueryで金になる仕事なんてほとんど無いでしょ

**デフォルトの名無しさん** · 2022/02/01(火) 19:59:39.42

>>282
その時点でUX見直す方が楽

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

う～んこの気配。おじさんの加齢臭を感じる

**デフォルトの名無しさん** · 2022/02/01(火) 20:04:00.94

いつでも見てるぞ

**デフォルトの名無しさん** · 2022/02/01(火) 20:04:17.79

エコシステム変わりすぎ多すぎ問題ははやく解決してほしいんだが
JS系のコミュニティって俺が俺がって感じで協調性ないから永遠に無理なんだろうな

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

かと言って某言語みたく15年位ずっと同じフレームワークが第一線なのもそれはそれでちょっと……

**デフォルトの名無しさん** · 2022/02/01(火) 20:19:05.28

15年使われなくてメンテされてないのと
15年使われて磨かれてるのは全く別なのだがまあいいや

**デフォルトの名無しさん** · 2022/02/01(火) 20:22:04.52

それはそうだな。そういうニュアンスではなかったんだけど、すまんかった。

**デフォルトの名無しさん** · 2022/02/01(火) 21:16:04.68

これ使っときゃテッパンっしょってのも楽っちゃ楽だよね
springとかmojoliciousとかlaravelとか
phpは必ずしもそうではないかもだが

**デフォルトの名無しさん** · 2022/02/01(火) 21:36:15.98

エンジニアリングをエンターテイメントとして捉えてるかどうかの違いかな
陽キャエンジニアにとってはそれを使って自分達がエキサイトできるかどうかが最も大事なこと

**デフォルトの名無しさん** · 2022/02/01(火) 21:55:31.92

モチベーションは開発における無視できない大きな要素って意味なら同意

**デフォルトの名無しさん** · 2022/02/02(水) 00:12:35.92

>>291
それを楽しめないと無理
最近だとまたviteというwebpackを置き換えるものが現れた
しかも作者はevan you
まさかのwebpackがオワコンになる可能性が

**デフォルトの名無しさん** · 2022/02/02(水) 17:20:02.77

日本でReact使ったまともなWebシステムがゼロなんだよなあ
海外はたくさんあるが

**デフォルトの名無しさん** · 2022/02/02(水) 18:25:52.36

大きなシステムになるともう共通部品とかは他で作ったものがあるからそれ使うべきってなるし、
大きなシステムは外からの個人事業主とかの派遣さんにも来てもらうことになるけど
個人とかのいわゆる派遣さんに求められるのは皆と同じものを作ることであるという事実からReactなんか求めないからなぁ

**デフォルトの名無しさん** · 2022/02/02(水) 19:12:52.57

>>299
好きだよね。海外はー、海外はーっていうのｗ

**デフォルトの名無しさん** · 2022/02/02(水) 19:17:46.89

Reactのコンポーネントって並べるだけなら楽なんだけどデザイン変更したり動作をカスタマイズしようとすると途端に難しくなる
オブジェクト指向でプライベート変数にアクセスしたくなったときに似てる

**デフォルトの名無しさん** · 2022/02/02(水) 19:39:44.60

逆じゃね？
並べるのは手間だけどカスタマイズや連携は楽

**デフォルトの名無しさん** · 2022/02/02(水) 19:39:49.84

>>301
比較が海外しかないじゃん
好きとかの問題じゃない

>>300
他ってなんだ
オレオレフレームワーク？

>>302
日本のプログラマーはアホしかいないから難しいらしいよな
俺には難しい理由がわからん

**デフォルトの名無しさん** · 2022/02/02(水) 19:52:19.45

>>304
他っていうのは他の業務でだよ
何百画面もあるようなデカい仕事受けるような会社だけじゃなく
しょっぱいシステム屋とかでもたぶん流用がデフォやで

例えば文字を数値に変えて変えれないなら0を返すToIntegerとか
そういう共通関数群が大量にあるからそれ使ってもらうってのはそれなりの大きさの業務では基本やで

**デフォルトの名無しさん** · 2022/02/02(水) 20:32:36.99

>>305
そんな共通ユーティリティみたいなことは言ってない

フレームワークレベルでコレ使えってなってるのか？
デカい仕事ってバックエンドがゴミ部屋のようにめちゃくちゃな管理してフロントはショボいっていう仕事だよな

**デフォルトの名無しさん** · 2022/02/02(水) 20:56:20.06

おじさん芸風変えたの？

**デフォルトの名無しさん** · 2022/02/02(水) 20:56:23.20

>>304
海外ってどこですかー？
北朝鮮も海外ですが？

具体的なことを知らんから
海外ってひとくくりにする

**デフォルトの名無しさん** · 2022/02/02(水) 20:57:41.24

>>306
例えば得意先コード入力したら得意先名が右のラベルに表示されるようなものとか
ReactやVueで作ってあってもどうせフロントの人らは仕様書みて部品はっつけて終わりやで

**デフォルトの名無しさん** · 2022/02/02(水) 21:05:19.17

>>309
ルックアップコンポーネントみたいな奴だな
で、このスレと何の関係があるんだ？

**デフォルトの名無しさん** · 2022/02/02(水) 21:11:40.10

ん？日本でReact使ったまともなWebシステムがゼロなんだよなあ
からの流れだよ

結局のところ全体のフレームワークとしてバックエンドにまで絡めて既存の資産を捨てるほど大きなプロジェクトでReact使うことでの価値は無いってだけで
小規模のホームページとかそういうのならぜんぜん使ってもいいんじゃないっていう話だよ

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

まぁクソデカSSRシステムに組み込めとか言われたらそうなるかもしれん。でも今後は変わるんじゃね？

**デフォルトの名無しさん** · 2022/02/02(水) 21:36:33.87

いやほんとまともにReactとかで規模の大きめのシステム作れるやつがまったくいない
日本のプログラマーがゴミクソばかりで世界一のIT後進国だからな

**デフォルトの名無しさん** · 2022/02/02(水) 21:45:08.40

webじゃないがSikiっていう専ブラはreactだったはず

**デフォルトの名無しさん** · 2022/02/02(水) 21:53:49.27

ここの連中集めればReact技能者は集まりそうだけど技術選定と設計ですげー揉めそうw

**デフォルトの名無しさん** · 2022/02/02(水) 22:18:45.71

好きなフレームワークで1人1ページ担当してがっちゃんこしよーぜ！

**デフォルトの名無しさん** · 2022/02/02(水) 22:37:51.13

じゃあおれバックエンドをVBScriptでやるわ
おまえらフロントすきにしていいぞ

**デフォルトの名無しさん** · 2022/02/02(水) 22:39:20.46

>>317
ごちゃごちゃと障がい者みたいにつぶやいてないで
一回自分でやれ

**デフォルトの名無しさん** · 2022/02/02(水) 22:58:02.85

じゃぼく「それjQueryで良くない？」って言う係

**デフォルトの名無しさん** · 2022/02/02(水) 23:36:32.04

技術選定だとReact、Nextjsを選んだ以上にCSSどうするかはかなり悩んだな。
結局CSS Modulesが最良と判断したが。

**デフォルトの名無しさん** · 2022/02/03(木) 16:23:18.14

個人的にはUtility Firstなやつが楽かな
クラス名考えるの面倒だし

**デフォルトの名無しさん** · 2022/02/03(木) 17:35:40.81

いやもうnuxtで良くない？

**デフォルトの名無しさん** · 2022/02/03(木) 18:48:10.96

今更vueって

**デフォルトの名無しさん** · 2022/02/03(木) 19:47:20.12

React/Next.js系がデファクトスタンダードだよな

**デフォルトの名無しさん** · 2022/02/03(木) 20:28:23.89

>>324
それってデータあるんですか？

**デフォルトの名無しさん** · 2022/02/03(木) 20:31:10.87

wasmでdomが扱えるようになったらrustで書けるフロントエンドが流行るはず
たぶんrustで書けるreactがそのまま出てくるから結局react覇権になりそうだが
rustはtypescriptの利便性保ちつつより堅牢で高速だから欠点無い

**デフォルトの名無しさん** · 2022/02/03(木) 20:34:08.26

マイナスが0になったら
流行るはずって思ってるやつ多いよな

LinuxでWindowsアプリが動いたら
流行るはずとかさ

**デフォルトの名無しさん** · 2022/02/03(木) 20:43:12.09

rust版reactとjs版reactの機能が同等になったら
新規プロジェクトでみんなrust版を選ぶようになるはずから
そうなったときがjs/tsの将来性が無くなる瞬間かもしれない

reactがrust版を出すんだったらvueとかsvelteもrust版出すはずで
結局今とフロントエンドライブラリの選定は変わらないのかな

**デフォルトの名無しさん** · 2022/02/03(木) 20:48:01.47

rustの方が冗長なんだから、
そんなことにはならないって言ってるんだがｗ

**デフォルトの名無しさん** · 2022/02/03(木) 20:48:33.70

なぜ劣る言語に変えると思うんだろうかね

**デフォルトの名無しさん** · 2022/02/03(木) 21:19:21.75

wasmからjsをバインディングしてdom操作すんの？
馬鹿じゃね？

**デフォルトの名無しさん** · 2022/02/03(木) 21:45:39.19

Rustは素晴らしく洗練された言語だけど、それはそれとしてフロントを書きたいかと言われると、パフォーマンス上の問題が出ない限りそうは思わない。ライフタイムとhookを並行して思考したりしてると著しく生産性落ちそう

**デフォルトの名無しさん** · 2022/02/03(木) 21:57:49.98

>>326
もうあるよ
dioxusのweb版
まんまreact
これはパラダイムシフトは確実な気がする
フロントエンドは面白くなるぞー

**デフォルトの名無しさん** · 2022/02/03(木) 22:05:06.01

>>333
これか
https://dioxuslabs.com/reference/web/

なんだこれは？
rustでフロントエンドしちゃってるよ
ヤバタニエン過ぎる

もしもだがdenoランタイムでこれができるようになったらマジでやべーぞ

**デフォルトの名無しさん** · 2022/02/03(木) 22:11:48.24

>>334
別に（JSの立場は）ヤバくはないと思うけど、確かに面白いなこれ

**デフォルトの名無しさん** · 2022/02/03(木) 22:12:16.95

よく分からんけどフロントをRustで書くメリットってなんかあるの？

**デフォルトの名無しさん** · 2022/02/03(木) 22:17:40.45

>>336
今の所はなさそう
ただ数年後となるとわからない

**デフォルトの名無しさん** · 2022/02/03(木) 22:30:20.41

Rustってjsとかphpとかより低級言語よね
したらもうコード書けませんってエンジニア溢れそうだね

**デフォルトの名無しさん** · 2022/02/03(木) 22:32:58.03

>>335
denoランタイムとの接続がキーポイントになると思う
denoから使えればtsと相互変換が可能になり
さらにdenoのv8 bindingを使って様々なメタプログラミングが可能になる
とんでもないことになるぞ

**デフォルトの名無しさん** · 2022/02/03(木) 22:39:30.35

謎のdeno推し

**デフォルトの名無しさん** · 2022/02/03(木) 22:44:37.55

こんなんただのBlazorのフォロワーじゃん

**デフォルトの名無しさん** · 2022/02/04(金) 00:52:08.94

rustフロントエンドの選定スレがほしいな

**デフォルトの名無しさん** · 2022/02/04(金) 01:31:33.73

なんでウェブでわざわざゲーム作ろうとするの？
作っても別にいいけど、
rustとかでゲーム以外作るわけ無いだろ

**デフォルトの名無しさん** · 2022/02/04(金) 02:51:53.60

wasmには期待してるけど
wasmが完成した時に覇権を握るのがrustかどうかは別の話

**デフォルトの名無しさん** · 2022/02/04(金) 05:29:04.98

ちょっとした部分をrustで書くのはよくても本格的なやつはrustで書きたくないな
rust難しすぎる

**デフォルトの名無しさん** · 2022/02/04(金) 07:09:02.77

>>341
設計としてReactに寄せてるし、C♯ランタイムまで入るBlazorとは明確に違うでしょ。

>>343
ゲーム要素ゼロじゃん。

Reactの3倍位の容量にはなるみたいだし、JSの立場を脅かす事は無いだろうけど、選択肢が増えるのは歓迎かな。
Rustたしかに難しいけど、TSで型パズルするのと難易度的には同じくらいに感じる。

**デフォルトの名無しさん** · 2022/02/04(金) 07:31:25.17

>>345
俺も最初そう思ってたけどオライリーのプログラミングrust第2版読んだらそんなに難しくなかったよ
これまで日本人作者の書いた本読んでいまいち理解できなかったけど
単に説明が下手すぎただけだったよう

**デフォルトの名無しさん** · 2022/02/04(金) 07:40:26.56

rust難しいって言ってる人って単にCSを理解してないだけな気がする
rustの仕様ってゼロコスト抽象化なのだからCSを理解してない状態で使えるわけないんだよね

**デフォルトの名無しさん** · 2022/02/04(金) 08:21:16.73

難しいかどうかと使いたいかどうかはまた別問題じゃないかな

**デフォルトの名無しさん** · 2022/02/04(金) 09:10:35.79

rustはlodashのようなライブラリはあるのかな？

**デフォルトの名無しさん** · 2022/02/04(金) 10:55:16.98

rustは実行時型情報はあるのか？
C++やTypeScriptみたいにコンパイル時と違う形のデータが入ってくるようなら使い物にならんが？

**デフォルトの名無しさん** · 2022/02/04(金) 11:35:10.38

tsでwasmするのが正解

**デフォルトの名無しさん** · 2022/02/04(金) 11:35:16.43

静的かつ強い型付けなので実行時にはないしキャストもない
ていうかwasmはRustではないしRustがブラウザで実行される訳でもないので開発環境はTypeScriptでも他の言語でも全然構わない

**デフォルトの名無しさん** · 2022/02/04(金) 11:36:32.22

TypeScriptで型が化けるのはバリーションできてない時だけ。
Rustで型が化けるのは余程変なコード書いた時だけ。

**デフォルトの名無しさん** · 2022/02/04(金) 12:00:18.20

Rustは未履修だが意図的に破壊しなければ型エラーが出ないと言う話だったら間違いなく今後はRustに置き換えが進むだろうね
Blazorがその地位に来るかと思ったがRustにしてやられたか
いやいやまだわからんか
速度と安全性を重視するときはRust
実行時型情報による高い安全性と開発コスパを重視するときはBlazor
老害懐古厨はJsTsって感じで棲み分けが進むかもしれん

**デフォルトの名無しさん** · 2022/02/04(金) 12:08:13.07

Blazorおじさんまだ生きてたのか……。老害って言われて悔しかったんだね。強く生きてね。

**デフォルトの名無しさん** · 2022/02/04(金) 12:11:44.09

老害？それはJsTs厨のほうだろ
何十年前のポンコツ仕様でいつまで使い続けてるんだって話
JsTsはクソ仕様のオンパレードだから排除できるなら速やかにそうすべき

**デフォルトの名無しさん** · 2022/02/04(金) 12:20:02.95

はいはい、ご苦労さん

**デフォルトの名無しさん** · 2022/02/04(金) 12:44:19.41

Vue.js! Vue.js! Vue.js!

**デフォルトの名無しさん** · 2022/02/04(金) 13:09:29.21

Rust勉強して良かったなと思うことの一つは、Promiseのcatchメソッドの有用性に気づけた事。fetchのResponseのjsonメソッドがPromiseなのもすげえ腑に落ちた。

**デフォルトの名無しさん** · 2022/02/04(金) 14:42:39.19

rustできないと落ちこぼれる時代
フロントエンドも大変なことになってきたな
死ぬ気で勉強しないとな

**デフォルトの名無しさん** · 2022/02/04(金) 14:50:43.17

SNSフォローしてるハイレベルなフロントエンジニアもrustはオプションでなく必須になりつつあるって考えて学習始めてたな
まあそれも結構前の出来事だけど
乗り遅れんようにせんとあかんね
JsTsにしがみついてたらこの先どうなることやら

**デフォルトの名無しさん** · 2022/02/04(金) 14:59:54.77

文章に癖があるからすぐわかるなぁ

**デフォルトの名無しさん** · 2022/02/04(金) 15:05:23.64

コンポーネントは再利用性やテスタビリティにこだわらん方が実務レベルだと上手く行くようだ
純粋関数は理想ではあるがバケツリレーで脳のスタックを食い潰すのでよくないな
ライブラリ化する時が来たらじっくり考えよう

**デフォルトの名無しさん** · 2022/02/04(金) 15:12:51.48

rustやるならvacodeでいいの？

**デフォルトの名無しさん** · 2022/02/04(金) 16:18:07.30

rust使うメリットを薄っすら考えてたけどやはりあった
rust使えばフロントとバックエンドで真のisomorphicができるんだよな
このメリットはあまりにもでかいよ
サーバーサイドのエンジニアからしたらむしろrustがいいし

**デフォルトの名無しさん** · 2022/02/04(金) 17:16:47.18

フロントエンドの重たい処理をRustをWasmにして代替するってのはいいけどReactみたいなのを代替するとは思えない

**デフォルトの名無しさん** · 2022/02/04(金) 17:25:44.41

言語とライブラリは分けて考えたほうがいいのでは？
既存の言語は大きく仕様が変わることがないので言語同士の優位性が逆転することは滅多にない
しかしライブラリは急に現れて優位性を塗り替えていく可能性がある
RustにReact.js以上のライブラリが現れる可能性は十分にあるが(ALT)JavaScriptがRustに勝つ可能性はゼロに近い
将来を見据えればどちらに学習リソースを支払うべきかは自明だと考えるが如何かな

**デフォルトの名無しさん** · 2022/02/04(金) 17:29:47.06

>>367
この人そう言うの分かんないんだよ
wasmがjsを代替するものだと勘違いしてるっぽい
wasmでのdom操作は遅いっての普通に考えたら理解できるはずなんだけど

**デフォルトの名無しさん** · 2022/02/04(金) 17:33:21.11

普通に考えたらDOM操作も今後高速化するとわかりそうなものだが…？
なぜwasmでのDOM操作が将来にわたってずっと遅いままだと確信してるのか逆に聞きたいぐらいだ