typescript 后端選型：

Express &Typescript &trpc 廣泛使用，靈活，快速，穩定
Nestjs 企業級，標準化，像java ，依賴注入，
Hono , web standards framework. Support for any JavaScript runtime.

---

思考：

最近我和幾個用Go和Java/Kotlin寫后端的開發者聊過。他們說TypeScript差遠了，Go和Java/Kotlin才是真正的現代后端語言。但是當我問到具體原因時，他們卻很難說出什么具體的來。他們聲稱，例如，這些語言的工具比TypeScript要好。

我過去在前端編程（React）中大量使用過TypeScript，并沒有用它做過很多后端開發。但我認為TypeScript 是一門強大的語言，它非常靈活，而且有類型系統。我對后端工具不太熟悉，所以他們在這點上可能是對的。

但是當涉及到微服務時，我看不出使用Go/Kotlin比TypeScript有什么優勢。你只需要用一個Docker容器，做一個Express的endpoint，就完事了。

另外，我認為在后端使用TypeScript的優勢在于，你可以用同一種語言做前后端，這對小型公司/初創公司特別有用，因為它們通常擁有更多全棧開發者，而不是嚴格區分前后端開發者。

---

TypeScript本身比前端更適合后端領域，因為你的類型更多的是圍繞領域邏輯而不是DOM。所以從這個意義上說，它真的很好。

很多人吹捧Go，我在一些大量使用Go的地方工作過，但我個人始終無法接受它在美學上的丑陋。我幾乎在各個方面都更喜歡Rust。

這里有很多關于性能的討論，但是取決于你的領域，你可能不會注意到區別。如果你使用的是現代基礎設施，例如無服務器架構，那么TypeScript在很多用例中實際上性能更好——例如HTTP API。如果你受限于更傳統的選項，例如Docker，那么TypeScript可能不是最佳選擇。

如果你已經熟練掌握了TS和TS工具，那么在后端使用它完全沒問題。但我個人討厭Express和其他Node生態系統的框架，所以我需要補充一點，如果我不能使用Lambda/無服務器生態系統，我會避免使用TS。

TS比Java/C#最大的優勢在于它默認情況下不是面向對象的語言。當然，你可以將TS與OOP一起使用，但是能夠自由地編寫操作數據的自由函數非常令人解放。我不再想把所有東西都塞進一個類里了。

還有其他優點。例如，我們運行微服務和微前端。對于使用全棧TypeScript的團隊來說，這意味著他們的服務可以是一個小型單體倉庫，其后端和前端在同一個倉庫中共享API契約類型。我想，那些在后端使用C#的團隊必須做其他事情，例如契約測試。

然后還有測試框架、ESLint、IDE配置等等。能夠停留在相同的工具集中是很好的。

老實說，對于任何需要企業級規模并需要能夠快速構建和維護的項目，TS都是我的后端默認選項。但如果我做的是計算密集型的工作，我會選擇Rust——這幾乎總是后臺作業，所以我的API幾乎總是用TS。

---

是的！在無服務器環境中使用 TS 太棒了，fp-ts TaskEither 真的非常適合那些可能以奇奇怪怪的方式失敗的異步 API。

---

對我來說，關鍵在于編譯時間和運行時間。我們必須記住，JS嚴格來說不是強類型語言，所以在你的程序編譯掉那些類型之后，如果出現問題，你該怎么辦？我更傾向于對后端密集型的東西，比如支付系統，使用強類型語言。
對我來說，另一個重要的事情是企業級應用的包，特別是像支付系統這樣高風險的東西。我更喜歡那些內置庫更多，而且經過多年驗證的庫，而不是一些JS開源庫。尤其是在考慮安全性的情況下。JS的依賴性簡直是地獄。