The TypeScript Tax
My experience with TS is totally on the backend.<p>The biggest issue with typescript, and the reason I&#x27;ll probably never reach for it for another large project despite having used it for a 50k line+ project, is that it&#x27;s still, at its core, javascript. We&#x27;ve experienced a tremendous amount of pain because of this.<p>- We&#x27;ve needed libraries which don&#x27;t provide typescript typings. Like a good little typescript user, we have strict mode enabled, which means we have to build our own typings when we encounter this. We&#x27;ve had library maintainers reject our typings we provide back to the community. We&#x27;ve had library maintainers say they have no desire to provide any support to typescript users because &quot;its a fad&quot; and &quot;ts is just js, you don&#x27;t need types, live with it&quot; (not joking, not exaggerating).<p>- All of the good high-level JS frameworks and architectural libraries are built for, well, JS. So, you want to adapt them for TS, but the JS idioms are <i>so core</i> to their design that you throw away any benefit TS gives you. Express is a good example; you might have middleware which parses a bearer token and attaches it to the request. When the request hits the next middleware or request handler, its just a normal request. There&#x27;s no way to assert at compile time that &quot;this middleware came before, the request is now a new type with this extra field&quot;. Express, Apollo, the list goes on.<p>- Further, the community around creating Typescript-native libraries is exceedingly small and, as far as I can tell, dying. I&#x27;m talking libraries that are made for typescript and make use of the true end-to-end compile-time verification typescript gives you. TypeStack is probably the leading organization (on GitHub) which builds (amazing!) projects like this, and their velocity is slowing down. TypeDI hasn&#x27;t seen an update in nine months. Vesper was an incredible web framework that hasn&#x27;t been touched in a while. There&#x27;s nothing available for MongoDB if you use that. Basically, you&#x27;re stuck with JS native projects 90% of the time, and about 10% of those don&#x27;t have typings available.<p>- We&#x27;ve had NPM libraries redefine the Error global. This isn&#x27;t caught at compile-time, obviously, and totally borked the error responses our API sends.<p>- It&#x27;s a constant uphill battle with the `as` keyword. I wish there was a way to easily ban it globally. You can essentially assert Anything As Anything, and if its not caught in review you&#x27;ll end up with incredibly hard to trace behavior because &quot;the compiler says this field should be there, why am I getting undefined&quot;... well, its because sixteen layers down someone asserted a type without verifying its accuracy at runtime, and in 5% of situations its incorrect, and it missed review.<p>- It&#x27;s a constant uphill battle with lodash. We have developers on some teams that swear by it, and will scatter `_.get`s all over the codebase, then be startled when things break in unexpected ways. Typescript added the `!` operator, which is basically just an escape hatch, and it took us a long time to get everyone educated that this is, without a doubt, the dumbest thing Microsoft has added to the language because it doesn&#x27;t actually do anything at runtime, it just suppresses a potentially useful compiler error.<p>In summary, don&#x27;t pick Typescript for the backend. It&#x27;s an obvious improvement over JS, but you&#x27;ll still be left wishing you hadn&#x27;t.<p>But I also don&#x27;t know what the better option is for a high-velocity organization. Go and Rust are too unproductive. Ruby and Python aren&#x27;t performant and aren&#x27;t strongly typed. JVM languages are a pain. Elixir shows a lot of promise but the lack of typing concerns me.