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/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って

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

>>869
>>872
同じ事繰り返し言ってるだけでなんも解決できてなくてワロタ

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

>>873
そりゃ最初から一貫して答えを言ってるんだからずっと同じことになるだろ

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

>>868
JavaScriptで唯一信用できる型は何か？というとそれは関数だけ
つまり値を関数でラップすれば副作用は外出しできる
単純明快なこの発想をReactのランタイムに実装したものがHooksとなる
Reactチームの頭の良さには脱帽する

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

次スレではワッチョイ入れて荒らしはNGしましょうね～

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

言葉はいらないからコード書いてみろってw

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

>JavaScriptで唯一信用できる型は何か？というとそれは関数だけ

その場合の信用できるできないの判断基準ってなんなんだろう

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

>>874
コードはよ

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

>>875
細かいことはわからんが柔軟なJSの関数なら型の制限も高階関数の埋め込みもメモ化も思いのままだもんね。

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

>>875
もう少しわかりやすくたのむ

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

>>878
コンストラクタを持っていること
JSではこれ以外で型を識別することはできない

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

信用できる型というとまずtypeofが思いつくが

**デフォルトの名無しさん** · 2022/02/28(月) 00:16:09.83

instanceofの話か。でもそれは『型』の意味する範囲が狭すぎないか

**デフォルトの名無しさん** · 2022/02/28(月) 14:40:19.31

DIライブラリ使えば済む話を延々文句言い続けるおじさんって一体

**デフォルトの名無しさん** · 2022/02/28(月) 14:52:40.67

あ、今急になんとなくわかったかも
俺がreactに求めてるのはvdomとvの接続だけだったのかもしれん
状態をどう管理するかだとか、vdomをどうやって構築するかなんてのは、正直おせっかいでしかない
別にvdomをmvvm(この場合はmvvdommになるのか？呼び方がわからんが)で管理したっていいはずなんだよな
なんなら古のformsスタイルだって行けたはずだ
vdomをどうやってvと接続するか、vdomをどう構築・変更していくか、は本来なら直交してる概念の筈なのに、全部セットでreactというパッケージで提供してしまったところがダメなんだ
この抱き合わせはライブラリ的でなく、お節介なフレームワーク的なやり方と言わざるを得ない

**デフォルトの名無しさん** · 2022/02/28(月) 14:54:05.60

いやmvdomvmか。略し方はどうでもいいが

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

>>886
その発想は悪くないしアイデアがあるなら実装すれば？
評論家みたいに言うだけじゃ何も評価されない
Reactは仮想Domのライブラリの一つでしかない
数年前はオレオレ仮想Domライブラリは結構あった
全部死んだけど
もし君のアイデアが優れたものなら他の人が流用したり
盗んだりするだろう

**デフォルトの名無しさん** · 2022/02/28(月) 15:33:49.09

>>886
そういう用途なら違うの使えばいいだけじゃん

**デフォルトの名無しさん** · 2022/02/28(月) 15:39:42.00

自分で作れとか違うの使えってのはアマチュアプログラマならそれでいいんだけど
仕事でやるとなるとどうしてもシェアが支配的なフレームワークを使わざるを得ない大人の事情も察してくれたら助かる

**デフォルトの名無しさん** · 2022/02/28(月) 15:43:20.33

あんたアマチュアじゃん

**デフォルトの名無しさん** · 2022/02/28(月) 15:45:22.89

>>891
また盤外のレスバを始める気ですか？
そういうのはよそでどうぞ

**デフォルトの名無しさん** · 2022/02/28(月) 16:01:33.23

日本じゃvueのほうが支配的じゃね？

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

ちなみにReactは仮想Dom部分はちゃんとライブラリになってるから
単独で使うこと可能だよ
イベントとかもDomと同じものが実装されてるからReactの仮想Domの上にオレオレフレームワークを作ることは不可能ではないと思う

**デフォルトの名無しさん** · 2022/02/28(月) 16:32:02.24

フレームワークが決まってるならそれに合わせた設計をするだけじゃん

**デフォルトの名無しさん** · 2022/02/28(月) 16:36:26.00

次スレはワッチョイ必須だな

**デフォルトの名無しさん** · 2022/02/28(月) 17:57:07.90

