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/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
2022/05/20(金) 17:07:04.18ID:Gup2SPuad
setupだとかreturnとか面倒くせえ
普及しないわけだ
新たに始めて覚えるあいだに古いやつで何本もアプリつくれるだろ
そうこうしてるとまた仕様をかえてくるループ
2022/05/20(金) 18:59:28.62ID:ZVMU5bd00
仕様は動かさないで下さい
こういった頻繁な変更がエンタープライズアプリケーションで使いづらくするのです
2022/05/20(金) 21:38:26.64ID:icSQvEud0
recoilを使うと非同期でステータス更新する時のステータス管理が楽だな
contextを呼び出す書き方は、どのメソッドをオーバーライドするか覚えておくのが面倒だわ
628デフォルトの名無しさん (ﾜｯﾁｮｲ 1f18-bAjp)
垢版 |
2022/05/27(金) 01:45:51.49ID:B+c0w6Pq0
TSって意味ないだろ
型つけても速くなるわけじゃないし非生産的過ぎる
コード長くなって作るの遅くなるだけ
2022/05/27(金) 05:49:52.71ID:gss6SgrQ0
型推論あるから型をつけるのは（関数の引数やJSON等）データの出入り口くらいでそんなにコード伸びない。
生産性が落ちる要素は型エラーを消すべく型パズルに頭悩ませたり、バリデーションに気を使ったり、ビルドを組み上げたりする部分。
逆にインテリセンスや、厳格なコメントとしての型など、生産性が伸びる要素も多い。特に後から改修するときに凄く役立つ。
生産性は規模によるけど、悪くてもトントンで、むしろ上がる。
実行時エラーをほぼ消せるので枕を高くして眠れる価値はプライスレスw
あと地味にJSよりTSのコードの方が熟達者が書いてるケースが多く、玉石混交なネット上のソースを見るときに役に立つ。
2022/05/27(金) 06:07:36.80ID:QlGRmtWta
トランスパイル環境作りめんどいからあえてjsのネットのソース使ってるわ
2022/05/27(金) 08:25:38.89ID:cdC2AjzLM
JSとTSだったらTSのがいいよ
あまり強力ではないけどいちおう型安全でインテリセンスも効く
2022/05/27(金) 08:25:47.90ID:tqR3qcVja
>>628
作るサイトが大したことしないんなら要らないんじゃない？
2022/05/27(金) 08:51:52.91ID:aeyQTPTPa
TSに対応したよ！（TS版のドキュメントを作ったとは言ってない）
これがなければなあ
2022/05/27(金) 10:36:59.59ID:SjE05UxVM
型のもたらす恩恵が分からないというのはある意味幸せなこと
2022/05/27(金) 10:39:41.17ID:X2EnXYhx0
フロントおじさんは別名consoleおじさんだから
2022/05/27(金) 16:10:05.44ID:4jZnoEWod
20年前コンパイルできたのに不用品扱いだったのがJScript .net
どう見てもその矮小化版のTypeScriptなんてゴミに決まってんだけどな、今の若い子にはキラキラ見えてんだろうな。
2022/05/27(金) 16:17:49.35ID:G9ybTKrgr
昔話しかできないおじさんかわいそう
2022/05/27(金) 18:37:27.10ID:gss6SgrQ0
>>636
ググってみたけど明らかにTypeScriptとは別物じゃん。JSを.NET向けに強引に矯正した醜悪な代物じゃん。当時のMSはこういうの多かったな
2022/05/27(金) 19:04:13.88ID:9SIeHNxX0
当時はなんでも～.netってのが出るのかと思ってた
2022/05/27(金) 19:20:02.08ID:rGg+7oBEM
何をもって「どう見ても矮小化版」と判断してるんだろうね
2022/05/27(金) 19:49:47.91ID:Bc7zCTdYr
TSは型の足し算、引き算がUI開発にめちゃくちゃ良い
2022/05/28(土) 06:19:13.77ID:jNgQBc1X0
20年以上プログラミングやってるやつがこんな発言したのかと思うと、いっそ切なくなるな
2022/05/29(日) 02:37:46.01ID:K8aquu2V0
Remixを参戦させてくれや
最高の使い心地
2022/05/29(日) 10:32:18.57ID:ig8caTNF0
どんなに良くても情報が少ないと致命的なんだよなあ
645デフォルトの名無しさん (ﾜｯﾁｮｲ db02-O+bm)
垢版 |
2022/05/31(火) 03:28:55.50ID:yPBYm6AK0
昔から型書くの大変だから動的型付けにして書く量減らそうって流れだったのに逆行してるじゃん
型書いても結局周辺のコード見たり動作テストするんだから一緒だよ
型付けして動作が速くなるならまだしもそれすらないなら自己満感だけのオナニーコードだよ
646デフォルトの名無しさん (ﾜｯﾁｮｲ db02-O+bm)
垢版 |
2022/05/31(火) 03:41:46.94ID:yPBYm6AK0
賢者は歴史に学び愚者は経験に学ぶ
本当に賢い奴はJSを選択する
わざわざ余計なコードを書く必要はない。型付けはシステムに自動でやらせるべき。シンプルisベストだろ
647デフォルトの名無しさん (ﾜｯﾁｮｲ db02-O+bm)
垢版 |
2022/05/31(火) 03:44:02.74ID:yPBYm6AK0
動的型付けを否定するという事は自動化を否定するという事であり
システム自体を否定する事である
プログラム自体を否定するのと同じだ
648デフォルトの名無しさん (ﾜｯﾁｮｲ db02-O+bm)
垢版 |
2022/05/31(火) 03:45:51.50ID:yPBYm6AK0
型付け最高！はいつまでもオートマを否定しマニュアル最高！と言ってるようなもん
2022/05/31(火) 03:50:50.55ID:NNzmqFeUr
正直どっちでもいい
動的だろうが静的だろうが業務系システムで複数言語で動的静的両方で組んでるけどエラーなんて起こしたことない
2022/05/31(火) 05:59:57.13ID:5m0UDVmd0
型あり型無し好きなもん使えば良いよ。
ただ、型あり言語が自動化されてないってのは間違い。
型という情報をコンパイラやエディタに与えることで、自動でエラーを発見してくれたり、型演算で何が指定できるかを教えてくれたり、推論でそもそも書く必要が無かったり。少しの情報で色々自動化される。
2022/05/31(火) 07:27:46.85ID:O5wT99Nb0
この独特な文と連投具合、いつもの人かな
2022/05/31(火) 07:37:20.95ID:HDbDKB3F0
一人で作る難易度の低い、使い捨てのツールならいいんじゃない？
逆に、ビジネスルールが複雑、複数人で開発する、寿命が長いシステムは型がないとしんどいだろ
2022/05/31(火) 08:58:38.54ID:tbsCZ2HBd
ビジネスロジックが複雑なシステムは一般にバックエンドの比重が大きいから、フロントエンドの型の有無は実はあまり関係なかったりするね
バックエンドはTypeScriptだけどフロントはBabelなんてのも見たことある
しかしバックエンドとフロントで微妙に似て非なる言語を使うのは非効率なだけだしビルドパイプラインも無駄に複雑になる
現実にはフロントでのTypeScriptはBabelの代替として型緩めで運用されてるケースが多いんじゃないかな
2022/05/31(火) 09:57:57.54ID:Fy6rwZDC0
型ありがいいです
ある程度のエディタなら静的解析効くってくらいのがいいです＼(^o^)／
実行するまでエラーわからないのはイヤです
2022/05/31(火) 11:53:31.52ID:Z56N724qM
>>651
毎度釣り針が大きすぎるんだよな
656デフォルトの名無しさん (ﾜｯﾁｮｲ c918-A0bq)
垢版 |
2022/05/31(火) 14:57:29.43ID:zhmqFn8J0
型最高！とか言ってる奴は自分の書いたコードしか見てないだろ
自画自賛してるだけ
フロントの大規模開発でTSちゃんと書ける奴大量に集めるなんてそうそう出来ない

