I love TypeScript in the right places, but I think it’s often used for things where other tools would be a much better fit.
On the backend it can be nice if you’ve got a monorepo including the front ends it supports. Maybe you’ve got graphql happening and you can share types. That seems great sometimes, and there are cases where it’s super handy and efficient.
I don’t know for sure, but it doesn’t seem worth it after a certain point. I’d much rather keep typescript to the front end where I find it really shines. I’ve worked on a lot of projects where it was full stack typescript and there were always these common, nagging, very typescript-and-JavaScript-specific problems.
Fundamentally the build and development tool chains in general tend to be awful. I can accept it on the front end out of necessity, but on the back end it gets egregious quickly unless you’re using micro services and builds stay quick by default.
Any time I work on something statically typed with nice tooling I realize how much better life can be. It feels like the minor gains I get from fullstack TS are quickly negated by the plethora of advantages to using something like Go or Rust where I can purpose-build applications with absolutely crazy performance, reliability, and portability.
So, TS in the browser is awesome. I think you’d be crazy not to. On the backend on the other hand — unless you’ve got like a perfect fit for using something like Next.js or a static site generator where the backend can be dead simple, I’m pretty tired of dealing with its deficiencies.
And even then it’s not the language so much as the cruft built up in tooling over the years. It’s slow and awkward. NPM is plain old awful. Basics like linting are painfully slow. Testing libraries feel like a house of cards. And so on.
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.
On the backend it can be nice if you’ve got a monorepo including the front ends it supports. Maybe you’ve got graphql happening and you can share types. That seems great sometimes, and there are cases where it’s super handy and efficient.
I don’t know for sure, but it doesn’t seem worth it after a certain point. I’d much rather keep typescript to the front end where I find it really shines. I’ve worked on a lot of projects where it was full stack typescript and there were always these common, nagging, very typescript-and-JavaScript-specific problems.
Fundamentally the build and development tool chains in general tend to be awful. I can accept it on the front end out of necessity, but on the back end it gets egregious quickly unless you’re using micro services and builds stay quick by default.
Any time I work on something statically typed with nice tooling I realize how much better life can be. It feels like the minor gains I get from fullstack TS are quickly negated by the plethora of advantages to using something like Go or Rust where I can purpose-build applications with absolutely crazy performance, reliability, and portability.
So, TS in the browser is awesome. I think you’d be crazy not to. On the backend on the other hand — unless you’ve got like a perfect fit for using something like Next.js or a static site generator where the backend can be dead simple, I’m pretty tired of dealing with its deficiencies.
And even then it’s not the language so much as the cruft built up in tooling over the years. It’s slow and awkward. NPM is plain old awful. Basics like linting are painfully slow. Testing libraries feel like a house of cards. And so on.