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(土) 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の主張がとっちらかっててようわからん
同期非同期、ウェブサーバでの重い処理云々の話から
>速いか遅いかの話をしているんだよ
はイマイチ繋がりが読めない
2022/05/16(月) 22:00:34.18ID:FZsPlm29M
いずれのケースでもサーバーサイドはローカルファイルシステム待ちや他のサーバー待ちがほぼ確実に入るのだから
それらを順次処理しかすることが出来ない同期プログラミングは不利
並行処理することが出来る非同期プログラミングは有利
2022/05/16(月) 22:33:40.10ID:1cDlwRW1a
>>602
だね
node最高って言いたいだけなんだろうけど
2022/05/16(月) 22:38:47.31ID:zuDvQ8ve0
>サーバーサイドはpython1択だろ

こんなこと言ってた奴がNode.js否定するんだから笑える。
2022/05/16(月) 23:14:35.31ID:XfoCH0Ek0
ワッチョイあるから曲がりなりにもスレが機能するなぁ
2022/05/16(月) 23:29:01.92ID:U0Am7PfN0
nodeは完璧ではないだろうけどnodeが頭ごなしに否定される要件って生き残る言語がほぼない気が
2022/05/17(火) 01:01:12.57ID:PUUcKTl00
https://knowledge.sakura.ad.jp/24148/
この辺読むと>>575はデタラメ以外の何物でもないな
2022/05/17(火) 05:45:28.08ID:ljngt0Cn0
なるほど、あのアンチ非同期の人はC10K問題を理解してないんじゃなくて、そもそも知らなかった可能性があるのか
2022/05/17(火) 09:19:23.29ID:fFq5aUVM0
そいやしらんけどangularにもNextみたいなのあるん？
2022/05/17(火) 15:39:36.94ID:gaF/x0PY0
例えば、画像のサムネイルを作るような、CPU セントリックな処理は、
直接、App・Web サーバーで処理しない。
他のサーバーへ回す

AWS Lambda では、
1. 画像をS3 へアップロードする
2. それをトリガーに、Lambdaが起動
3. 画像のサムネイルを作成
4. そのサムネイルを別のS3バケットへ追加する

これを、Ruby on Rails のActive Storage では、Image Magick, libvips を使う。
Appサーバーを経由しない、ダイレクトアップロードもできる
2022/05/17(火) 21:11:42.44ID:5sTsDSNCM
>>610
angular自体がnextみたいなものじゃないの？
2022/05/18(水) 13:46:42.60ID:pBGsXlbta
>>608
俺の留守の間に好き勝手やってくれたようだな
仕事に忙殺されて見る時間がなかったわ

知ってないわけないだろ
むしろお前が今調べたんだろ
しかもそれだいぶ前だぞw

あと接続数の問題と「処理を捌ける」とは別物
全てが幻想の話なんだよ

後そもそもクラウド全盛時代に1台の性能や接続数を語ってもナンセンス

nodeが生まれた時代はクラウド全盛期前
アーキテクチャが古くても仕方ない
現に最近はC10K問題とか誰も言ってないだろ
nodeにやって解決されたわけじゃないぞ
2022/05/18(水) 13:47:48.03ID:Q05gEBgM0
今さら出てきてふわっとした単語で吠えてて草
2022/05/18(水) 13:49:25.58ID:pBGsXlbta
ちなみにdenoでは非同期の利点などもはや一歳言っていない

むしろセキュリティとサーバーサイドをフロント側のWeb標準に合わせるという点を強調している
2022/05/18(水) 13:51:31.15ID:pBGsXlbta
あと勘違いしてるようだが俺はnodeの非同期がクソと言ってるだけで
一般的な非同期や分散環境を否定してるわけではなく
むしろそっちはやるべき派

それは上の俺の書き込みを見てくれればわかるだろう
2022/05/18(水) 13:52:05.20ID:pBGsXlbta
俺の書き込みに対して真正面から打ち返せない奴が何を言っても無駄だ
2022/05/18(水) 13:57:10.42ID:pBGsXlbta
C10K問題を今更出してきたということはもしかして
nodeの非同期を知らなかったということか？

恥ずかしい
流石にそれ恥ずかしい

議論の舞台にすら上がってなかったのかよ
2022/05/18(水) 15:34:10.89ID:UHYN5VPTM
>>616
> 一般的な非同期や分散環境を否定してるわけではなくむしろそっちはやるべき派
> それは上の俺の書き込みを見てくれればわかるだろう

>>575
> サーバーサイドは全部同期的に動くのがベスト
> 同期で動いていかに早くレスポンスを返すかを設計するもの

嘘じゃんww
nodeの非同期が他とどう違って、それがどうして「サーバーサイドは全部同期的に動くのがベスト」に繋がるのかな？
2022/05/18(水) 15:55:49.00ID:Q05gEBgM0
結局顔真っ赤にしちゃって連続カキコでクソクソ吠えてるワンちゃんやんw
具体的に「こういうコードや設計や非同期がこうだめ」って言えないんだろw
2022/05/18(水) 20:38:18.17ID:KwZ7Wkgo0
最初からC10K問題が念頭にあったならあんなに「重い処理」にこだわったりしないと思うがな。
2022/05/18(水) 21:56:00.38ID:oTMHjH2B0
>>613
>あと接続数の問題と「処理を捌ける」とは別物
>全てが幻想の話なんだよ
？
ちゃんと意味の通る日本語で頼むよ
2022/05/18(水) 22:43:43.34ID:GtCaCq+I0
誰かが青天井でお金を払ってくれるならいいけどそうじゃないなら1台で捌ける数がどうでもよくはないよなあ
624デフォルトの名無しさん (ｵｯﾍﾟｹ Sr6f-zs7H)
垢版 |
2022/05/20(金) 13:27:58.01ID:qat+Km1Or
vue3.2の記法ほぼsvelteじゃんw
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況