There are alternatives to NPM, and high performance build tools. A lot of code-quality tools like linting are on the slower side though.
Ultimately people use TS on the back end because they want to simplify hiring and reduce context switching loss in developers mostly, and in some cases because their application is isomorphic. This choice works well when the ratio of front end to back end code is high (which is the case for most shops), since these benefits outweigh the downsides of developing services in Typescript compared to go (I wouldn't write most services in rust...).
> Ultimately people use TS on the back end because they want to simplify hiring and reduce context switching loss in developers mostly
In my experience this hasn’t panned out particularly well, but I believe it works for some teams.
> because their application is isomorphic
This is one case where it had worked out okay for me. The scope has tended to be relatively limited and there was a framework in place which was generally good at gluing things together and ensuring people work along the same rails.
> I wouldn’t write most services in rust…
No, me either. I tend to teach for Go for web services these days, but I do like rust for CLIs and situations where optimizations are crucial. Admittedly I don’t even like Go as a language that much, but it’s great at what it does if I’m willing to put my head down, deal with the quirks and verbosity, and crank something out. It’s not a language of cleverness or elegance, but the results tend to be excellent and easy to maintain.
Ultimately people use TS on the back end because they want to simplify hiring and reduce context switching loss in developers mostly, and in some cases because their application is isomorphic. This choice works well when the ratio of front end to back end code is high (which is the case for most shops), since these benefits outweigh the downsides of developing services in Typescript compared to go (I wouldn't write most services in rust...).