Vue vs React vs Angular vs Svelte Part.10

■ このスレッドは過去ログ倉庫に格納されています
2022/03/08(火) 22:57:16.85ID:D77bZcWT0
!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/14(土) 13:31:51.95ID:UUXyqx7tM
>>502
動くもの動かないものが意外と違うんで一本で済むと思って始めると辛い
stringに生えてるメソッドですら環境依存
そもそもフロントとバックって書き方もアーキも勘どころも依存先も違うんで言語だけ合わせてもって感じ
2022/05/14(土) 13:37:03.84ID:lXb0w+3k0
>>500
ほんまかと思って数年ぶりにjava書いたけど普通にNodeの倍以上メモリ食ってた。
AtCorderはたくさんVM立てるから（forkとかかな？）なんか設定が違うんじゃないかな。
とはいえ思ったより食わなかったので、バカ食いは訂正します。
2022/05/14(土) 13:41:17.73ID:DuvSDtMha
バックもフロントもコード補完と型安全性、型情報によるドキュメントの補完を目的としてるな
バックでts使った事ないけどapiのスキーマの定義はopenapi使ってれば他の言語使ってても生成できるので二度手間にはならないよ
2022/05/14(土) 13:48:11.53ID:GNnPWoYV0
あくまで学習コストが低いくらいや、とワイも思う
まあドキュメントとかも少しは節約できるかもくらいかな
社内にJSTSのコミュニティがあるとかなら十分検討に値するんじゃね
会社なんて千差万別なんや
2022/05/14(土) 13:53:46.11ID:bL0HlggA0
継続的に開発するならなんでもいいけど
リリース後は放置するようなものだと、問題が出たときに久々に見てもなんだっけこれ？にならない楽さはある
フロントからJSが駆逐されたらそれも通じなくなるだろうけど
2022/05/14(土) 14:36:41.86ID:LJgHQn+CM
いまどきの学習コストは言語自体よりライブラリやらフレームワークの占める領域がな・・・
言語を揃えてもコスト削減効果は限定的な気はする
2022/05/14(土) 14:42:40.49ID:wZ/dlG450
でもバックエンドが.netとかjava系でフロントreactよりnextのほうが学習コストは低いやろ
2022/05/14(土) 15:04:21.52ID:LJgHQn+CM
さあ？
それを比較できる根拠は何ももってないから肯定も否定もできないな
2022/05/14(土) 18:15:30.80ID:4GKPU3lGa
皆さんご意見ありがとうございます。
大体の認識はあってそう…？

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

しかし意見が結構別れますね
フロントサイド、もしくはサーバーサイドしかやってない人は言語なんてバラバラでもいい
どっちもやってる人は一緒の方がいいってなるのかな
2022/05/14(土) 18:20:06.66ID:0bRjAEIy0
フロントエンド出身の人は同じ言語でいいじゃんってなりやすいし
バックエンド出身の人は鯖でJSTSとか氏ねよって人多いだろうし
2022/05/14(土) 18:26:21.07ID:UUXyqx7tM
JSはまあ論外としてTSしかできないならTS
そうでないなら別の言語でいいんじゃないの

TSのカジュアルさは場合によりメリットになりうる
がしかしJSから継承した多数の変な罠、変化の速い依存関係、低品質な標準・非標準ライブラリを持ち込むデメリットのほうが大きいと思うね
2022/05/14(土) 18:43:36.84ID:YyWH0a110
程度問題だな。
pythonやrubyのバックエンドなんてのも平気で存在しているわけだし。
2022/05/14(土) 18:43:56.92ID:wtoFZqAo0
>>511
そもそもこのスレでサーバサイドについて質問する時点で
回答にある種のバイアスがかかるであろうことは想定しないと

