Vue vs React vs Angular vs Svelte Part.10

1 名前：デフォルトの名無しさん mailto:sage [2022/03/08(火) 22:57:16.85 ID:D77bZcWT0.net] !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 496 名前：デフォルトの名無しさん mailto:sage [2022/05/12(木) 22:01:26.54 ID:kgXbK+rw0.net] JScript.NETから進化してる？ 497 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ b77d-d5Qg) mailto:sage [2022/05/13(金) 18:48:59 ID:zD7+eQiB0.net] TSがどうこうというより、動的型付けの型チェックぐらいもっと手軽にやりたい googleの賢い人たちに期待してる 498 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2a00-ckJZ) mailto:sage [2022/05/13(金) 18:56:41 ID:gY0FxiLY0.net] 型は複雑なものだしTSはMSのレジェンドが生み出した言語だゾ。 マジレスするとSuperstructとか使えば？ 499 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) ] [ここ壊れてます] 500 名前：01:09:33.55 ID:pZnfA7Wr0.net mailto: >>491 TSには現在進行形でお世話になるよ。これがないとJSはnullが怖い あとSuperstructを教えてくれてありがとう 調べてみるぜい [] [ここ壊れてます] 501 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 08:36:20.76 ID:sMGvGTwPa.net] 勉強中の身なのですがtsを使う理由ってこんな感じでしょうか 理解や用語が誤っていたらご指摘ください。 tsを使う理由（サーバーサイド） tsは型を厳密に定義することができるのでサーバーサイドでの利用、特にドメイン層でのビジネスロジックの記述に適している。 tsを使う理由（View） サーバーも同じ言語を使うことで、サーバーで定義したモデル（レスポンスモデル等）をViewでも定義するという二度手間がなくなる。 ただしView側でtsでビジネスロジックを記述すると、利口な UI アンチパターンになってしまうので注意。 502 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 09:12:28.76 ID:sn4udcUf0.net] >>493 TypeScript検定でも受験すんの？ 503 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 09:48:51.54 ID:sMGvGTwPa.net] >>494 社内の技術選定で候補に挙げようかと 504 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 10:07:07.91 ID:UUXyqx7tM.net] 鯖でtsはないかな 505 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 12:11:20.40 ID:lXb0w+3k0.net] かと言ってPHPやPythonはアレだし、JavaやC#はアホみたいにメモリ食うし、Node.jsで（fastifyとかで出入り口をガチガチに固めれば）良いじゃんってなることは結構ある。比較的簡単にスケールするし、クラウドでも大体使えるし。 506 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 12:22:01.90 ID:GNnPWoYV0.net] まあサーバがJSTSであるメリットは、 フロントと言語が共通しやすくなることでの総合的な学習コストの抑制がメインやろからね 仕事なら各予算とかパフォーマンスとか、要件に合わせてちゃんと多角的に評価すべきだとおもうよ 507 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 12:39:34.79 ID:UUXyqx7tM.net] 共通っていうほど移植性ないでしょTS 逆に混乱するから別言語のほうがいいと思うよ 508 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 12:44:48.12 ID:UUXyqx7tM.net] >>497 https://www.takigawa-memo.com/compare-language-atcoder/ TSはJavaやC#より遅くてメモリ食ってるよ 509 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 12:59:34.72 ID:UUXyqx7tM.net] ちと古いが ttps://cryptomode.com/c-is-the-most-energy-efficient-and-fastest-programming-language-study-finds/ 言語比較ってたまにググると色々出てきて面白いね エネルギー消費量なんてのも比較されてんだ 510 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 13:00:57.29 ID:YyWH0a110.net] 移植性は関係ないんじゃね。単に環境や知識が一本で済むというだけ。 論点はほかにもあるだろうけどそのへんは要件に照らして個別に判断する話であって、 そういう前提なしに >鯖でtsはないかな なんて断言できるもんでもないだろう。 511 名前：デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MM49-ur9t) mailto:sage [2022/05/14(土) 13:31:51 ID:UUXyqx7tM.net] >>502 動くもの動かないものが意外と違うんで一本で済むと思って始めると辛い stringに生えてるメソッドですら環境依存 そもそもフロントとバックって書き方もアーキも勘どころも依存先も違うんで言語だけ合わせてもって感じ 512 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ ff00-GCUU) mailto:sage [2022/05/14(土) 13:37:03 ID:lXb0w+3k0.net] >>500 ほんまかと思って数年ぶりにjava書いたけど普通にNodeの倍以上メモリ食ってた。 AtCorderはたくさんVM立てるから（forkとかかな？）なんか設定が違うんじゃないかな。 とはいえ思ったより食わなかったので、バ� 513 名前：J食いは訂正します。 [] [ここ壊れてます] 514 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 13:41:17.73 ID:DuvSDtMha.net] バックもフロントもコード補完と型安全性、型情報によるドキュメントの補完を目的としてるな バックでts使った事ないけどapiのスキーマの定義はopenapi使ってれば他の言語使ってても生成できるので二度手間にはならないよ 515 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 13:48:11.53 ID:GNnPWoYV0.net] あくまで学習コストが低いくらいや、とワイも思う まあドキュメントとかも少しは節約できるかもくらいかな 社内にJSTSのコミュニティがあるとかなら十分検討に値するんじゃね 会社なんて千差万別なんや 516 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 13:53:46.11 ID:bL0HlggA0.net] 継続的に開発するならなんでもいいけど リリース後は放置するようなものだと、問題が出たときに久々に見てもなんだっけこれ？にならない楽さはある フロントからJSが駆逐されたらそれも通じなくなるだろうけど 517 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMb3-9b1c) mailto:sage [2022/05/14(土) 14:36:41 ID:LJgHQn+CM.net] いまどきの学習コストは言語自体よりライブラリやらフレームワークの占める領域がな・・・ 言語を揃えてもコスト削減効果は限定的な気はする 518 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3fac-YYQQ) mailto:sage [2022/05/14(土) 14:42:40 ID:wZ/dlG450.net] でもバックエンドが.netとかjava系でフロントreactよりnextのほうが学習コストは低いやろ 519 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 15:04:21.52 ID:LJgHQn+CM.net] さあ？ それを比較できる根拠は何ももってないから肯定も否定もできないな 520 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 18:15:30.80 ID:4GKPU3lGa.net] 皆さんご意見ありがとうございます。 大体の認識はあってそう…？ ガチガチの業務システムになるので、サーバー側は堅牢な言語にしたいところですが… >>505を読む限り、言語が別でも二度手間感はないのでしょうか サーバーサイドに定義したレスポンスモデルを変更したら、自動的にフロントサイドも書き変わるのが理想ですね。 しかし意見が結構別れますね フロントサイド、もしくはサーバーサイドしかやってない人は言語なんてバラバラでもいい どっちもやってる人は一緒の方がいいってなるのかな 521 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 18:20:06.66 ID:0bRjAEIy0.net] フロントエンド出身の人は同じ言語でいいじゃんってなりやすいし バックエンド出身の人は鯖でJSTSとか氏ねよって人多いだろうし 522 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 18:26:21.07 ID:UUXyqx7tM.net] JSはまあ論外としてTSしかできないならTS そうでないなら別の言語でいいんじゃないの TSのカジュアルさは場合によりメリットになりうる がしかしJSから継承した多数の変な罠、変化の速い依存関係、低品質な標準・非標準ライブラリを持ち込むデメリットのほうが大きいと思うね 523 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 18:43:36.84 ID:YyWH0a110.net] 程度問題だな。 pythonやrubyのバックエンドなんてのも平気で存在しているわけだし。 524 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 18:43:56.92 ID:wtoFZqAo0.net] >>511 そもそもこのスレでサーバサイドについて質問する時点で 回答にある種のバイアスがかかるであろうことは想定しないと サーバサイドについて公正な意見が欲しいならそれに適したスレに行くことを勧めるよ 525 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 18:50:21.52 ID:PIqdDhGKd.net] 言語単体でどれがとはいいにくいかな 今時は何らかのフレームワークにのっけることになるけどフレームワークも複雑化しているから使い慣れたものを選択するケースが多い でそこにマッチした言語を多用することになる でこれまた使い慣れた言語以外は使いにくいなあと思うように… 526 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 19:21:28.20 ID:59Ewxs6ZM.net] >>501 やはりCとRustが圧倒的に効率的なんだな ブラウザサイドはJavaScript＋Rust(Wasm)のハイブリッドが最も効率良いし サーバーサイドはRustがクラウド等コスト最小にできるから 今後はJS(/TS)＋Rustの両者だけで最も効率良く行けるね 527 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 19:35:06.42 ID:wZ/dlG450.net] とりあえず要求要件まとめるのが最初じゃね 会社の得意言語が決まってるとかじゃなけりゃさ ガチガチの業務システムのコア部分が何がしかのフレームワークで果たしていいのか、とかもあるやろ 528 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 19:47:16.30 ID:lXb0w+3k0.net] ぶっちゃけ余程マイナー言語じゃなきゃなんでも書けるし、要件や現状にあったものを選ぶだけ。早まった最適化は無駄どころか後々の負債になりかねないからね 529 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 20:19:21.78 ID:rJz/kRn+0.net] サーバーサイドはpython1択だろ 新規ならこれで間違いないよ 現時点でnextだのnuxtだの自前で運用するものではないぞ どんだけコストかかるか 530 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 20:23:46.80 ID:vireAt4B0.net] 使ってないけど最近サーバーサイドでGoは流行り始めてるってのは何回か聞いた 531 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 87b9-az5c) [2022/05/14(土) 20:44:36 ID:zxDXnmN60.net] フロントはVue.js 3、サーバーサイドはPHP 日本においてはこれが最適解だよ なんで日本に住んでるのにReactとかいうどこの企業も使ってないライブラリ使いたがるのか理解できん 532 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ e302-lIli) mailto:sage [2022/05/14(土) 20:58:56 ID:vireAt4B0.net] >>522 Vue2の時は悪くなかったけどVue3の日本語ドキュメント全然充実してないやん 533 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ c72d-lIli) mailto:sage [2022/05/14(土) 21:05:18 ID:TQJ9y2tp0.net] 弊社、退職済みの自称イケイケエンジニアがnodejsで業務システム作ったおかげで 負の遺産となってる 534 名前：デフォルトの名無しさん (ｱｳｱｳｱｰ Sa83-k6zu) mailto:sage [2022/05/14(土) 21:08:48 ID:4GKPU3lGa.net] >>515 でもこの板って特定の技術のスレはあれど アーキテクチャをテーマにしたスレがないんですよ あっても過疎ってるんですよ ちょうどこのスレでtsの話題があったので投稿した次第です しかしサーバー、フロントどっちもやってる人はすくなそうですね。 うちは規模が小さいのでどっちもやる羽目になりそうなのですよ。 535 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1f5f-bIPI) mailto:sage [2022/05/14(土) 21:09:06 ID:q0VbptyB0.net] >>522 メルカリ、LINE、Yahoo、マネーフォワード、SmartHR、DeNAとreact(nextjsも含めて)をプロダクトに使用してる企業は枚挙に暇がないんだが・・・ 536 名前：デフォルトの名無しさん (ｱｳｱｳｴｰ Sa93-iKbs) mailto:sage [2022/05/14(土) 21:09:49 ID:DuvSDtMha.net] >>524 nodeサーバーゴミだよね 537 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 21:16:45.10 ID:DuvSDtMha.net] >>511 両方やってるけどバックとフロントは言語ちがうね フロントは使う技術そんなに変わらないけどバックエンドはプロジェクト毎に要件かなり違うから幅が広くなっちゃう 最初からnodeでやりましょうって決め打ちはしないかな 538 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 21:17:27.35 ID:ng6xGQr50.net] websocketをガッツリ使うならsocket.ioのあるtsがサーバーサイドでも一番！とか思ってるんだけどこの認識もしかして古い？ Pythonのswampdragonとかスケールしないって記事を見たことがあって 539 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 21:26:52.64 ID:DuvSDtMha.net] >>529 swamp dragonというかdjango自体があまり使われてない印象 今はfastspi一色かも 540 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 21:27:15.79 ID:59Ewxs6ZM.net] >>527 Node (JavaScript) がゴミだと言い張るあなたは何の言語を使っているの？ 541 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 21:52:35.44 ID:wtoFZqAo0.net] >>525 >でもこの板って特定の技術のスレはあれど >アーキテクチャをテーマにしたスレがないんですよ じゃあこの板自体がその手の情報収集に適してないということ 技術ブログとか漁ってみればある程度まとまった情報も手に入るかもよ >しかしサーバー、フロントどっちもやってる人はすくなそうですね。 少ないかどうかはわからんけど、自分が少し前にやったのはVue+SpringBootで 選定と実装はひとりでやったよ 542 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 21:56:55.67 ID:UUXyqx7tM.net] >>529 SignalRとか 543 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 22:42:44.47 ID:h9YALwRY0.net] >>529 そんなもんJavaにでもC#にでもなんにでもある あとWebSocketと従来のソケット通信は若干送信内容が違う 544 名前：デフォルトの名無しさん mailto:sage [2022/05/14(土) 22:49:45.09 ID:rJz/kRn+0.net] >>529 websocketだけならnodeでもいいけど それ以外の処理はどうすんのよ データベースやキャッシュなどのWebの根幹をなす処理をさ nodeの不得意分野 545 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 00:06:24.43 ID:PKOM7k+T0.net] 最初に用件をある程度固めて、 それを実現できるフレームワークやライブラリを調べて、 言語は最後にベストなものを選択する 開発にかかるコストの全体の中で、言語の取得なんてかなり小さい 546 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 07:24:17.87 ID:/QC8ypewr.net] 遅いしメモリ食うPythonをバックエンドなんかに選ぶ理由はないわな 547 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 07:45:14.36 ID:g61xzk710.net] >>535 不得意でもないけど 548 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 12:45:04.08 ID:jYft1JFw0.net] >>511 >>サーバーサイドに定義したレスポンスモデルを変更したら、自動的にフロントサイドも書き変わるのが理想ですね。 かってに変わられたら困るですけど(´ω｀) 堅牢とか言ってる割にはなんか根底が矛盾してんですけど 549 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 15:07:20.10 ID:Pwx8c3iM0.net] >>539 開発中の話ね 項目名が変わったり、減ったりしたときに困らない？ 550 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 16:21:49.45 ID:vHVXFnMOd.net] i/f変わればいずれにしろその項目に対して適切な処理が必要というか作り込みになるから勝手にはこまるのでは idlぽいものを双方合意で共有するのが現実的では 551 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ abcf-7P1Y) mailto:sage [2022/05/15(日) 16:44:09 ID:VMVrIVgn0.net] OpenAPIの定義で握ってるような開発ってどのくらい普及してんのかな。 うちは単にドキュメントとしてしか使ってないけど、あれデータ定義がjsonschemaだから冗長で大変なんだよな。 552 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 16:52:54.26 ID:vNRch2400.net] 古くはWSDLとかSOAPとかあったけど、お手軽シンプルなRESTに滅ぼされたのよな 553 名前：デフォルトの名無しさん [2022/05/15(日) 17:33:08.47 ID:k55J8NDG0.net] 今でもSORPやCORBAが負の遺産で残ってるとこ多いね Restに駆逐されて良いわ 554 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 17:51:00.04 ID:ezWJ6neIM.net] Swaggerって実質的にWSDLの再発明みたいなもんでしょう WSDLを安易に滅ぼさずに最適化し洗練させていけば 技術間の断絶が起きず移行コストを抑えつつ今と同じような形態に落ち着いたのではと思う まあいまさら何を言っても過去は変わらんのだけど 555 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 18:15:18.89 ID:Pwx8c3iM0.net] >>541 自分は勝手に変わって、コンパイルエラーになる方が嬉しいわ 変わってることに気付かないのが怖い 556 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sddb-nHzh) mailto:sage [2022/05/15(日) 20:14:06 ID:jKD1Yf03d.net] リクエストやレスポンスに載せる要素を勝手に追加して送っても受け取る側がさわらなけりゃエラーにもならずそのまま漏れるケースがでてくるよ ぼっち開発ならいいけど複数人でやるならコミュはとらんと 557 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 20:40:00.47 ID:VMVrIVgn0.net] >>547 それで困るシーンがいまいちイメージしづらいな。 受け取る側で必要ないデータを勝手に追加しても使われないから別に問題ないんでは？ 558 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMb3-9b1c) mailto:sage [2022/05/15(日) 21:01:47 ID:yFmPLlmrM.net] >>539が何をもって堅牢と矛盾してると言ってるのかようわからん 559 名前：デフォルトの名無しさん (ｱｳｱｳｳｰ Saaf-k2uo) mailto:sage [2022/05/15(日) 21:26:19 ID:3/ngjaD/a.net] >>514 Rubyは一時期ゴリ押されてたからまあまあ多いだろうな 560 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ efba-k6zu) mailto:sage [2022/05/15(日) 22:05:09 ID:Pwx8c3iM0.net] >>547 いやそりゃレスポンスモデル変わったことは通知するよ でも人間がやることだから必ず対応漏れが出る 大幅な変更で対応漏れがあったらもうどうしようもないけど ちょっとスペルミスがありました程度で対応漏れで値が表示されなくなるのはつらい 561 名前：デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MM49-ur9t) mailto:sage [2022/05/15(日) 23:14:33 ID:ezWJ6neIM.net] 型安全な言語だと当たり前の感覚だけどスクリプトをやってる人にはピンとこないのかも 562 名前：デフォルトの名無しさん mailto:sage [2022/05/15(日) 23:49:50.15 ID:Pwx8c3iM0.net] >>552 言語というか フロントのみしかやらない人は、IFの変更があったときはバックエンドから通知が来るのが当然で、 通知が来なくて不具合が出たとしてもそれは通知しない方に責任があるというような考え方ではなかろうか システムの形態によってはスマホアプリもあるだろうし、その場合はフロントとバックの言語が違うなんてのは当たり前なんだろうけど、 ブラウザのみの場合は極力フロントとバックの言語を合わせた方がメリットが多いと思う 563 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 00:40:22.43 ID:cASOeT3aM.net] メリットがあるのは理解するけどバックエンドの選定って運用とかにも大きく絡むから 開発の都合だけを押し通すわけにもいかなくない？ 要件的制約的にどれを選んでも大差ないってときにじゃあ同じ言語にしとくかってのは否定しないけども 564 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 00:51:53.77 ID:NcmrqgSm0.net] というかバックエンドは負荷が集中する箇所だから 小さい規模ならまだしも本来ならば バックもjavascriptで書くなんてあほなマネは極力避けるべきだろ 565 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 01:59:51.50 ID:UTxfnI1i0.net] だからフレームワークも運用も枯れまくってるRuby Python PHP Javaのどれかがベスト 566 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 06:03:18.76 ID:IGDmE8Ky0.net] バックエンド側を勉強する機会がない クラウドファンクションの実装で済ませる機会が多くて… 567 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ ff00-GCUU) mailto:sage [2022/05/16(月) 06:24:16 ID:XfoCH0Ek0.net] >>555 一般的なRESTサーバーで負荷の集中が予測される場合、クラウドでも自前サーバでも一番気にしなくてはならないのはDBがスケールするか否かじゃね？ 568 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 09:44:15.27 ID:a802uHDS0.net] 言語合ってくれるとバックエンドはフロントのこと分かりやすいだろうな、とは思うけど 合わせてくれとまでは思わない それよりも優先すべきことが多い てかまあスレタイとはズレていくな 569 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 10:17:06.28 ID:03MF3TRNd.net] それは逆だな 一般にバックエンドのほうが技術的に幅広く理解している人が多いから、言語が違ってようがバックエンド担当がフロントを読めないってことはまず無い 当たり前のことだし煽るつもりもないが、フロントの人の方がJSに拘る傾向は遥かに強い 570 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ ff00-GCUU) mailto:sage [2022/05/16(月) 10:37:26 ID:XfoCH0Ek0.net] バックエンドでも一つの言語や一つのフレームワークしかわかりませんみたいな人いるけどなぁ。本人次第過ぎる 571 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 73f1-t7Xx) mailto:sage [2022/05/16(月) 11:19:17 ID:2hxrh63x0.net] >>560 ？ 572 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 11:47:58.40 ID:a802uHDS0.net] なんかズレてんな まあどこの会社のバックエンドが優れてる優れてないってのは様々やしな 今のフロントを理解できるバックエンドってのもなかなか貴重な気はしてる 573 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 12:16:20.57 ID:zuDvQ8ve0.net] だよな。実際、人材探してもフロント(SPA)できる人のほうが希少だったわ。 574 名前：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr93-fo/a) mailto:sage [2022/05/16(月) 12:48:31 ID:zUcFmi9Cr.net] SPAやフロントなんてシステム全体からみたらデザイナーの仕事だからどうでもいいんだよ 575 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sddb-nHzh) mailto:sage [2022/05/16(月) 12:48:38 ID:wSD9JNVwd.net] フロントもバックもそれぞれ人材はいるけどspaするなら結局前後でデータ整合や認証関連、フロー制御の連携するために間に立って全体をみる役割の人材が少ない印象 576 名前：デフォルトの名無しさん (ﾜﾝﾐﾝｸﾞｸ MM1b-eHJy) mailto:sage [2022/05/16(月) 13:00:15 ID:IoIRdAU7M.net] >>566 結局フルスタック出来るか、それとも一部しか出来ないか、だよね 言語をどれにするかは独立した別の問題 システム的に許容範囲ならば全てをJavaScriptでも問題ない 逆にサーバーリソースコストが重要ならばスクリプト言語を使っていてはダメだし、 ブラウザ側も重い処理が入るならばJavaScriptだけではダメでWasm必須など 577 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 13:13:26.71 ID:j5xHL+8m0.net] ここサーバーサイドjsは劣ってるって決めつけてる人いない？ 表現力もライブラリも実用レベルだと思うが 578 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 13:22:53.05 ID:IoIRdAU7M.net] 速さの性能面に限っても、 V8のおかげでスクリプト言語の中でもJavaScriptは断トツに速いから、 他のスクリプト言語を使っていても大丈夫なサーバーサイドならばJavaScriptでも大丈夫 579 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 14:19:04.42 ID:DJgy/fWm0.net] 漏れは、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 580 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 14:28:18.18 ID:a802uHDS0.net] 実に香ばしい 581 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 14:30:48.17 ID:DQrIwGMYM.net] こういう書き込みをしてKENTAとかいうやつの評判を下げてる人です 582 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 14:46:23.75 ID:qZK8tQUSa.net] バックエンドではTypeScriptは意図的に避けてる エコシステムの変化が激しすぎるのと標準ライブラリの貧弱さが使用に耐えない OSS文化は悪くないけど基本的な機能すらコミュニティ依存っていう無責任な方針はよくない 今後数年から数十年に渡って自分達のプロダクトと共存していくことになるパートナーとして信用できない 583 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 14:49:42.10 ID:qZK8tQUSa.net] 逆に言うとフロントと同じぐらい小さくて寿命が短い使い捨てのバックエンドなら別にTypeScriptでも良いと思う うちはそういうの扱ってないんで選択肢に挙がらないけど 584 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 15:13:42.42 ID:UTxfnI1i0.net] 何するにも非同期とかnodeというかJSは終わってる それはフロントエンドの発想 サーバーサイドは全部同期的に動くのがベスト 同期で動いていかに早くレスポンスを返すかを設計するもの 何やるにもコールバックかPromise連打しなきゃいけなくて地獄 サーバーサイドで非同期は余計なのよ この感覚を理解できない人はサーバーサイドを理解してない 585 名前：570 mailto:sage [2022/05/16(月) 15:29:38.98 ID:DJgy/fWm0.net] KENTA 未経験からのエンジニア転職の必須教養【技術知識編】 https ://www.youtube.com/watch?v=Q1c09rrhTjo 奇をてらって、Laravel, Django を選ぶな。 転職先が多い、Ruby on Rails が有利 AWS EC2 はオワコンだから、Fargate を使えとか、 CircleCI, Github Actions, Terraform, Nuxt.js, Type Script 586 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 15:44:43.87 ID:XfoCH0Ek0.net] >>575 えぇ……サーバサイドでも非同期役立つやん……。仕組みからしてシンプルにスケールさせやすいし、DBの返答待つ間にできる処理回すとかもお手の物。 Promiseやawaitある現代JSでは非同期は簡単に扱えるし、Rustのactix-webとかも非同期だよ？ 587 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 15:45:18.25 ID:a802uHDS0.net] なるほど、非同期に苦手意識があるのかな 588 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 15:47:16.27 ID:AoVbevXWM.net] 非同期は必須 589 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 15:49:03.92 ID:IoIRdAU7M.net] >>575 それは真逆 サーバーサイドは同期的にならない 様々なマイクロサーバー待ち、データベースサーバー待ち、ローカルファイルシステム待ち、など、これらを一つ一つ同期的に待つのは無駄だから非同期で並行処理させる 590 名前：デフォルトの名無しさん (ｽﾌﾟｯｯ Sddb-nHzh) mailto:sage [2022/05/16(月) 16:42:00 ID:6UuQWNeTd.net] >>575 TPモニタですら非同期のAPI提供してきたのに… 591 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 17:01:53.01 ID:UTxfnI1i0.net] >>576 それあなたの環境だけですよね？ 592 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 17:05:06.95 ID:UTxfnI1i0.net] >>580 だからそれがダメなんだって そもそもそんな重い処理をしてる時点で論外 593 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 17:21:30.33 ID:iHhbmbyAd.net] ビックデータどうすんの 594 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 17:23:54.78 ID:DQrIwGMYM.net] 同時接続数が100なのか万単位なのかで全然話が違う 595 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 18:19:39.14 ID:i5j4+7lIM.net] この手の話は具体的なケースを想定するなりして前提を合わせないと話が噛み合わなくて時間の無駄 596 名前：デフォルトの名無しさん mailto:sage [2022/05/16(月) 18:37:05.18 ID:zuDvQ8ve0.net] >>583 >>580に対して「重い処理」なんて単語が出てくるようじゃ会話が噛み合わないわな。 本当にサーバーやってたのかすら疑わしい。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef