Vue vs React vs Angular vs Svelte Part.10

2022/03/08(火) 22:57:16.85

!extend:on:vvvvv:1000:512

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/
Vue vs React vs Angular vs Svelte Part.9
https://mevius.5ch.net/test/read.cgi/tech/1642316774/

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

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

2022/05/11(水) 15:22:05.78

TSの恩恵がないと判断したなら戻せばよかろう

2022/05/11(水) 15:27:49.44

>>451
例外の型にclassを使ってinstanceof

はい！終了...

2022/05/11(水) 15:32:44.60

オプソライブラリに例外に関するドキュメントが無い時に困る
ソース解析とデバッグで調べてるけれど信用できる仕様書が無いと無断で変更されそうで不安

2022/05/11(水) 15:51:32.19

instanceofだけだとうまくいかないケースもあるそうだ
ttps://github.com/typeorm/typeorm/issues/5057

2022/05/11(水) 16:32:24.65

例外の型なんて精々リトライ可能かどうかの判断とデバッグくらいにしか使わないんだから、そんなに厳密に扱う必要ないんだよ
多くの人に使われるようなオプソライブラリを作るレベルの人はそのへんの匙加減をよく理解していて、
いちいち例外を全部場合分けして個別に作り込みをしてるようなドカタレベルの開発者とはだいぶギャップがある

2022/05/11(水) 17:17:10.10

>>456
俺も昔はそう考えてたけどUXを考えるとそうも言ってられん
プログラミングはエラー処理が大半ってよく言われるけど本当にそのとおりだった
面白くない部分だけど品質を上げるためにやらないと

2022/05/11(水) 18:09:59.23

そもそもTypeScriptもそう長く続かない
こんな所詮トランスパイルするだけのものが永遠に使われる訳が無いし
ネイティブはjavascriptで変わらないのだから

2022/05/11(水) 18:55:47.05

そうだね
ブラウザが静的型付け言語を直接実行できるようになったらあっという間に廃れるね

2022/05/11(水) 19:54:48.33

jsより先にポイ捨てされるならtsってなんだったんだろうな
苦労しながら型書いてたのは保守性のためだったはずなのに

2022/05/11(水) 20:02:51.13

そういうのは廃れてから言ってください

2022/05/11(水) 20:45:51.48

>>457
品質を上げるために例外の型を細かく区別することが必須というわけでもあるまい。
そのアプローチでやろうとしたのがJavaの検査例外なわけだけど、結局それを
きっちりやるのは困難なことがわかってきたんで最近は例外の型に依存する
設計自体が避けられる傾向じにあるんじゃゃないかな。

2022/05/11(水) 21:48:20.99

>>462
問題は実行時型情報の欠落とドキュメント不足で静的検査の有無ではない

2022/05/11(水) 21:50:37.24

>>448
本質的問題はそこだね
だから最近のプログラミング言語であるGoやRustは例外機構try/throw/catchを廃止した

>>449
GoやRustはその方式だね
Goはすべてタプルで返し
Eitherに相当するのがRustだとResult<T, Error>型であとは有無を示すOption<T>型
Rustの「?」オペレータが絶妙でエラー時に即時に関数を抜けてくれて例外のようにエラー処理を上位関数に集められる

2022/05/11(水) 23:04:51.66

>>462
別に例外すべてを細かく切り刻めとは言わないけど
ログイン処理実装などのように、例外を細かく刻まないといけない部分はどうしても出てくる

2022/05/11(水) 23:05:58.48

>>453
おっ、ありー！試してみる

2022/05/11(水) 23:16:11.62

fetchがPromise生成してくれてResponseのメソッドもPromise生成でcatchでサクッと例外処理できるのはほんとに良く出来てると思う

2022/05/11(水) 23:48:55.25

>>466
こんなもんなのよ。
の世の中の問題って！

2022/05/12(木) 00:27:38.23

>>463
何か勘違いしてないかね。
たしかにTSはJSに対して型情報を埋め込んだりするようなオーバーヘッドは生じさせないと言っているが
それは実行時に型を判断できないという意味じゃあない。
nominal subtypingな言語だとコンパイルで型名が失われたら型が判断できなくなるから、あえて
「実行時型情報」として保持させてやる必要があるわけだが。

2022/05/12(木) 00:40:13.66

>>469
いやTSもJSも実行時に型は判断できないよ
オブジェクトが特定の条件をみたしているか判断してるだけ
これは酷く脆いやりかたでだから>455のような事故が起きる
例外に対処するためのcatchブロックで間違えやすい設計になっているのはちと問題だね

