[フレーム]
はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

気に入った記事をブックマーク

  • 気に入った記事を保存できます
    保存した記事の一覧は、はてなブックマークで確認・編集ができます
  • 記事を読んだ感想やメモを書き残せます
  • 非公開でブックマークすることもできます
適切な情報に変更

エントリーの編集

loading...

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

タイトルガイドライン

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます
コメントを非表示にできます コメント表示の設定

ブックマークしました

ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

246users がブックマーク コメント 45

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

TypeScriptをバックエンドで使わない理由

246 users zenn.dev/putcho

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

はてなブックマーク

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント45件

  • 注目コメント
  • 新着コメント
knjname
案件によるけどJVMはフットプリントが重いので、すぐ立ち上がるミニマルバイナリなGoが好き TypeScriptのようなGoがあると嬉しいのだが(無理)

その他
hirokinko
expressは十分枯れてると言っても良さそう。NestJSだけは絶対に選ばない方が良い。

その他
twotiger
JS/TSのフレームワークでExpressの次くらいに普及してるのはFastify。機能面、普及度申し分ない。Nodejsの中心メンバーが10年開発してて将来性は堅い。SpringっぽいのがNestjs、フロントエンドからジョブチェンジならNextjsかRemix

その他
yamadadadada2
型をうまく使いこなす設計が同時にできないとTSは厳しそう。ここで言われてることは一見尤もらしいが、実際は道具を使いこなす技術レベルが足りてないだけという現場のほうが多そうではある

その他
strawberryhunter
デメリットは言語のコミュニティーの文化だから長期的にもあきらめるしかない。とは言え、PythonかTypeScriptを選べと言われたら断然TypeScript。

その他
qnq777
標準ライブラリが小さいエコシステムは同様の辛みがある

その他
mingos
バックエンドは自分はRails一択。使い慣れていて運用経験が長いものが一番。フロントエンドはReact+TypeScriptでいいけども。

その他
hasiduki
型安全なエラーハンドリングが言語仕様に無いの辛いよねーーーー!、!!、!!!!

その他
hylom
昨今のWebバックエンド選択は言語というよりもどのフレームワークを選ぶかという話になるので使わない理由というのはあまり意味のない議論かなと

その他
flytales
実態はJavaScriptなので数値がnumberだったりであんまりバックエンドに向いてる感じはしない。作るものによるのではないか。

その他
tamanecoplus
大規模システムのバックエンドでTypeScriptはやめておけ、絶対途中で辛くなる、とガンダムが言っている。

その他
noonworks
そもそも「バックエンドは変更頻度が低い」という前提自体が、TSをバックエンドに採用してるプロダクトとは異なってると思うので、話が噛み合ってないかも?

その他
satomi_hanten
Node.js(というかJavascriptそのものが素人)はお遊び程度でしか使ってないけどPromiseで本当にやりたいこと全部出来るもんなの。

その他
fikah
TypeScriptバリバリ書ける人でバックエンドやりたいって人があんまりいないことが一番の理由になるんじゃないかな。フロントより責任重いからやらなくていいならやりたくないし

その他
JULY
どうせ流行り廃りがある話、ではあるけど、フロントエンド側の「軽い」文化をそのままバックエンドに持ってくると、運用が破綻する。日頃、アプリのエラーでも「繋がらないんだけど」と言うアプリ屋を見てるので...

その他
hogeaegxa
業務前提だとなんだかんだでJavaの安定感は強い。枯れてる&充実の標準ライブラリ&外部ライブラリはSpringを入れればだいたいどうにかなるってのは強い。Rustやnodeで書こうぜ!とか言い出す勇気はないな。責任取れん。

その他
w1234567
時代遅れだとは思うけどバックエンドはできる限り同期的に動いてくれたほうが安心感ある

その他
n314
フロントエンドもバックエンドめっちゃ古いやつ使ってるけど、OSバージョンアップ時・言語本体のバージョンアップ時に動かなくなることだけが心配。

その他
mollifier
TypeScript界隈では流行り廃りが激しく落ち着いて使えないっていう意見よね。TypeScriptという言語自体の問題ではないけど、そういう傾向はあると思う。でもWeb開発技術って多かれ少なかれそうだし、自由に選べば良いと思う

その他
tmurakam
Spring Boot 一択なんで Java。 Goも好きだが、周りにあんま使える人がいない

その他
flytales
flytales 実態はJavaScriptなので数値がnumberだったりであんまりバックエンドに向いてる感じはしない。作るものによるのではないか。

2025年05月28日 リンク

その他
circled
バックエンドの根幹はDBなんだけど、DBってデータに全て型持ってんだよね(整数型、テキスト型、最近だとベクター型やJSON型も)。あと例えばPostgreSQLの全機能使えるORMなんて無いから、最後には生SQL最強に向かってしまう

その他
nemoba
人材がいないだけだよ。TypeScript食える奴がバックエンド来たがらないでしょ。Next.jsとかバリバリ使われる時代に後ろが出来ないなんてのは無い。

その他
atsushieno
オーディオプラグインのWebUIもだめかもしれんなあ(開発者もユーザーもまともにアップデートしない)

