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/02/20(日) 19:50:17.91

>>771
ipがどうのこうのと議論と関係ないことを書いてる人達が無視してること

**デフォルトの名無しさん** · 2022/02/20(日) 19:51:22.45

npmでreact、vue、nextjs、nuxtjsのダウンロード数を見るとvueやる気にならんが、
気にしない人も多いんかな。

**デフォルトの名無しさん** · 2022/02/20(日) 19:53:50.90

スレと関係ない事延々と語るおじさんに問題があるとしか思えないけど

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

>>773
全く気にしないことはないが指標の１つ程度だね
普通はそうだろう

>>774
俺もちゃんと議論してくれる相手ならそうしたいんだけどね
議論から外れて盤外のレスバ仕掛けてくる人達が湧いてくるんで対処してるだけ
彼らが静かになればこちらも無駄なレスしなくて済むんで助かるんだが…

**デフォルトの名無しさん** · 2022/02/20(日) 20:11:55.25

Blazor最高！って
あちこちのスレ嵐してた奴の事？

**デフォルトの名無しさん** · 2022/02/20(日) 20:14:54.91

そういうとこなんだよな

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

おじさんって仕事なにしてるの？
ニート？

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

仕事で開発してるよ
仕事でもなければ開発なんて絶対にやりたくない

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

Blazor最高は間違いなく無いけど、
金だせる企業ならASP.netMVC最高はあるな

**デフォルトの名無しさん** · 2022/02/20(日) 20:50:52.33

>>773
へ～と思って見てみたら驚いた。今5倍も違うのか。

**デフォルトの名無しさん** · 2022/02/20(日) 23:25:22.43

MSも囲い込めるなら強いからなあ

**デフォルトの名無しさん** · 2022/02/21(月) 03:06:33.67

結局後方互換切るのは悪手なんだな
angularもそれで斜陽になったし
vueは巻き返せるだろうかね

**デフォルトの名無しさん** · 2022/02/21(月) 04:20:34.02

派遣切りにあったのかどうかだけ教えて？

**デフォルトの名無しさん** · 2022/02/21(月) 07:27:47.87

プライベートでは絶対開発したくないと言う人が、わざわざプライベートな時間を割いて嫌いな技術のスレに来る？
やはり目的は議論じゃないよね……

**デフォルトの名無しさん** · 2022/02/21(月) 10:01:33.67

Reactが最強とか言語のシェアでイキってるのはなんなんw
シェアが全くの0じゃないならVueでもAngularでも仕事上捨てきれなくね？
それともReactの開発者とか関係者なん？
Reactないと詰むの？w

**デフォルトの名無しさん** · 2022/02/21(月) 10:14:55.67

なに発狂してんだよ

**デフォルトの名無しさん** · 2022/02/21(月) 10:20:29.28

大事なのはシェアよりも公式による主要ライブラリのカバー率、公式の抱える熱意だと思うな
シェアが多ければある程度は熱意に反映されるかもしれんが人間の感情はそれだけじゃないだろう

**デフォルトの名無しさん** · 2022/02/21(月) 10:34:17.39

reactって言語だったのか
勘違いしてたわ

**デフォルトの名無しさん** · 2022/02/21(月) 10:37:29.68

JSXがあるから実質的にDSLと捉えることもできなくはないのかもしれんね

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

大事なのはプロジェクトにマッチするかどうかだろ

**デフォルトの名無しさん** · 2022/02/21(月) 13:32:45.52

フェイスブック嫌いやねん

**デフォルトの名無しさん** · 2022/02/21(月) 13:38:11.57

メタはオワコンなりそうな気配感じてるけどreactは大丈夫なんかね？

**デフォルトの名無しさん** · 2022/02/21(月) 15:08:21.45

MITライセンスのオープンソースだしそこはあまり問題ないかと
一人の開発者に依存してるVueに比べたら全然

**デフォルトの名無しさん** · 2022/02/21(月) 15:25:27.98

もし仮にmetaが潰れたとしても、みんなReactのイニシアティブは握りたいだろうから開発チームごと何処かが引き取るだろうね。
Oracleみたいな会社が引き取ると悲惨だけど

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

それよりNode.jsの先行きの方が気になるわ

**デフォルトの名無しさん** · 2022/02/21(月) 15:59:52.86

どうせならMicrosoftに引き取ってもらいたい

**デフォルトの名無しさん** · 2022/02/21(月) 17:50:33.95

denoがよほど跳ねない限りはnodeも安泰な気がするなぁ

**デフォルトの名無しさん** · 2022/02/21(月) 18:13:31.27

wasmが発展すればnodejsにこだわる意味はなくなるのでシェアは縮小する
しかし無理して乗り換える必要性もないので選択肢の１つとしては残り続ける