サーバサイドについて公正な意見が欲しいならそれに適したスレに行くことを勧めるよ
2022/05/14(土) 18:50:21.52ID:PIqdDhGKd
言語単体でどれがとはいいにくいかな
今時は何らかのフレームワークにのっけることになるけどフレームワークも複雑化しているから使い慣れたものを選択するケースが多い
でそこにマッチした言語を多用することになる
でこれまた使い慣れた言語以外は使いにくいなあと思うように…
2022/05/14(土) 19:21:28.20ID:59Ewxs6ZM
>>501
やはりCとRustが圧倒的に効率的なんだな
ブラウザサイドはJavaScript＋Rust(Wasm)のハイブリッドが最も効率良いし
サーバーサイドはRustがクラウド等コスト最小にできるから
今後はJS(/TS)＋Rustの両者だけで最も効率良く行けるね
2022/05/14(土) 19:35:06.42ID:wZ/dlG450
とりあえず要求要件まとめるのが最初じゃね
会社の得意言語が決まってるとかじゃなけりゃさ
ガチガチの業務システムのコア部分が何がしかのフレームワークで果たしていいのか、とかもあるやろ
2022/05/14(土) 19:47:16.30ID:lXb0w+3k0
ぶっちゃけ余程マイナー言語じゃなきゃなんでも書けるし、要件や現状にあったものを選ぶだけ。早まった最適化は無駄どころか後々の負債になりかねないからね
2022/05/14(土) 20:19:21.78ID:rJz/kRn+0
サーバーサイドはpython1択だろ
新規ならこれで間違いないよ
現時点でnextだのnuxtだの自前で運用するものではないぞ
どんだけコストかかるか
2022/05/14(土) 20:23:46.80ID:vireAt4B0
使ってないけど最近サーバーサイドでGoは流行り始めてるってのは何回か聞いた
522デフォルトの名無しさん (ﾜｯﾁｮｲ 87b9-az5c)
垢版 |
2022/05/14(土) 20:44:36.70ID:zxDXnmN60
フロントはVue.js 3、サーバーサイドはPHP
日本においてはこれが最適解だよ
なんで日本に住んでるのにReactとかいうどこの企業も使ってないライブラリ使いたがるのか理解できん
2022/05/14(土) 20:58:56.26ID:vireAt4B0
>>522
Vue2の時は悪くなかったけどVue3の日本語ドキュメント全然充実してないやん
2022/05/14(土) 21:05:18.72ID:TQJ9y2tp0
弊社、退職済みの自称イケイケエンジニアがnodejsで業務システム作ったおかげで
負の遺産となってる
2022/05/14(土) 21:08:48.30ID:4GKPU3lGa
>>515
でもこの板って特定の技術のスレはあれど
アーキテクチャをテーマにしたスレがないんですよ
あっても過疎ってるんですよ
ちょうどこのスレでtsの話題があったので投稿した次第です

しかしサーバー、フロントどっちもやってる人はすくなそうですね。
うちは規模が小さいのでどっちもやる羽目になりそうなのですよ。
2022/05/14(土) 21:09:06.59ID:q0VbptyB0
>>522
メルカリ、LINE、Yahoo、マネーフォワード、SmartHR、DeNAとreact(nextjsも含めて)をプロダクトに使用してる企業は枚挙に暇がないんだが・・・
2022/05/14(土) 21:09:49.81ID:DuvSDtMha
>>524
nodeサーバーゴミだよね
2022/05/14(土) 21:16:45.10ID:DuvSDtMha
>>511
両方やってるけどバックとフロントは言語ちがうね
フロントは使う技術そんなに変わらないけどバックエンドはプロジェクト毎に要件かなり違うから幅が広くなっちゃう
最初からnodeでやりましょうって決め打ちはしないかな
2022/05/14(土) 21:17:27.35ID:ng6xGQr50
websocketをガッツリ使うならsocket.ioのあるtsがサーバーサイドでも一番！とか思ってるんだけどこの認識もしかして古い？
Pythonのswampdragonとかスケールしないって記事を見たことがあって
2022/05/14(土) 21:26:52.64ID:DuvSDtMha
>>529
swamp dragonというかdjango自体があまり使われてない印象
今はfastspi一色かも
2022/05/14(土) 21:27:15.79ID:59Ewxs6ZM
>>527
Node (JavaScript) がゴミだと言い張るあなたは何の言語を使っているの？
2022/05/14(土) 21:52:35.44ID:wtoFZqAo0
>>525
>でもこの板って特定の技術のスレはあれど
>アーキテクチャをテーマにしたスレがないんですよ
じゃあこの板自体がその手の情報収集に適してないということ
技術ブログとか漁ってみればある程度まとまった情報も手に入るかもよ