その他
tettekete37564
全然的外れでは?npmのモジュールバージョンは固定にすればいいし、それは他の言語のバンドラーでも同じだよね。セキュリティ関連のアップデートで更新せざるを得ないタイミングが来るのも同じ。

その他
tacamula
TS検討なら型が欲しい前提。GoはWebFWもORMも乱立、発展途上な印象。選定条件をイジってTSを選ばない理由を作ってるだけでは | PythonはNPMどころじゃなくモジュール周りがクソすぎるので絶対ない

その他
letsspeak
枯れた言語と安い人材で選ばれる事が多かったけれど、その辺はAIがなんとか出来るから淘汰が進むと論理的に優れてるやつが選ばれそうねえ

その他
masatotoro
長期運用を考えると、バックエンドでは手を出せない

その他
soybeancucumber
視点がよい

その他
qnq777
qnq777 標準ライブラリが小さいエコシステムは同様の辛みがある

2025年05月28日 リンク

その他
twainy
自分の仕事だと、バックエンドは数十万人が1年間アクセスし続けても何も問題が起きないようにする必要があり、枯れていて信頼できることが何よりも必要なのでTypeScriptは選びづらい

その他
strawberryhunter
strawberryhunter デメリットは言語のコミュニティーの文化だから長期的にもあきらめるしかない。とは言え、PythonかTypeScriptを選べと言われたら断然TypeScript。

2025年05月28日 リンク

その他
seal2501
メリデメ理解して、デメリットが許容できるなら好きなもん使ったらええ

その他
cloverstudioceo
バックエンドはjavaかなぁ、って言うとかっこよさそう。最近は、nextjs一択だわ。なのでTSで書いてる。

その他
uehaj
もっともだけど、バックエンドもBBaaSやBaaSなどで薄くなってる前提なので、観点がちがうというだけのこと

その他
System
エコシステムが本当に長期運用に向かない。

その他
nojimage
小さいもの、使い捨て、ならいいけど、規模が大きくなると依存ライブラリの問題で避けるよね/JSのエコシステムは他より脆い/まだjs>tsやcjs>esmの過渡期なのが悪い

その他
prograti
個人的には大規模開発はJavaかな。Javaのマルチモジュールだと依存関係が厳密に管理できるけどTypeScriptのモノレポはそれが出来ないので

その他
knjname
knjname 案件によるけどJVMはフットプリントが重いので、すぐ立ち上がるミニマルバイナリなGoが好き TypeScriptのようなGoがあると嬉しいのだが(無理)

2025年05月28日 リンク

その他
nilab
「npm エコシステムは流動性が非常に高く、依存パッケージも頻繁に更新」「TypeScript や Node.js 本体も頻繁にバージョンアップが行われていますが、これ自体は他の言語でもよくありますし、後方互換性を大事にしている」

その他

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー
アプリのスクリーンショット
いまの話題をアプリでチェック!
  • バナー広告なし
  • ミュート機能あり
  • ダークモード搭載
アプリをダウンロード

関連記事

usersに達しました!

さんが1番目にブックマークした記事「TypeScriptをバッ...」が注目されています。

気持ちをシェアしよう

ツイートする

TypeScriptをバックエンドで使わない理由

この記事は、下記の記事への反論というよりも、「 TypeScript でバックエンドを書く」というテーマにつ... この記事は、下記の記事への反論というよりも、「 TypeScript でバックエンドを書く」というテーマについて、別の観点から整理したい という意図で書いています。 元記事は、文脈が分かりづらいと感じたため、自分なりにバックエンドの特性にフォーカスして再整理しています。 最近、以下の記事を見かけました。 記事の内容は、バックエンドも TypeScript で書きましょうという内容です。 たしかに、TypeScript は現代のフロントエンド開発においてデファクトスタンダードとも言えます。型安全性、補完の効きやすさ、そしてJavaScriptとの互換性。いずれも実務で使うには非常に便利です。フロントエンドではもはや必須とも言える存在です。 ただ、バックエンドという文脈においては、TypeScriptを選ばない理由もあるよね? と感じました。 TypeScript を否定したい訳ではなく、「あ

ブックマークしたユーザー

  • techtech05212025年09月12日 techtech0521
  • heatman2025年06月26日 heatman
  • knj29182025年06月12日 knj2918
  • stntaku2025年06月01日 stntaku
  • yutaubi2025年05月30日 yutaubi
  • phoope2025年05月29日 phoope
  • wkubota2025年05月29日 wkubota
  • hush_in2025年05月29日 hush_in
  • tamanecoplus2025年05月28日 tamanecoplus
  • tuki09182025年05月28日 tuki0918
  • ozkey2025年05月28日 ozkey
  • noonworks2025年05月28日 noonworks
  • invogue-isogai2025年05月28日 invogue-isogai
  • kayamak2025年05月28日 kayamak
  • breitengrad2025年05月28日 breitengrad
  • zetta19852025年05月28日 zetta1985
  • MzdA0w73tg2025年05月28日 MzdA0w73tg
  • satomi_hanten2025年05月28日 satomi_hanten
すべてのユーザーの
詳細を表示します

ブックマークしたすべてのユーザー

同じサイトの新着

同じサイトの新着をもっと読む

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

同時期にブックマークされた記事

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しましたx

AltStyle によって変換されたページ (->オリジナル) /