7 ms·

I've found typescript an invaluable tool. Having worked on large backend codebases in both TS and JS, the difference is stark. The TS API in my case had someth

by chmln 9y ago

I've found typescript an invaluable tool. 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.

fauigerzigerk 9y ago
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.
- deleted 9y ago
  [deleted]
- mattmanser 9y ago
  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.
- geon 9y ago
  > 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.
grsblk 9y ago
> 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.
- crucialfelix 9y ago
  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.
- pure 9y ago
  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.
- always_good 9y ago
  Tests are also a red flag for the same reason. Just suck less, I always say!
- KirinDave 9y ago
  If Typescript can deliver 90% less errors with the same team, saying "Must be a bad developer" is a useless comment. If TypeScript let's that developer make good code, then the variable is JavaScript.
- jordwest 9y ago
  A great carpenter can hammer a nail with a screwdriver, but that doesn't mean it's a good idea. When the tools help you, a good developer can focus on making better things rather than not making mistakes.

by chmln 9y ago

fauigerzigerk 9y ago

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.

deleted 9y ago
[deleted]
mattmanser 9y ago
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.
geon 9y ago
> 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.

grsblk 9y ago

> 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.

crucialfelix 9y ago
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.
pure 9y ago
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.
always_good 9y ago
Tests are also a red flag for the same reason. Just suck less, I always say!
KirinDave 9y ago
If Typescript can deliver 90% less errors with the same team, saying "Must be a bad developer" is a useless comment. If TypeScript let's that developer make good code, then the variable is JavaScript.
jordwest 9y ago
A great carpenter can hammer a nail with a screwdriver, but that doesn't mean it's a good idea. When the tools help you, a good developer can focus on making better things rather than not making mistakes.