>しかしサーバー、フロントどっちもやってる人はすくなそうですね。
少ないかどうかはわからんけど、自分が少し前にやったのはVue+SpringBootで
選定と実装はひとりでやったよ
2022/05/14(土) 21:56:55.67ID:UUXyqx7tM
>>529
SignalRとか
2022/05/14(土) 22:42:44.47ID:h9YALwRY0
>>529
そんなもんJavaにでもC#にでもなんにでもある
あとWebSocketと従来のソケット通信は若干送信内容が違う
2022/05/14(土) 22:49:45.09ID:rJz/kRn+0
>>529
websocketだけならnodeでもいいけど
それ以外の処理はどうすんのよ
データベースやキャッシュなどのWebの根幹をなす処理をさ
nodeの不得意分野
2022/05/15(日) 00:06:24.43ID:PKOM7k+T0
最初に用件をある程度固めて、
それを実現できるフレームワークやライブラリを調べて、
言語は最後にベストなものを選択する
開発にかかるコストの全体の中で、言語の取得なんてかなり小さい
2022/05/15(日) 07:24:17.87ID:/QC8ypewr
遅いしメモリ食うPythonをバックエンドなんかに選ぶ理由はないわな
2022/05/15(日) 07:45:14.36ID:g61xzk710
>>535
不得意でもないけど
2022/05/15(日) 12:45:04.08ID:jYft1JFw0
>>511
>>サーバーサイドに定義したレスポンスモデルを変更したら、自動的にフロントサイドも書き変わるのが理想ですね。

かってに変わられたら困るですけど(´ω｀)
堅牢とか言ってる割にはなんか根底が矛盾してんですけど
2022/05/15(日) 15:07:20.10ID:Pwx8c3iM0
>>539
開発中の話ね
項目名が変わったり、減ったりしたときに困らない？
2022/05/15(日) 16:21:49.45ID:vHVXFnMOd
i/f変わればいずれにしろその項目に対して適切な処理が必要というか作り込みになるから勝手にはこまるのでは
idlぽいものを双方合意で共有するのが現実的では
2022/05/15(日) 16:44:09.04ID:VMVrIVgn0
OpenAPIの定義で握ってるような開発ってどのくらい普及してんのかな。
うちは単にドキュメントとしてしか使ってないけど、あれデータ定義がjsonschemaだから冗長で大変なんだよな。
2022/05/15(日) 16:52:54.26ID:vNRch2400
古くはWSDLとかSOAPとかあったけど、お手軽シンプルなRESTに滅ぼされたのよな
544デフォルトの名無しさん (ﾜｯﾁｮｲ 4563-HE43)
垢版 |
2022/05/15(日) 17:33:08.47ID:k55J8NDG0
今でもSORPやCORBAが負の遺産で残ってるとこ多いね
Restに駆逐されて良いわ
2022/05/15(日) 17:51:00.04ID:ezWJ6neIM
Swaggerって実質的にWSDLの再発明みたいなもんでしょう
WSDLを安易に滅ぼさずに最適化し洗練させていけば
技術間の断絶が起きず移行コストを抑えつつ今と同じような形態に落ち着いたのではと思う
まあいまさら何を言っても過去は変わらんのだけど
2022/05/15(日) 18:15:18.89ID:Pwx8c3iM0
>>541
自分は勝手に変わって、コンパイルエラーになる方が嬉しいわ
変わってることに気付かないのが怖い
2022/05/15(日) 20:14:06.84ID:jKD1Yf03d
リクエストやレスポンスに載せる要素を勝手に追加して送っても受け取る側がさわらなけりゃエラーにもならずそのまま漏れるケースがでてくるよ
ぼっち開発ならいいけど複数人でやるならコミュはとらんと
2022/05/15(日) 20:40:00.47ID:VMVrIVgn0
>>547
それで困るシーンがいまいちイメージしづらいな。
受け取る側で必要ないデータを勝手に追加しても使われないから別に問題ないんでは？
2022/05/15(日) 21:01:47.68ID:yFmPLlmrM
>>539が何をもって堅牢と矛盾してると言ってるのかようわからん
2022/05/15(日) 21:26:19.11ID:3/ngjaD/a
>>514
Rubyは一時期ゴリ押されてたからまあまあ多いだろうな
2022/05/15(日) 22:05:09.04ID:Pwx8c3iM0
>>547
いやそりゃレスポンスモデル変わったことは通知するよ
でも人間がやることだから必ず対応漏れが出る