**デフォルトの名無しさん** · 2022/02/21(月) 18:26:40.55

それはユーザー数を指標にして見るとNodeは減らずWasm分が単純に増える感じになりそう。
なおnpmはGitHub傘下だから実質MS

**デフォルトの名無しさん** · 2022/02/21(月) 18:27:58.41

Adobe製品インストールすると、ロカールにnode.jsのサーバ立てまくるからな。
便利なんだろうけどちょっと怖いｗ

**デフォルトの名無しさん** · 2022/02/21(月) 18:52:13.55

Ruby on Rails 6 では、
webpack で変更ファイルをwatch してコンパイルするために、webpack-dev-server を使う

Rails 7 では、脱webpackで、esbuild になるけど

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

webpackが終わるなんて数年前は考えられなかったな
フロントエンドの環境構築はほんと安定しないね
いいツールが生み出されるのはいいことなのだが

webpackのconfigは初心者殺しすぎたし

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

wasmのGC TypesがJVMの再実装になってるのは気になる
ここまで来たらガッツリJSというかTSに寄せて欲しいのだが

**デフォルトの名無しさん** · 2022/02/21(月) 20:08:29.76

JVM言語に寄せすぎるとオラクルの影響力が強くなるから嫌やぁ
偏り無いのが理想だけど偏るならMSの方が全然いい

**デフォルトの名無しさん** · 2022/02/21(月) 20:13:46.87

wasmはdom apiをサッサと実装しる

**デフォルトの名無しさん** · 2022/02/21(月) 20:28:14.84

じみにおじさんのレス入るのが笑える

**デフォルトの名無しさん** · 2022/02/21(月) 20:29:45.95

>>807
どれがおじさんのレスだと思う？

**デフォルトの名無しさん** · 2022/02/21(月) 20:38:48.50

807

**デフォルトの名無しさん** · 2022/02/21(月) 20:43:56.44

こういう疑心暗鬼嫌だからワッチョイあるスレに早く移行したいよ

**デフォルトの名無しさん** · 2022/02/21(月) 21:06:22.94

>>798
denoはkoaと同じ道を辿りそうだよなぁ

**デフォルトの名無しさん** · 2022/02/21(月) 23:39:53.60

denoとkoaを同列に語ってるの意味がわからんのだが

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

本人の意図と合ってるかは分からんけど
「コンセプトは悪くないが流行らなかった」とかそんな感じじゃない？

**デフォルトの名無しさん** · 2022/02/22(火) 07:42:00.35

ヒットしたソフトの作者自身による改良版という意味で。
思いがけずヒットしたソフトのバージョン2が意欲的すぎてこける現象ってなにか名前がついてなかったかな。

**デフォルトの名無しさん** · 2022/02/22(火) 07:55:56.11

axiosの作者が新たに作ったkyと同じか

**デフォルトの名無しさん** · 2022/02/22(火) 08:15:33.27

自分が書いたクソコードを直したいのはわかるけどね

**802** · 2022/02/22(火) 12:15:10.06

>>803
Ruby on Rails 6 では、webpack の薄いラッパー・Webpacker を使うので、
設定ファイルも、webpacker.yml を使う

webpack.config.js を直接使わない

webpacker.yml で、全環境共通の設定をしてから、
development など、各環境の設定で上書きする

Railsがデフォルトの設定や、使うモジュールを選んでいるから、あまり考える事がない

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

>>817
ちょっと気になるんだけどそのラッパーはwebpackをうまく抽象化、隠蔽してるのかね？
この手のツールって中で使ってるツールに関する知識も要求されることが多くて負担が余計に増えるだけなんだよね

**デフォルトの名無しさん** · 2022/02/22(火) 12:40:28.10

Rubyガイジには触れるなｗ

**デフォルトの名無しさん** · 2022/02/22(火) 16:34:58.28

SPAに限らないけどフロントエンドは設定ファイル多すぎなんだよね
自由な反面煩雑すぎる
これっていう開発環境欲しいわ

**デフォルトの名無しさん** · 2022/02/22(火) 16:51:32.51

wasmが完成すれば多少楽になるのでは？
多数の外部ライブラリとローカルプロジェクトで構成されるソリューションを単一のバイナリにアウトプットする
こんなのは他のコンパイルタイプの言語なら当たり前にできる基本的な能力の１つ
基本的な能力ゆえに他の言語ではサードパーティのビルダーに頼らないし設定もほとんど要らない
複雑な環境構築から解放されるだけでもJSを捨てる価値があると思うんでwasm開発チームには頑張ってもらいたい

**デフォルトの名無しさん** · 2022/02/22(火) 17:50:20.32

あ、この独特の用語の使い方と長文は……

**デフォルトの名無しさん** · 2022/02/22(火) 17:57:39.18