2022/05/12(木) 00:59:23.22

そもそもID:Iqge52I10はTSに何を期待して採用しようとしたのか気になる
まったく見当違いの期待をしといてTSはダメだ！役に立たん！と言ってるように見えるが

2022/05/12(木) 01:04:07.53

>>470
>オブジェクトが特定の条件をみたしているか判断してるだけ

それがstructual subtyping的あるいはduck typing的な型なわけだが。
>>455はinstanceofにnominal subtyping的な型の保証を期待したらそうじゃなかったというだけだろ。
実際にはプロトタイプチェーンしか見てないわけだし。

2022/05/12(木) 04:11:26.12

JSに型なんて期待し過ぎ
そもそもが型とは正反対の言語だ
このポンコツ言語をなんとかして実用に耐えるように矯正してるだけにすぎない

2022/05/12(木) 05:33:09.35

本来ならTSスレで話すべき内容なんだろうけど、ワッチョイ無くてあっち機能してないからなぁ

2022/05/12(木) 11:02:25.32

思ったよりマイナー言語なのかね
TSスレは過疎化がひどい

2022/05/12(木) 13:07:33.15

型付けは便利だし手放せないけど変に意識高い系の人が入ってくると面倒なことになりがち

2022/05/12(木) 13:12:26.97

TSは型チェックやトランスパイルの速度がこれからすごい早くなるから
開発環境はさらによくなってオススメされるのでユーザー数は増える

2022/05/12(木) 14:24:04.12

そろそろTSはJSに吸収される

2022/05/12(木) 14:37:11.32

JSがもっとマシな言語になるなら構わない

2022/05/12(木) 14:42:00.63

みんなTS大好きなんだね♪

2022/05/12(木) 19:10:45.42

>>477
これまでが遅すぎたんで期待

2022/05/12(木) 19:44:49.92

TSもJS互換だし仕様がカオスすぎてワイは頭抱えながら格闘してる…
ESLintって必須プラグインになってきたのは良いが、あれダメこれダメが多すぎる

2022/05/12(木) 19:52:01.26

リテラルと...だけは本当に便利なのであらゆる言語が模倣すべき

2022/05/12(木) 20:15:47.12

頭のいい人がなんやかんやと新しい思想いれたりお作法作ったりしてくれてはいるけど
その度実装してるみんなは右往左往して余計な稼働くって世の中発展を妨げるのは実は頭のいい人達の優越感のせいなんじゃねと愚痴りたくなるほどゴロゴロ仕様がかわるのは完璧して

2022/05/12(木) 20:24:29.54

jsの話ですらないけど初見演算子のなんてググればいいかわからない問題ってどうしてる？

2022/05/12(木) 21:12:03.45

「言語名　演算子」で地道にググるか公式ドキュメントの演算子のページを探す

2022/05/12(木) 21:48:50.75

>>482
EslintはAirbnbとか使わないで最小でやるのが良いんじゃ無いかと
そもそもスケールするかどうか分からんプロジェクトをガッチガチに固める理由がない

2022/05/12(木) 21:53:12.74

>>485
TSならこれで調べるのが早い
https://typescriptbook.jp/code-reading-assistant

2022/05/12(木) 22:01:26.54

JScript.NETから進化してる？

2022/05/13(金) 18:48:59.39

TSがどうこうというより、動的型付けの型チェックぐらいもっと手軽にやりたい
googleの賢い人たちに期待してる

2022/05/13(金) 18:56:41.97

型は複雑なものだしTSはMSのレジェンドが生み出した言語だゾ。
マジレスするとSuperstructとか使えば？

2022/05/14(土) 01:09:33.55

>>491
TSには現在進行形でお世話になるよ。これがないとJSはnullが怖い

あとSuperstructを教えてくれてありがとう
調べてみるぜい

2022/05/14(土) 08:36:20.76

勉強中の身なのですがtsを使う理由ってこんな感じでしょうか
理解や用語が誤っていたらご指摘ください。

tsを使う理由（サーバーサイド）
tsは型を厳密に定義することができるのでサーバーサイドでの利用、特にドメイン層でのビジネスロジックの記述に適している。

tsを使う理由（View）
サーバーも同じ言語を使うことで、サーバーで定義したモデル（レスポンスモデル等）をViewでも定義するという二度手間がなくなる。
ただしView側でtsでビジネスロジックを記述すると、利口な UI アンチパターンになってしまうので注意。