大幅な変更で対応漏れがあったらもうどうしようもないけど
ちょっとスペルミスがありました程度で対応漏れで値が表示されなくなるのはつらい
2022/05/15(日) 23:14:33.75ID:ezWJ6neIM
型安全な言語だと当たり前の感覚だけどスクリプトをやってる人にはピンとこないのかも
2022/05/15(日) 23:49:50.15ID:Pwx8c3iM0
>>552
言語というか
フロントのみしかやらない人は、IFの変更があったときはバックエンドから通知が来るのが当然で、
通知が来なくて不具合が出たとしてもそれは通知しない方に責任があるというような考え方ではなかろうか

システムの形態によってはスマホアプリもあるだろうし、その場合はフロントとバックの言語が違うなんてのは当たり前なんだろうけど、
ブラウザのみの場合は極力フロントとバックの言語を合わせた方がメリットが多いと思う
2022/05/16(月) 00:40:22.43ID:cASOeT3aM
メリットがあるのは理解するけどバックエンドの選定って運用とかにも大きく絡むから
開発の都合だけを押し通すわけにもいかなくない？
要件的制約的にどれを選んでも大差ないってときにじゃあ同じ言語にしとくかってのは否定しないけども
2022/05/16(月) 00:51:53.77ID:NcmrqgSm0
というかバックエンドは負荷が集中する箇所だから
小さい規模ならまだしも本来ならば
バックもjavascriptで書くなんてあほなマネは極力避けるべきだろ
2022/05/16(月) 01:59:51.50ID:UTxfnI1i0
だからフレームワークも運用も枯れまくってるRuby Python PHP Javaのどれかがベスト
2022/05/16(月) 06:03:18.76ID:IGDmE8Ky0
バックエンド側を勉強する機会がない
クラウドファンクションの実装で済ませる機会が多くて…
2022/05/16(月) 06:24:16.60ID:XfoCH0Ek0
>>555
一般的なRESTサーバーで負荷の集中が予測される場合、クラウドでも自前サーバでも一番気にしなくてはならないのはDBがスケールするか否かじゃね？
2022/05/16(月) 09:44:15.27ID:a802uHDS0
言語合ってくれるとバックエンドはフロントのこと分かりやすいだろうな、とは思うけど
合わせてくれとまでは思わない
それよりも優先すべきことが多い
てかまあスレタイとはズレていくな
2022/05/16(月) 10:17:06.28ID:03MF3TRNd
それは逆だな
一般にバックエンドのほうが技術的に幅広く理解している人が多いから、言語が違ってようがバックエンド担当がフロントを読めないってことはまず無い
当たり前のことだし煽るつもりもないが、フロントの人の方がJSに拘る傾向は遥かに強い
2022/05/16(月) 10:37:26.36ID:XfoCH0Ek0
バックエンドでも一つの言語や一つのフレームワークしかわかりませんみたいな人いるけどなぁ。本人次第過ぎる
2022/05/16(月) 11:19:17.17ID:2hxrh63x0
>>560
？
2022/05/16(月) 11:47:58.40ID:a802uHDS0
なんかズレてんな