ってかフロントの大規模開発なんてそうそうないだろ
だいたい書く人は1人から3人程度で相当大規模でも対応出来る
2022/05/31(火) 15:08:02.08ID:ezVaWrUp0
ぶっちゃけ一人で書いたほうが効率いいわ
2022/05/31(火) 16:53:11.76ID:5m0UDVmd0
>>656
つまり、TS使えるやつ3人集めれば十分って事？
2022/05/31(火) 17:25:46.51ID:O8RZnMC90
>>656
型がわからないエンジニアばかりの空間って存在するのか？
型は大規模開発の必須要件だと思うの
2022/05/31(火) 17:41:20.31ID:ufxJhZaQM
>>656の大規模は3人月
661デフォルトの名無しさん (ﾜｯﾁｮｲ c918-A0bq)
垢版 |
2022/05/31(火) 18:17:01.89ID:zhmqFn8J0
TSスラスラ書ける奴3人なら結構色々出来るはずだけどな
そもそも狭い範囲を多人数でやり過ぎるのもやり難いからモノレポなりにして担当範囲分けた方が良いし
ますますTSの必要はなくなる
2022/05/31(火) 18:17:30.99ID:yK5XL3mgM
SvelteKitを345に上げたらstatic下のシンボリックリンクを読まなくなったので元のバージョンに戻した
663デフォルトの名無しさん (ﾜｯﾁｮｲ c918-A0bq)
垢版 |
2022/05/31(火) 18:19:15.21ID:zhmqFn8J0
バックエンドPHPでフロントがJS系なんて腐る程あるだろ
GOとPHPじゃ生産性全く違うし動的型付け選択なんて十分有り得る
2022/05/31(火) 18:30:34.74ID:Qq0V5Ts0M
TSは良いと思うけどビルドの蛸足配線だけはどうにかして欲しい
C#から多くを学んだようにdotnetからも学ぶべき
2022/05/31(火) 18:31:18.82ID:YqJEkN6cM
フロントの大規模開発ってページ数が多いだけだろ
ページがどんだけ増えようがデータとHTMLをマッピングするだけの単純作業なら複雑さは変わらん
もちろんSlackみたいなのを作ってるなら別だけどね
2022/05/31(火) 18:34:13.71ID:Qq0V5Ts0M
フロントの大規模ってDB管理ツールだとかVSCodeのようなイメージ
2022/05/31(火) 21:42:20.25ID:OmesV7rg0
＞データとHTMLをマッピングするだけの単純作業なら複雑さは変わらん
悲しいなあ、もうちょい楽しい案件やればいいのに
せっかくこういうスレにいるのに
668デフォルトの名無しさん (ﾜｯﾁｮｲ c918-A0bq)
垢版 |
2022/05/31(火) 21:51:29.48ID:zhmqFn8J0
座標とか使うようなSPAの利点を最大限活かした案件もあるよ
実装が面倒臭いけど
2022/05/31(火) 22:00:51.71ID:ZjE3sOpEr
大規模案件やってるが基幹システム作ってる
ページというよりコンポーネント設計だな
DBがかなり複雑でそれに合わせて画面開発
コンポーネント同士が連動しているからSPAは開発しやすい
バックエンドはJava
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況