2022/05/14(土) 09:12:28.76

>>493
TypeScript検定でも受験すんの？

2022/05/14(土) 09:48:51.54

>>494
社内の技術選定で候補に挙げようかと

2022/05/14(土) 10:07:07.91

鯖でtsはないかな

2022/05/14(土) 12:11:20.40

かと言ってPHPやPythonはアレだし、JavaやC#はアホみたいにメモリ食うし、Node.jsで（fastifyとかで出入り口をガチガチに固めれば）良いじゃんってなることは結構ある。比較的簡単にスケールするし、クラウドでも大体使えるし。

2022/05/14(土) 12:22:01.90

まあサーバがJSTSであるメリットは、
フロントと言語が共通しやすくなることでの総合的な学習コストの抑制がメインやろからね
仕事なら各予算とかパフォーマンスとか、要件に合わせてちゃんと多角的に評価すべきだとおもうよ

2022/05/14(土) 12:39:34.79

共通っていうほど移植性ないでしょTS
逆に混乱するから別言語のほうがいいと思うよ

2022/05/14(土) 12:44:48.12

>>497
https://www.takigawa-memo.com/compare-language-atcoder/
TSはJavaやC#より遅くてメモリ食ってるよ

2022/05/14(土) 12:59:34.72

ちと古いが
ttps://cryptomode.com/c-is-the-most-energy-efficient-and-fastest-programming-language-study-finds/
言語比較ってたまにググると色々出てきて面白いね
エネルギー消費量なんてのも比較されてんだ

2022/05/14(土) 13:00:57.29

移植性は関係ないんじゃね。単に環境や知識が一本で済むというだけ。
論点はほかにもあるだろうけどそのへんは要件に照らして個別に判断する話であって、
そういう前提なしに

>鯖でtsはないかな

なんて断言できるもんでもないだろう。

2022/05/14(土) 13:31:51.95

>>502
動くもの動かないものが意外と違うんで一本で済むと思って始めると辛い
stringに生えてるメソッドですら環境依存
そもそもフロントとバックって書き方もアーキも勘どころも依存先も違うんで言語だけ合わせてもって感じ

2022/05/14(土) 13:37:03.84

>>500
ほんまかと思って数年ぶりにjava書いたけど普通にNodeの倍以上メモリ食ってた。
AtCorderはたくさんVM立てるから（forkとかかな？）なんか設定が違うんじゃないかな。
とはいえ思ったより食わなかったので、バカ食いは訂正します。

2022/05/14(土) 13:41:17.73

バックもフロントもコード補完と型安全性、型情報によるドキュメントの補完を目的としてるな
バックでts使った事ないけどapiのスキーマの定義はopenapi使ってれば他の言語使ってても生成できるので二度手間にはならないよ

2022/05/14(土) 13:48:11.53

あくまで学習コストが低いくらいや、とワイも思う
まあドキュメントとかも少しは節約できるかもくらいかな
社内にJSTSのコミュニティがあるとかなら十分検討に値するんじゃね
会社なんて千差万別なんや

2022/05/14(土) 13:53:46.11

継続的に開発するならなんでもいいけど
リリース後は放置するようなものだと、問題が出たときに久々に見てもなんだっけこれ？にならない楽さはある
フロントからJSが駆逐されたらそれも通じなくなるだろうけど

2022/05/14(土) 14:36:41.86

いまどきの学習コストは言語自体よりライブラリやらフレームワークの占める領域がな・・・
言語を揃えてもコスト削減効果は限定的な気はする

2022/05/14(土) 14:42:40.49

でもバックエンドが.netとかjava系でフロントreactよりnextのほうが学習コストは低いやろ

2022/05/14(土) 15:04:21.52

さあ？
それを比較できる根拠は何ももってないから肯定も否定もできないな

2022/05/14(土) 18:15:30.80

皆さんご意見ありがとうございます。
大体の認識はあってそう…？

ガチガチの業務システムになるので、サーバー側は堅牢な言語にしたいところですが…
>>505を読む限り、言語が別でも二度手間感はないのでしょうか
サーバーサイドに定義したレスポンスモデルを変更したら、自動的にフロントサイドも書き変わるのが理想ですね。

しかし意見が結構別れますね
フロントサイド、もしくはサーバーサイドしかやってない人は言語なんてバラバラでもいい
どっちもやってる人は一緒の方がいいってなるのかな

2022/05/14(土) 18:20:06.66