まあどこの会社のバックエンドが優れてる優れてないってのは様々やしな
今のフロントを理解できるバックエンドってのもなかなか貴重な気はしてる
2022/05/16(月) 12:16:20.57ID:zuDvQ8ve0
だよな。実際、人材探してもフロント(SPA)できる人のほうが希少だったわ。
2022/05/16(月) 12:48:31.69ID:zUcFmi9Cr
SPAやフロントなんてシステム全体からみたらデザイナーの仕事だからどうでもいいんだよ
2022/05/16(月) 12:48:38.41ID:wSD9JNVwd
フロントもバックもそれぞれ人材はいるけどspaするなら結局前後でデータ整合や認証関連、フロー制御の連携するために間に立って全体をみる役割の人材が少ない印象
2022/05/16(月) 13:00:15.74ID:IoIRdAU7M
>>566
結局フルスタック出来るか、それとも一部しか出来ないか、だよね
言語をどれにするかは独立した別の問題
システム的に許容範囲ならば全てをJavaScriptでも問題ない
逆にサーバーリソースコストが重要ならばスクリプト言語を使っていてはダメだし、
ブラウザ側も重い処理が入るならばJavaScriptだけではダメでWasm必須など
2022/05/16(月) 13:13:26.71ID:j5xHL+8m0
ここサーバーサイドjsは劣ってるって決めつけてる人いない？
表現力もライブラリも実用レベルだと思うが
2022/05/16(月) 13:22:53.05ID:IoIRdAU7M
速さの性能面に限っても、
V8のおかげでスクリプト言語の中でもJavaScriptは断トツに速いから、
他のスクリプト言語を使っていても大丈夫なサーバーサイドならばJavaScriptでも大丈夫
2022/05/16(月) 14:19:04.42ID:DJgy/fWm0
漏れは、NRI ネットコムのAWS Solution Architect Associate(SAA)の教科書で勉強しているけど、
データベースの基本は、マルチAZ

マスター・スタンバイ + read replica(参照のみ)。
Ruby on Rails 6 から、複数DB(read replica)にも対応している

YouTube で有名な、雑食系エンジニア・KENTA の初心者向けRailsサロンでは、
キャリアパスは、Ruby → Go だけ

PHP, Scala は、KENTAがオワコン認定したから、
Laravel を使っているZOZO も、もうダメ。
日本ではKENTAがダメと言うと、誰もその会社へ転職しなくなる。それで滅ぶ

Python, Django も、無理だと言ってる。
大学院数学科とか、AWS 機械学習 Specialty を持っていないと無理。
この分野はプログラミングに関係ない

文系がプログラミング技術だけで食っていけるのが、Rails, Goと、AWS SAA

KENTAだったか誰かは忘れたけど、
フルスタックエンジニアを名乗る香具師は、信用するなと言ってたけど、
KENTAは転職用に、Rails + Vue.js を推奨しているw
2022/05/16(月) 14:28:18.18ID:a802uHDS0
実に香ばしい
2022/05/16(月) 14:30:48.17ID:DQrIwGMYM
こういう書き込みをしてKENTAとかいうやつの評判を下げてる人です
2022/05/16(月) 14:46:23.75ID:qZK8tQUSa
バックエンドではTypeScriptは意図的に避けてる
エコシステムの変化が激しすぎるのと標準ライブラリの貧弱さが使用に耐えない
OSS文化は悪くないけど基本的な機能すらコミュニティ依存っていう無責任な方針はよくない
今後数年から数十年に渡って自分達のプロダクトと共存していくことになるパートナーとして信用できない
2022/05/16(月) 14:49:42.10ID:qZK8tQUSa
逆に言うとフロントと同じぐらい小さくて寿命が短い使い捨てのバックエンドなら別にTypeScriptでも良いと思う
うちはそういうの扱ってないんで選択肢に挙がらないけど
2022/05/16(月) 15:13:42.42ID:UTxfnI1i0
何するにも非同期とかnodeというかJSは終わってる
それはフロントエンドの発想
サーバーサイドは全部同期的に動くのがベスト
同期で動いていかに早くレスポンスを返すかを設計するもの
何やるにもコールバックかPromise連打しなきゃいけなくて地獄
サーバーサイドで非同期は余計なのよ
この感覚を理解できない人はサーバーサイドを理解してない
2022/05/16(月) 15:29:38.98ID:DJgy/fWm0
KENTA
未経験からのエンジニア転職の必須教養【技術知識編】
https
://www.youtube.com/watch?v=Q1c09rrhTjo

