Having worked on large backend codebases in both TS and JS, the difference is stark. The TS API in my case had something like 90% less errors, and those were all subtle bugs in business logic.
On the other hand, the large JS API over time had all sorts of unexpected type errors and undefined behavior. I'm aware that this is anecdotal evidence, but TS is pretty much a no-brainer now on backend.
Is it not a problem in practice when TS type declarations and their associated JS code are written by different people at different times for different versions of a library?
I have no experience with maintaining TS projects over a longer period of time, but I have started some experimental TS projects where I was looking for type declarations.
What I found didn't seem to have any formal reference to a specific version of the library. I found that a bit scary. Not sure if it actually causes problems though.
Not caused us any yet over 3 years. You've got to think of it as the opposite, when we find a missing method because we at some point updated a library, we update the ts definition.
So it's not that it's a source of errors as most libraries are backwards compatible.
> Is it not a problem in practice when TS type declarations and their associated JS code are written by different people at different times for different versions of a library?
It can be. But most popular libraries have very good version syncing, or even include definitions in the module itself. In the worst case, or if there are no typings available at all, you can just import the plain js, and use it untyped, which can be acceptable if it is not used in a lot of places.
> didn't seem to have any formal reference to a specific version
Yeah. It mostly works if you install the latest version of them both at the same time. Sometimes I've had to fiddle with backing the definition or the module back a version to get them to match.
> The TS API in my case had something like 90% less errors
That sounds like a red flag to me. I hardly have any type related bugs in my pure JS server code. Must be a poor developer in the team. Too easy to blame JS for that.
That's the great thing about Type systems. It doesn't matter if the development team is amazing or not. Typescript still makes huge classes of errors impossible. It also speeds up development due to superior IDE support.
I've only used TS on the frontend, but I had the same opinion as you until I dug into a couple of TS projects. I don't know if I've ever caused a JS production bug that was a type error at its core, but I've had plenty of bugs like that in development. TS lets me cut out those little dev cycles where I'll write some code, rebuild the app, then see an obvious error in the JS console when I run the app. That adds up to a lot of wasted time over a week of coding. Smart autocomplete and smart variable renaming is also really nice, and I have way more confidence refactoring a TS project than a JS one. I think using TS does result in fewer production bugs, but the big win for me has been having fewer development bugs.
Types are good for more than just "int instead of string". What you consider a type related error is likely not the full set of errors a type system can prevent.
Aside from the other responses you are getting, consider that the "90% less errors" doesn't actually tell you anything about the overall quality of either codebase. It could be a million lines of JS/TS with 10 errors found in the JS vs 1 in the TS. That would be a 90% reduction, but 10 errors in a large codebase would still be pretty excellent.
Having worked on large backend codebases in both TS and JS, the difference is stark. The TS API in my case had something like 90% less errors, and those were all subtle bugs in business logic.
On the other hand, the large JS API over time had all sorts of unexpected type errors and undefined behavior. I'm aware that this is anecdotal evidence, but TS is pretty much a no-brainer now on backend.