議論なら聞くけど
そうでないならレスは不要です

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

>>820
フロントに限らずモダンな開発環境はだいたい設定ファイル多いように思うな。ORMにUIのxml、プロジェクト設定ファイルにlintにエディタ用、充実した色んなライブラリやフレームワークの力を借りてる以上、仕方ないんじゃないかな。

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

formatとかもgolangみたいに、「お前らこれでやれ」ってしてほしい

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

>>820
そういう発想のヤツにはこの業界向いてないからバックエンドとかアプリとか違う分野に言った方がいいんじゃない？

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

付加価値を産まない重労働から解放されたい

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

付加価値造って喜ばれるし、知能労働で工夫しがいはあるし、毎日わりと楽しいです

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

>>823
「不要」じゃなくて「辛いのでやめてください」の間違いでは？

**デフォルトの名無しさん** · 2022/02/24(木) 13:04:05.35

>>820
わかる
重複した設定多いよね
TypeScript使うと更に重複する

**デフォルトの名無しさん** · 2022/02/24(木) 13:31:08.40

TSの案件に参加してお勉強を始めた初日にtsconfigとbabelとwebpackとjestに似たようなPath Aliasをずらずらと書かされた時点で既に俺はTSに見切りをつけて仕事を辞めたくなっていた

**デフォルトの名無しさん** · 2022/02/24(木) 15:02:13.15

いきなり全部やらずに一つ一つ進めればいいのに

**デフォルトの名無しさん** · 2022/02/24(木) 16:00:58.67

>>831
パスはほんと面倒だよね
微妙に書き方違ったりするし
あとlint系
もうちょっとなんとかならんのかな

**デフォルトの名無しさん** · 2022/02/24(木) 16:10:24.66

設定ファイルのセンスのなさは気になるね

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

TSなんてメンドクサイだけやんｗ
javascriptのままでいいよ
わざわざAPIの戻り値とかパラメータをクラスにしてたりするのか？ｗ
過去にC#とかでそういう設計の見て頭痛くなってきたよｗ

**デフォルトの名無しさん** · 2022/02/24(木) 19:57:27.00

typescript使ったことなさそう

**デフォルトの名無しさん** · 2022/02/24(木) 20:25:37.57

class以外に型（データ構造）の表現方法があるからclassの出番は少ないぜ

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

規模が小さいならtypeでもなんでもいいけど
お仕事で扱うようなのだとclassにした方がいいと思うけどね(当然だけどimmutableね)
どんな時でも通じる正解はなくて損益分岐点次第

**デフォルトの名無しさん** · 2022/02/24(木) 20:37:50.55

immutableオブジェクトにclass使う意味無くね？

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

コンストラクタ

**デフォルトの名無しさん** · 2022/02/24(木) 20:45:20.93

>>835
いまだにこういう人がいるってのがフロントエンドっぽい

**デフォルトの名無しさん** · 2022/02/24(木) 20:47:10.11

>>841
まさか全部クラス化してるの？ｗ
ありえねーｗ
そこまでして何か得でもあるの？ｗ

**デフォルトの名無しさん** · 2022/02/24(木) 20:50:44.50

>>840
関数でいいじゃん

**デフォルトの名無しさん** · 2022/02/24(木) 21:31:23.97

JSは人によってスタイルがめちゃくちゃ変わるのが面白い
俺は関数型スタイルが好きだがクラススタイルを否定はしない

**デフォルトの名無しさん** · 2022/02/24(木) 21:52:31.20

tsでgeter、seter使って
世代管理機能付きの値クラスとかね

**デフォルトの名無しさん** · 2022/02/24(木) 22:28:39.88

最近はTailwindCSSかstyled-components+styled-systemでcssを記述するのが好みなんだけど、皆はどうしてる？
facebookもstylexを発表したし、ＭicrosoftもGriffelを公開したしまたcss、css-in-js周りはちょっと流れが変わりそうな気がする

**デフォルトの名無しさん** · 2022/02/24(木) 22:51:46.72

何も考えずに使えて容量も小さくそれなりな見た目になるからTailwindCSSばかり使ってる……

**デフォルトの名無しさん** · 2022/02/24(木) 23:29:43.63

>>846
react(next.js)だとcss modules、素でゴリゴリカスタマイズする用
vue(2ベース、nuxt.js)だとvuetify、さらっと作ってしまいたい用

**デフォルトの名無しさん** · 2022/02/25(金) 10:23:48.08

>>842
TSと何かを勘違いしてない？

**デフォルトの名無しさん** · 2022/02/25(金) 11:06:29.42

TypoSxrypt

**デフォルトの名無しさん** · 2022/02/25(金) 12:31:09.23

Nuxt3っていつリリースされんの？

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

reactのhookはすぐに受け入れられたのにVueのcomposition apiはなかなか受け入れられない謎

**デフォルトの名無しさん** · 2022/02/25(金) 14:20:53.24

後発だからすでにhookのツラミを知ってるというのもあるだろうね

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

Hooksのツラミって？

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

おじさんがGoスレで暴れてるのを見てしまった……

**デフォルトの名無しさん** · 2022/02/26(土) 18:00:19.74

>>852
新規案件が無いってことかと

**デフォルトの名無しさん** · 2022/02/26(土) 18:27:13.35

hook以降にReactに入門したけどhook無しのReact世界なんてイメージできないくらい馴染んでると思う。いや、クラスコンポーネントのソースも見たことあるし、読めはするけども

**デフォルトの名無しさん** · 2022/02/27(日) 14:19:30.81

フック憎んでるのおじさんだけでしょ

**デフォルトの名無しさん** · 2022/02/27(日) 14:40:59.19

ReactをUIを記述するための一種のDSLと考えるならhookはあれでいいと思う
ただ一般的なプログラミングの習慣から考えるとhookは異質すぎる
関数トップレベルでしか使えない、依存関係配列地獄なんかは何故これでリリースしちゃったのか理解に苦しむレベル

**デフォルトの名無しさん** · 2022/02/27(日) 16:10:02.02

クラスコンポーネントはコンストラクタの問題とか
stateを生で触れるとかいろいろ問題があった
それ自体言語機能の問題的な部分も大きいのだがね

それはさておきHooksはコード量の削減と副作用の明示的な排除という目的が達成されるから明らかに良い

問題はJSの言語機能の限界ゆえあの様な形になったのをお忘れなく

**デフォルトの名無しさん** · 2022/02/27(日) 16:26:12.59

いや副作用排除は全然できてない
ここに副作用があります、ってマーカーにはなってるけど

**デフォルトの名無しさん** · 2022/02/27(日) 16:33:35.07

reactは副作用の分離をjsで楽にに実現出来る環境を整えただけでどう分離するかは完全に開発者の領分
自分の知識の足りなさを他者のせいにするのはみっともないからやめた方が良いよ

**デフォルトの名無しさん** · 2022/02/27(日) 17:18:08.29

>>861
それが関数型言語ですがw
副作用が起きる部分を外出しして
値をラップした型としてデザインするというのが関数型言語のアイデア
ラップした型から値を取り出したり設定する時に副作用が起きるがそこは目を瞑る
これがHooksによってできているのはお分かりだろう

**デフォルトの名無しさん** · 2022/02/27(日) 17:59:02.56

HaskellのMonadとかもそういう事なの？

**デフォルトの名無しさん** · 2022/02/27(日) 18:45:51.51

>>862
楽にできてないんだなぁ
>>859で指摘したようにかなり異質だからねhookって
普通にライブラリ作るときにこんな制約持ち込んだらレビューでボコボコにされる

>>863
副作用が起きる場所をラップ(抽象化というが)して外に出すのは関数型でなくプログラミング一般的なプラクティスな
オブジェクト指向でもDIとかあるだろ？
hookがポンコツなのはせっかく抽象化したuseうんたらってのを関数内で直呼びしちゃうこと
このせいで副作用と関数の結合度が高まって扱いにくくなってる
関数のパラメータとして副作用を渡すなりOOPだったらDIするなりもう少しやりようがあった筈なんだがねぇ

**デフォルトの名無しさん** · 2022/02/27(日) 18:54:40.69

おじさんの考えるフックの理想的な実装ってどんなの？
jsで良いから例を出してみて

**デフォルトの名無しさん** · 2022/02/27(日) 18:57:07.53

>>864
基本はそうだよ
あとはラップした値が違う型を連鎖呼び出しできるようにするbindという操作があればモナド

**デフォルトの名無しさん** · 2022/02/27(日) 18:58:57.93

>>867
は～なるほど、勉強になりました！

**デフォルトの名無しさん** · 2022/02/27(日) 19:01:51.31

>>866
hookじゃどうやっても理想にならん
本当に必要なものは副作用をコンポーネントに注入するための自然な経路
それは一般的なプログラミング習慣では関数のパラメータだったりOPPでいうDIだったりする
関数の中で副作用であるhookを直で呼んでる時点でダメダメだ

**デフォルトの名無しさん** · 2022/02/27(日) 19:02:58.48

hooksをawaitできる仕様ができたらいいんだけどな

**デフォルトの名無しさん** · 2022/02/27(日) 19:03:38.95

いやフックじゃ無くて良いからこうすれば良いって言うコードだしてみて

**デフォルトの名無しさん** · 2022/02/27(日) 19:20:22.54

>>871
既に答え出してるが？
関数の引数やOOPでいうDIって