フロントエンド出身の人は同じ言語でいいじゃんってなりやすいし
バックエンド出身の人は鯖でJSTSとか氏ねよって人多いだろうし

2022/05/14(土) 18:26:21.07

JSはまあ論外としてTSしかできないならTS
そうでないなら別の言語でいいんじゃないの

TSのカジュアルさは場合によりメリットになりうる
がしかしJSから継承した多数の変な罠、変化の速い依存関係、低品質な標準・非標準ライブラリを持ち込むデメリットのほうが大きいと思うね

2022/05/14(土) 18:43:36.84

程度問題だな。
pythonやrubyのバックエンドなんてのも平気で存在しているわけだし。

2022/05/14(土) 18:43:56.92

>>511
そもそもこのスレでサーバサイドについて質問する時点で
回答にある種のバイアスがかかるであろうことは想定しないと

サーバサイドについて公正な意見が欲しいならそれに適したスレに行くことを勧めるよ

2022/05/14(土) 18:50:21.52

言語単体でどれがとはいいにくいかな
今時は何らかのフレームワークにのっけることになるけどフレームワークも複雑化しているから使い慣れたものを選択するケースが多い
でそこにマッチした言語を多用することになる
でこれまた使い慣れた言語以外は使いにくいなあと思うように…

2022/05/14(土) 19:21:28.20

>>501
やはりCとRustが圧倒的に効率的なんだな
ブラウザサイドはJavaScript＋Rust(Wasm)のハイブリッドが最も効率良いし
サーバーサイドはRustがクラウド等コスト最小にできるから
今後はJS(/TS)＋Rustの両者だけで最も効率良く行けるね

2022/05/14(土) 19:35:06.42

とりあえず要求要件まとめるのが最初じゃね
会社の得意言語が決まってるとかじゃなけりゃさ
ガチガチの業務システムのコア部分が何がしかのフレームワークで果たしていいのか、とかもあるやろ

2022/05/14(土) 19:47:16.30

ぶっちゃけ余程マイナー言語じゃなきゃなんでも書けるし、要件や現状にあったものを選ぶだけ。早まった最適化は無駄どころか後々の負債になりかねないからね

2022/05/14(土) 20:19:21.78

サーバーサイドはpython1択だろ
新規ならこれで間違いないよ
現時点でnextだのnuxtだの自前で運用するものではないぞ
どんだけコストかかるか

2022/05/14(土) 20:23:46.80

使ってないけど最近サーバーサイドでGoは流行り始めてるってのは何回か聞いた

2022/05/14(土) 20:44:36.70

フロントはVue.js 3、サーバーサイドはPHP
日本においてはこれが最適解だよ
なんで日本に住んでるのにReactとかいうどこの企業も使ってないライブラリ使いたがるのか理解できん

2022/05/14(土) 20:58:56.26

>>522
Vue2の時は悪くなかったけどVue3の日本語ドキュメント全然充実してないやん

2022/05/14(土) 21:05:18.72

弊社、退職済みの自称イケイケエンジニアがnodejsで業務システム作ったおかげで
負の遺産となってる

2022/05/14(土) 21:08:48.30

>>515
でもこの板って特定の技術のスレはあれど
アーキテクチャをテーマにしたスレがないんですよ
あっても過疎ってるんですよ
ちょうどこのスレでtsの話題があったので投稿した次第です

しかしサーバー、フロントどっちもやってる人はすくなそうですね。
うちは規模が小さいのでどっちもやる羽目になりそうなのですよ。

2022/05/14(土) 21:09:06.59

>>522
メルカリ、LINE、Yahoo、マネーフォワード、SmartHR、DeNAとreact(nextjsも含めて)をプロダクトに使用してる企業は枚挙に暇がないんだが・・・

2022/05/14(土) 21:09:49.81

>>524
nodeサーバーゴミだよね

2022/05/14(土) 21:16:45.10

>>511
両方やってるけどバックとフロントは言語ちがうね
フロントは使う技術そんなに変わらないけどバックエンドはプロジェクト毎に要件かなり違うから幅が広くなっちゃう
最初からnodeでやりましょうって決め打ちはしないかな

2022/05/14(土) 21:17:27.35

websocketをガッツリ使うならsocket.ioのあるtsがサーバーサイドでも一番！とか思ってるんだけどこの認識もしかして古い？
Pythonのswampdragonとかスケールしないって記事を見たことがあって

2022/05/14(土) 21:26:52.64