奇をてらって、Laravel, Django を選ぶな。
転職先が多い、Ruby on Rails が有利

AWS EC2 はオワコンだから、Fargate を使えとか、
CircleCI, Github Actions, Terraform,
Nuxt.js, Type Script
2022/05/16(月) 15:44:43.87ID:XfoCH0Ek0
>>575
えぇ……サーバサイドでも非同期役立つやん……。仕組みからしてシンプルにスケールさせやすいし、DBの返答待つ間にできる処理回すとかもお手の物。
Promiseやawaitある現代JSでは非同期は簡単に扱えるし、Rustのactix-webとかも非同期だよ？
2022/05/16(月) 15:45:18.25ID:a802uHDS0
なるほど、非同期に苦手意識があるのかな
2022/05/16(月) 15:47:16.27ID:AoVbevXWM
非同期は必須
2022/05/16(月) 15:49:03.92ID:IoIRdAU7M
>>575
それは真逆
サーバーサイドは同期的にならない
様々なマイクロサーバー待ち、データベースサーバー待ち、ローカルファイルシステム待ち、など、これらを一つ一つ同期的に待つのは無駄だから非同期で並行処理させる
2022/05/16(月) 16:42:00.83ID:6UuQWNeTd
>>575
TPモニタですら非同期のAPI提供してきたのに…
2022/05/16(月) 17:01:53.01ID:UTxfnI1i0
>>576
それあなたの環境だけですよね？
2022/05/16(月) 17:05:06.95ID:UTxfnI1i0
>>580
だからそれがダメなんだって
そもそもそんな重い処理をしてる時点で論外
2022/05/16(月) 17:21:30.33ID:iHhbmbyAd
ビックデータどうすんの
2022/05/16(月) 17:23:54.78ID:DQrIwGMYM
同時接続数が100なのか万単位なのかで全然話が違う
2022/05/16(月) 18:19:39.14ID:i5j4+7lIM
この手の話は具体的なケースを想定するなりして前提を合わせないと話が噛み合わなくて時間の無駄
2022/05/16(月) 18:37:05.18ID:zuDvQ8ve0
>>583
>>580に対して「重い処理」なんて単語が出てくるようじゃ会話が噛み合わないわな。
本当にサーバーやってたのかすら疑わしい。
2022/05/16(月) 18:47:25.98ID:1RXpoL4NM
並列処理せずに素直に待ってろって事だろ
DBが遅いのは他の人が使っているからでその間に他の仕事をすると他の人がさらに遅くなりトータルでは悪影響しかない
2022/05/16(月) 18:48:19.78ID:UTxfnI1i0
あのーJsの非同期はrustのそれとは別もんです
まずそれを理解しましょうね
2022/05/16(月) 18:51:10.73ID:UTxfnI1i0
あとスレッド生成しないなら結局クソ重い処理をした時点で固まるんですよ
それが論外
スレッドにしてもスレッド生成のコストもバカ高い
データベース引くより遥かに重いことをやるメリットはなに？
Webサーバーの処理の中でやるとクソ重くなるというのはこういう意味ね
理解できたかな？
2022/05/16(月) 19:01:29.63ID:UTxfnI1i0
俺はプラグラミングモデルの話をしているんじゃない
速いか遅いかの話をしているんだよ
nodeが本当に速いならclusterモジュールなんかいらないのではないか？
2022/05/16(月) 19:19:36.98ID:e/cRZO3XM
>>588
用語の使い方からおかしい
まずは並列(parallel)と並行(concurrent)の違いを勉強しよう
ワーカーを持ち出さない限りJavaScriptのコード並行処理
そして並行処理であってもした方が速くなる