>>894
数年前ちょっと流行ったな
状態管理をreactに依存しないパターン
reactはjsxのレンダリングだけを受け持つ
結局消えてなくなったけど

**デフォルトの名無しさん** · 2022/03/01(火) 13:08:43.56

>>886
わからない状態で書き込んでる癖にイキるな
次からは投稿文をママに見てもらってからにしな

**デフォルトの名無しさん** · 2022/03/01(火) 14:49:26.12

煽りだけしたいのか

**デフォルトの名無しさん** · 2022/03/01(火) 14:55:59.81

成りすましを疑うレベル

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

Reactのテストにはみんな何使ってる？
やっぱJest？

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

>>901
俺はjest
だけど使ってるっていえるほどテストしてないやｗ

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

テストなんかめんどくせえし手動でいっかいきりにきまってんだろ

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

>>902
なるほど、ありがとう。Jestで使ってるjsdomはスクレイピングで使ったことあったけど、ブラウザ動作のエミュレーションもこんなに出来るんだって感心したわ。

>>903
いやいや、アップデート毎に手動で検証するの面倒くさいやん。手動検証するよりテスト書いてる方が楽しいし。

**デフォルトの名無しさん** · 2022/03/03(木) 09:07:59.53

>>901
storybookのplay関数を使って目視で確認しながらやるのもいいよ
jestでそのstoryを丸ごと流用できるからテストの工数も増えないし、何より目でしっかり確認しながらテストできるのがかなりでかい

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

storybookって糞重くね？

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

TSだとクソ重いけど高速化出来るよ

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

>>905
ありがとう。
なるほど良さそうだ。目に見えるのはありがたいね。

**デフォルトの名無しさん** · 2022/03/03(木) 13:38:59.66

>>907
どうやるの？
公式に書いてある情報？

**デフォルトの名無しさん** · 2022/03/03(木) 15:09:58.45

公式ではないけどTSのReact Docgenがクソ重いのでそれをやめる
なのでstorybookのmain.jsにreact-docgenを使うようにする。

module.exports = {
typescript: { reactDocgen: 'react-docgen' }
}

あとstorybookは全部ビルドしようとするので必要なものだけビルドするようにするとか

const stories = () => {
return process.argv[4] === '-stories'
? [`../${process.argv[5]}`]
: [
'../src/components/**/*.stories.tsx'
];
};

module.exports = {
typescript: {reactDocgen: 'react-docgen'},
stories: () => stories(),
}

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

>>910
storybookはあんま深入りしてないので
指摘は直ぐには解らんけど、
後で見てみます！

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

>>907
糞重いのはtsだけなの？

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

jsでも沢山ストーリーがあったり重いプラグイン使ってたりすると遅いかと
その場合は二つ目に書いた必要なコンポーネントだけビルドするようにしたら良い
自分の環境だと20秒ぐらいかかってたのが2秒ぐらいになった

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

コンポーネントからレンダリングに関係ないロジックを分離しろ、という習慣は間違いだったことに気付いた。
コンポーネントに関わるもの全てを密結合し神クラス(関数だが)にしたほうが、ずっと楽で再利用しやすかった。
どうせフロントの寿命は短い。カジュアルでよかったんだ。

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

Vue2のSFP完成系ということでよろしいか？

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

コンポーネントによるでしょそんなの

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

Vue3派閥と戦ってる
なんか普通に負けそう

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

ほとんどの場合Vueのほうが書きやすいと思うんだよなあ
depsとかバグの温床だし、jsxも使えるし画面単位のコンポーネントはjsxよりもtemplateの方がメンテしやすい

割と変化激しいからVueの時代来る気がしている
俺の予想はよく外れる

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

BueはNativeで動かんし

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

>>918
Vue2と3の断絶が悔やまれるね
Vue3.2なら悪くないどころかむしろ覇権取ってもおかしくないと思った

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

veuはデルミネータ書き換えできるけどv-～や@～も別の識別子にかえられると嬉しいのだけど
他のフレーワークに組み込むときちょっと面倒

**デフォルトの名無しさん** · 2022/03/04(金) 10:17:45.71

よわよわエンジニア=Vueって認識ができちゃったのが痛い
まぁ実際そうなんだけども

**デフォルトの名無しさん** · 2022/03/04(金) 10:37:42.90

よわよわでもできるということは優れたフレームワークということ