>>529
swamp dragonというかdjango自体があまり使われてない印象
今はfastspi一色かも

2022/05/14(土) 21:27:15.79

>>527
Node (JavaScript) がゴミだと言い張るあなたは何の言語を使っているの？

2022/05/14(土) 21:52:35.44

>>525
>でもこの板って特定の技術のスレはあれど
>アーキテクチャをテーマにしたスレがないんですよ
じゃあこの板自体がその手の情報収集に適してないということ
技術ブログとか漁ってみればある程度まとまった情報も手に入るかもよ

>しかしサーバー、フロントどっちもやってる人はすくなそうですね。
少ないかどうかはわからんけど、自分が少し前にやったのはVue+SpringBootで
選定と実装はひとりでやったよ

2022/05/14(土) 21:56:55.67

>>529
SignalRとか

2022/05/14(土) 22:42:44.47

>>529
そんなもんJavaにでもC#にでもなんにでもある
あとWebSocketと従来のソケット通信は若干送信内容が違う

2022/05/14(土) 22:49:45.09

>>529
websocketだけならnodeでもいいけど
それ以外の処理はどうすんのよ
データベースやキャッシュなどのWebの根幹をなす処理をさ
nodeの不得意分野

2022/05/15(日) 00:06:24.43

最初に用件をある程度固めて、
それを実現できるフレームワークやライブラリを調べて、
言語は最後にベストなものを選択する
開発にかかるコストの全体の中で、言語の取得なんてかなり小さい

2022/05/15(日) 07:24:17.87

遅いしメモリ食うPythonをバックエンドなんかに選ぶ理由はないわな

2022/05/15(日) 07:45:14.36

>>535
不得意でもないけど

2022/05/15(日) 12:45:04.08

>>511
>>サーバーサイドに定義したレスポンスモデルを変更したら、自動的にフロントサイドも書き変わるのが理想ですね。

かってに変わられたら困るですけど(´ω｀)
堅牢とか言ってる割にはなんか根底が矛盾してんですけど

2022/05/15(日) 15:07:20.10

>>539
開発中の話ね
項目名が変わったり、減ったりしたときに困らない？

2022/05/15(日) 16:21:49.45

i/f変わればいずれにしろその項目に対して適切な処理が必要というか作り込みになるから勝手にはこまるのでは
idlぽいものを双方合意で共有するのが現実的では

2022/05/15(日) 16:44:09.04

OpenAPIの定義で握ってるような開発ってどのくらい普及してんのかな。
うちは単にドキュメントとしてしか使ってないけど、あれデータ定義がjsonschemaだから冗長で大変なんだよな。

2022/05/15(日) 16:52:54.26

古くはWSDLとかSOAPとかあったけど、お手軽シンプルなRESTに滅ぼされたのよな

2022/05/15(日) 17:33:08.47

今でもSORPやCORBAが負の遺産で残ってるとこ多いね
Restに駆逐されて良いわ

2022/05/15(日) 17:51:00.04

Swaggerって実質的にWSDLの再発明みたいなもんでしょう
WSDLを安易に滅ぼさずに最適化し洗練させていけば
技術間の断絶が起きず移行コストを抑えつつ今と同じような形態に落ち着いたのではと思う
まあいまさら何を言っても過去は変わらんのだけど

2022/05/15(日) 18:15:18.89

>>541
自分は勝手に変わって、コンパイルエラーになる方が嬉しいわ
変わってることに気付かないのが怖い

2022/05/15(日) 20:14:06.84

リクエストやレスポンスに載せる要素を勝手に追加して送っても受け取る側がさわらなけりゃエラーにもならずそのまま漏れるケースがでてくるよ
ぼっち開発ならいいけど複数人でやるならコミュはとらんと

2022/05/15(日) 20:40:00.47

>>547
それで困るシーンがいまいちイメージしづらいな。
受け取る側で必要ないデータを勝手に追加しても使われないから別に問題ないんでは？

2022/05/15(日) 21:01:47.68

>>539が何をもって堅牢と矛盾してると言ってるのかようわからん

2022/05/15(日) 21:26:19.11

>>514
Rubyは一時期ゴリ押されてたからまあまあ多いだろうな

2022/05/15(日) 22:05:09.04

>>547
いやそりゃレスポンスモデル変わったことは通知するよ
でも人間がやることだから必ず対応漏れが出る

大幅な変更で対応漏れがあったらもうどうしようもないけど
ちょっとスペルミスがありました程度で対応漏れで値が表示されなくなるのはつらい