>>590
例えば重い(遅い)サーバー2か所からデータを引っ張って来ないと自分のリクエスト元に返せない重い状況であっても
同期的に直列に処理するよりも並行処理した方が明白に速くなる
同期処理は悪
2022/05/16(月) 19:31:25.09ID:XfoCH0Ek0
>>590
データベースが行っている事はCPUバウンドな処理だけじゃないんだよ。
それにCPUのマルチコアやネットワーク、ストレージを並行に使えば速くなるじゃないか。スループットにもレイテンシにも利くぞ。

>>591
clusterモジュールがやってるのはマルチプロセス化だ。スケールアウトの要だし、速かろうが遅かろうが必要なものだ。
2022/05/16(月) 19:41:55.35ID:6EEFsN+o0
元が糞遅いものがマシになるって話してる並行派と、
そんな糞重いものをそもそも書くんじゃねぇよっていう直列派の醜い争いってことでいいの？
2022/05/16(月) 19:55:58.84ID:AoVbevXWM
流石にIOバウンドでの非同期の必要性は理解できてるようだが
CPUバウンドの非同期については理解が足りてない

完全にCPUバウンドの処理AとBがあるとする
Aは終了までに100秒かかる
Bは1ミリ秒でおわる
多数のクライアントがABBBBBBB...とリクエストしたときを頭の中でシミュレーションしてみればはっきりわかる

シングルスレッドかつ完全に非同期だと全てのクライアントがAのせいで100秒待たされる
しかしここでAのアルゴリズムを変更しループ処理を分解して1秒に1回程度の頻度でawaitを挟むとする
するとAは1秒後にCPUを開けわたすのでCPUはAをいったん止めてBの処理を先に進めることができる
Bを実行したクライアントは1秒程度でレスポンスを得ることができるようになる
2022/05/16(月) 20:01:55.65ID:m61O0R3fa
>>594
前提条件がズレてるから噛み合ってないんだと思う

まずクライアントに即座に結果を返す必要があるWebの処理では重い処理はしてはいけないのはその通り
重い処理はバッチ系に回すべきだし

そのバッチが並行処理というのなら並行処理は必要
分散環境での並行処理とプログラミング内での並行処理でもまた違ってくる
そういう意味でそれほどズレてはいない気がする

またフロントエンドはシングルスレッドでブロックする処理は厳禁
そういう環境で生まれたJavaScriptのPromiseとそれを元にしたrustのPromiseはAPIは似てるが実装は違ったりする

なかなか面白いテーマだ
2022/05/16(月) 20:10:15.33ID:odRt9Swia
この流れみるだけでnodeサーバーはやめとこってなるよな
2022/05/16(月) 20:20:20.37ID:qCgVIFl5M
いやなんでやねん
2022/05/16(月) 20:24:07.73ID:XfoCH0Ek0
>>595
あえて極端な例を出してるんだと思うけど、そこまででかい処理ならスレッドなり生成してOSにスケジューリングを任せるかな。

というか皆別々の単位で重い処理ってのを考えてそうな感じする。俺はms単位で考えてた。
2022/05/16(月) 20:46:33.54ID:odRt9Swia
>>599
まぁ一般的にはCPUバウンドが高価な処理は他のサーバーに振るよね
フロントではそのタスクの終了が通知されるのを待つだけの話
で、この重い処理をクライアントで賄えたら、ってみんな考えるけどこれはこれでなっかなか難しいんだよね
2022/05/16(月) 20:53:55.85ID:DE3tyBMGM
>>597
むしろNode.jsは好ましいものの一つと分かったはず

>>600
2箇所のデータ返すサーバーからデータを得てまとめてクライアントに返すといった普通の軽い処理の話だよ
Node.jsなどの非同期が楽に扱える言語で実装すれば並列に2箇所を待てるから軽くて速い
2022/05/16(月) 21:50:31.18ID:nKEST01j0
ID:UTxfnI1i0の主張がとっちらかっててようわからん
同期非同期、ウェブサーバでの重い処理云々の話から
>速いか遅いかの話をしているんだよ
はイマイチ繋がりが読めない
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況