こっちの方が実感に近い。スタートアップ初期・プロトタイプ・社内や細々としたツール類、みたいなの以外で推す人には近寄りたくない
型安全なエラーハンドリングが言語仕様に無いの辛いよねーーーー！、！！、！！！！
“TypeScriptのつらみ 1. ライブラリが破壊的変更しがち。2. TSもNode.jsもリリース早すぎて長期運用に向かない。3. 枯れたフレームワークがない”
バックエンドは自分はRails一択。使い慣れていて運用経験が長いものが一番。フロントエンドはReact+TypeScriptでいいけども。
この文脈で比較対象としてJavaもKotlinも出てこないんだから、やっぱりJVMの退潮は明らかだなーって思う。C#が出てきてくれないのは慣れてる。
expressは十分枯れてると言っても良さそう。NestJSだけは絶対に選ばない方が良い。
JS/TSのフレームワークでExpressの次くらいに普及してるのはFastify。機能面、普及度申し分ない。Nodejsの中心メンバーが10年開発してて将来性は堅い。SpringっぽいのがNestjs、フロントエンドからジョブチェンジならNextjsかRemix
「色んな言語がある理由」にも一部通じる話
Nodeのv6の時代に作ったバックエンドを何度書き換えたか・依存モジュールに振り回されたか分からない。C#のサービスは安定稼働してるのに。
概ね同意ではあるけど、むしろHono+Drizzleとかでようやく少しいい感じになってきたところなのかなと思う気持ちもあるし、どのくらいエコシステムの問題がきついか次第という印象はある。
型をうまく使いこなす設計が同時にできないとTSは厳しそう。ここで言われてることは一見尤もらしいが、実際は道具を使いこなす技術レベルが足りてないだけという現場のほうが多そうではある
基本的にバックエンドの役割はデータの永続性であり、具体的にはDBのラッパーになっている→APIサーバーの構築ならTypeScript以外にも選択肢がある…というか関数型言語（宣言型言語）を使うべきで、他の選択肢は次点？
バックエンドの難しさというか本質って複雑なビジネスロジックをどうコードに落とすかだと思っており、TypeScriptの型システムの強力さが替えが利かない場面もあると思ってるんだけどそこはあまりという感じなのかな
昨今のWebバックエンド選択は言語というよりもどのフレームワークを選ぶかという話になるので使わない理由というのはあまり意味のない議論かなと
使いやすいreplがないのもデバッグに大変。
参考になる
「npm エコシステムは流動性が非常に高く、依存パッケージも頻繁に更新」「TypeScript や Node.js 本体も頻繁にバージョンアップが行われていますが、これ自体は他の言語でもよくありますし、後方互換性を大事にしている」
案件によるけどJVMはフットプリントが重いので、すぐ立ち上がるミニマルバイナリなGoが好き TypeScriptのようなGoがあると嬉しいのだが（無理）
個人的には大規模開発はJavaかな。Javaのマルチモジュールだと依存関係が厳密に管理できるけどTypeScriptのモノレポはそれが出来ないので
小さいもの、使い捨て、ならいいけど、規模が大きくなると依存ライブラリの問題で避けるよね／JSのエコシステムは他より脆い／まだjs>tsやcjs>esmの過渡期なのが悪い
エコシステムが本当に長期運用に向かない。
もっともだけど、バックエンドもBBaaSやBaaSなどで薄くなってる前提なので、観点がちがうというだけのこと
RESTならHono。GraphQLならyoga。NestJSだけは絶対にやめとけ。しかし作って放置とか言ってるが、アプデのないライブラリ＝安心安全ってロジックはおかしくないか？
バックエンドはjavaかなぁ、って言うとかっこよさそう。最近は、nextjs一択だわ。なのでTSで書いてる。
メリデメ理解して、デメリットが許容できるなら好きなもん使ったらええ
デメリットは言語のコミュニティーの文化だから長期的にもあきらめるしかない。とは言え、PythonかTypeScriptを選べと言われたら断然TypeScript。
自分の仕事だと、バックエンドは数十万人が1年間アクセスし続けても何も問題が起きないようにする必要があり、枯れていて信頼できることが何よりも必要なのでTypeScriptは選びづらい
標準ライブラリが小さいエコシステムは同様の辛みがある
視点がよい
長期運用を考えると、バックエンドでは手を出せない
枯れた言語と安い人材で選ばれる事が多かったけれど、その辺はAIがなんとか出来るから淘汰が進むと論理的に優れてるやつが選ばれそうねえ
TS検討なら型が欲しい前提。GoはWebFWもORMも乱立、発展途上な印象。選定条件をイジってTSを選ばない理由を作ってるだけでは | PythonはNPMどころじゃなくモジュール周りがクソすぎるので絶対ない
全然的外れでは？npmのモジュールバージョンは固定にすればいいし、それは他の言語のバンドラーでも同じだよね。セキュリティ関連のアップデートで更新せざるを得ないタイミングが来るのも同じ。
オーディオプラグインのWebUIもだめかもしれんなあ（開発者もユーザーもまともにアップデートしない）
人材がいないだけだよ。TypeScript食える奴がバックエンド来たがらないでしょ。Next.jsとかバリバリ使われる時代に後ろが出来ないなんてのは無い。
バックエンドの根幹はDBなんだけど、DBってデータに全て型持ってんだよね（整数型、テキスト型、最近だとベクター型やJSON型も）。あと例えばPostgreSQLの全機能使えるORMなんて無いから、最後には生SQL最強に向かってしまう
実態はJavaScriptなので数値がnumberだったりであんまりバックエンドに向いてる感じはしない。作るものによるのではないか。
Spring Boot 一択なんで Java。 Goも好きだが、周りにあんま使える人がいない
TypeScript界隈では流行り廃りが激しく落ち着いて使えないっていう意見よね。TypeScriptという言語自体の問題ではないけど、そういう傾向はあると思う。でもWeb開発技術って多かれ少なかれそうだし、自由に選べば良いと思う
フロントエンドもバックエンドめっちゃ古いやつ使ってるけど、OSバージョンアップ時・言語本体のバージョンアップ時に動かなくなることだけが心配。
時代遅れだとは思うけどバックエンドはできる限り同期的に動いてくれたほうが安心感ある
どうせ流行り廃りがある話、ではあるけど、フロントエンド側の「軽い」文化をそのままバックエンドに持ってくると、運用が破綻する。日頃、アプリのエラーでも「繋がらないんだけど」と言うアプリ屋を見てるので...
業務前提だとなんだかんだでJavaの安定感は強い。枯れてる＆充実の標準ライブラリ＆外部ライブラリはSpringを入れればだいたいどうにかなるってのは強い。Rustやnodeで書こうぜ！とか言い出す勇気はないな。責任取れん。
TypeScriptバリバリ書ける人でバックエンドやりたいって人があんまりいないことが一番の理由になるんじゃないかな。フロントより責任重いからやらなくていいならやりたくないし
Node.js(というかJavascriptそのものが素人)はお遊び程度でしか使ってないけどPromiseで本当にやりたいこと全部出来るもんなの。
そもそも「バックエンドは変更頻度が低い」という前提自体が、TSをバックエンドに採用してるプロダクトとは異なってると思うので、話が噛み合ってないかも？
大規模システムのバックエンドでTypeScriptはやめておけ、絶対途中で辛くなる、とガンダムが言っている。
TypeScriptをバックエンドで使わない理由
こっちの方が実感に近い。スタートアップ初期・プロトタイプ・社内や細々としたツール類、みたいなの以外で推す人には近寄りたくない
型安全なエラーハンドリングが言語仕様に無いの辛いよねーーーー！、！！、！！！！
“TypeScriptのつらみ 1. ライブラリが破壊的変更しがち。2. TSもNode.jsもリリース早すぎて長期運用に向かない。3. 枯れたフレームワークがない”
バックエンドは自分はRails一択。使い慣れていて運用経験が長いものが一番。フロントエンドはReact+TypeScriptでいいけども。
この文脈で比較対象としてJavaもKotlinも出てこないんだから、やっぱりJVMの退潮は明らかだなーって思う。C#が出てきてくれないのは慣れてる。
expressは十分枯れてると言っても良さそう。NestJSだけは絶対に選ばない方が良い。
JS/TSのフレームワークでExpressの次くらいに普及してるのはFastify。機能面、普及度申し分ない。Nodejsの中心メンバーが10年開発してて将来性は堅い。SpringっぽいのがNestjs、フロントエンドからジョブチェンジならNextjsかRemix
「色んな言語がある理由」にも一部通じる話
Nodeのv6の時代に作ったバックエンドを何度書き換えたか・依存モジュールに振り回されたか分からない。C#のサービスは安定稼働してるのに。
概ね同意ではあるけど、むしろHono+Drizzleとかでようやく少しいい感じになってきたところなのかなと思う気持ちもあるし、どのくらいエコシステムの問題がきついか次第という印象はある。
型をうまく使いこなす設計が同時にできないとTSは厳しそう。ここで言われてることは一見尤もらしいが、実際は道具を使いこなす技術レベルが足りてないだけという現場のほうが多そうではある
基本的にバックエンドの役割はデータの永続性であり、具体的にはDBのラッパーになっている→APIサーバーの構築ならTypeScript以外にも選択肢がある…というか関数型言語（宣言型言語）を使うべきで、他の選択肢は次点？
バックエンドの難しさというか本質って複雑なビジネスロジックをどうコードに落とすかだと思っており、TypeScriptの型システムの強力さが替えが利かない場面もあると思ってるんだけどそこはあまりという感じなのかな
昨今のWebバックエンド選択は言語というよりもどのフレームワークを選ぶかという話になるので使わない理由というのはあまり意味のない議論かなと
使いやすいreplがないのもデバッグに大変。
参考になる
「npm エコシステムは流動性が非常に高く、依存パッケージも頻繁に更新」「TypeScript や Node.js 本体も頻繁にバージョンアップが行われていますが、これ自体は他の言語でもよくありますし、後方互換性を大事にしている」
案件によるけどJVMはフットプリントが重いので、すぐ立ち上がるミニマルバイナリなGoが好き TypeScriptのようなGoがあると嬉しいのだが（無理）
個人的には大規模開発はJavaかな。Javaのマルチモジュールだと依存関係が厳密に管理できるけどTypeScriptのモノレポはそれが出来ないので
小さいもの、使い捨て、ならいいけど、規模が大きくなると依存ライブラリの問題で避けるよね／JSのエコシステムは他より脆い／まだjs>tsやcjs>esmの過渡期なのが悪い
エコシステムが本当に長期運用に向かない。
もっともだけど、バックエンドもBBaaSやBaaSなどで薄くなってる前提なので、観点がちがうというだけのこと
RESTならHono。GraphQLならyoga。NestJSだけは絶対にやめとけ。しかし作って放置とか言ってるが、アプデのないライブラリ＝安心安全ってロジックはおかしくないか？
バックエンドはjavaかなぁ、って言うとかっこよさそう。最近は、nextjs一択だわ。なのでTSで書いてる。
メリデメ理解して、デメリットが許容できるなら好きなもん使ったらええ
デメリットは言語のコミュニティーの文化だから長期的にもあきらめるしかない。とは言え、PythonかTypeScriptを選べと言われたら断然TypeScript。
自分の仕事だと、バックエンドは数十万人が1年間アクセスし続けても何も問題が起きないようにする必要があり、枯れていて信頼できることが何よりも必要なのでTypeScriptは選びづらい
標準ライブラリが小さいエコシステムは同様の辛みがある
視点がよい
長期運用を考えると、バックエンドでは手を出せない
枯れた言語と安い人材で選ばれる事が多かったけれど、その辺はAIがなんとか出来るから淘汰が進むと論理的に優れてるやつが選ばれそうねえ
TS検討なら型が欲しい前提。GoはWebFWもORMも乱立、発展途上な印象。選定条件をイジってTSを選ばない理由を作ってるだけでは | PythonはNPMどころじゃなくモジュール周りがクソすぎるので絶対ない
全然的外れでは？npmのモジュールバージョンは固定にすればいいし、それは他の言語のバンドラーでも同じだよね。セキュリティ関連のアップデートで更新せざるを得ないタイミングが来るのも同じ。
オーディオプラグインのWebUIもだめかもしれんなあ（開発者もユーザーもまともにアップデートしない）
人材がいないだけだよ。TypeScript食える奴がバックエンド来たがらないでしょ。Next.jsとかバリバリ使われる時代に後ろが出来ないなんてのは無い。
バックエンドの根幹はDBなんだけど、DBってデータに全て型持ってんだよね（整数型、テキスト型、最近だとベクター型やJSON型も）。あと例えばPostgreSQLの全機能使えるORMなんて無いから、最後には生SQL最強に向かってしまう
実態はJavaScriptなので数値がnumberだったりであんまりバックエンドに向いてる感じはしない。作るものによるのではないか。
Spring Boot 一択なんで Java。 Goも好きだが、周りにあんま使える人がいない
TypeScript界隈では流行り廃りが激しく落ち着いて使えないっていう意見よね。TypeScriptという言語自体の問題ではないけど、そういう傾向はあると思う。でもWeb開発技術って多かれ少なかれそうだし、自由に選べば良いと思う
フロントエンドもバックエンドめっちゃ古いやつ使ってるけど、OSバージョンアップ時・言語本体のバージョンアップ時に動かなくなることだけが心配。
時代遅れだとは思うけどバックエンドはできる限り同期的に動いてくれたほうが安心感ある
どうせ流行り廃りがある話、ではあるけど、フロントエンド側の「軽い」文化をそのままバックエンドに持ってくると、運用が破綻する。日頃、アプリのエラーでも「繋がらないんだけど」と言うアプリ屋を見てるので...
業務前提だとなんだかんだでJavaの安定感は強い。枯れてる＆充実の標準ライブラリ＆外部ライブラリはSpringを入れればだいたいどうにかなるってのは強い。Rustやnodeで書こうぜ！とか言い出す勇気はないな。責任取れん。
TypeScriptバリバリ書ける人でバックエンドやりたいって人があんまりいないことが一番の理由になるんじゃないかな。フロントより責任重いからやらなくていいならやりたくないし
Node.js(というかJavascriptそのものが素人)はお遊び程度でしか使ってないけどPromiseで本当にやりたいこと全部出来るもんなの。
そもそも「バックエンドは変更頻度が低い」という前提自体が、TSをバックエンドに採用してるプロダクトとは異なってると思うので、話が噛み合ってないかも？
大規模システムのバックエンドでTypeScriptはやめておけ、絶対途中で辛くなる、とガンダムが言っている。