Is TypeScript the only language your company needs?
The quest for a single language
While it’s immediately appealing to be able to re-use data models and move business logic between client and server without onerous code-generation or translation steps, the justifications for efforts to use a single language for the whole stack largely come from organizational benefits to planning, training, hiring, and tooling.
Many articles in the agile world celebrate T-shaped skills (deep specialization, the leg of the T, complemented with broad ability to help out in adjacent areas) and many companies want to hire full-stack developers. While a developer that specializes in browser behaviors is unlikely to keep up with all the latest techniques for database performance, cross-functional benefits can still be had if developers work in a single language throughout the stack.
Web services are going asynchronous
Meanwhile Java, which has long been the dominant enterprise language unified around its servlet framework, is fragmenting its ecosystem as it moves into the asynchronous world. Java developers have to choose between numerous reactive solutions and even if they pick the winner, the code bases risk becoming obsolete unergonomic chains of lambda functions in a few years as the language finalizes support for and adopts fibers/goroutines.
Enterprise frameworks for TypeScript are maturing
Frameworks like TypeORM and NestJS were written with types from the start and provide constructs such as dependency-injection and database repositories that are familiar to developers with experience from Java frameworks like Spring and Hibernate.
The adoption of serverless and containers
As enterprises adopt serverless programming models like AWS Lambda and Google Cloud Functions, or deploy into container clusters that allow easy horizontal scaling, like Kubernetes, programming languages with rich concurrency constructs have less advantage over runtimes like NodeJS.
When is TypeScript a poor fit?
Disruption theory from The Innovator’s Dilemma tells us it’s natural for “toys” to mature and cover the most common uses in a market, while “serious” products move to serve increasingly specialized niche uses. Just like companies starting with databases today are unlikely to choose Oracle’s enterprise solution over alternatives considered toys a few decades ago like MySQL or Postgres, it might be worth evaluating if the language you will need to use for your front-end can now also serve the needs of your back-end.
Node as a runtime also leaves some doubts, but it should be a no-brainer to include among options for startups or small businesses that consider Ruby or PHP. Having recently surveyed the enterprise landscape as part of helping build a web application security SaaS, it’s also clear that both Node and even TypeScript on the JVM are seeing adoption in the enterprise (even though the Java and dotNet are still the dominant players).
For more programming language inspiration, see my earlier study on why Rust worked out well as an alternative to C/C++ for a native shared library https://www.tcell.io/2017/06/agents-rust/