3 ms·
No good metrics on my end, but anecdotally, the compiler regularly catches bugs that I would have had to find via testing. So, depending on how you track bugs,
by Eridrus 11y ago
No good metrics on my end, but anecdotally, the compiler regularly catches bugs that I would have had to find via testing. So, depending on how you track bugs, these types of things might have never made it to your bug tracker, just manifested as dev time. Not that I don't have bugs, it's just catching some. Is it worth having a compile step? Not clear.
In my mind though, the main benefit is types as documentation, both for devs & tool support. Via DefinitelyTyped it makes integrating new libraries simpler. It has made refactoring much more straight forward. I started a side project on the weekend where I wanted a chrome extension, and I made that a typescript and have absolutely no regrets. I've been doing lots of regular refactoring, and while the codebase is miniscule, it's a lot more mechanical to make changes (change the type, look for red squigglies) than really needing to think about where the changes are.
But I feel like our code is very much much more navigable than just straight JS. Being able to know the type of a thing and just jump to its definition makes it that much easier to read. I might have been scarred by my previous experiences trying to read large dynamically typed projects, but you can't just jump into most files and be able to figure out what is going on (particularly with classes).
We only have one typescript codebase, which we moved to from coffeescript, and that was a huge win, partly because of coffeescript, but also because the coffeescript codebase was a disaster and needed some rework. When I originally ported it, it was about 4k LoC in a single file, and now it is 11k across 93 files. My team wasn't entirely thrilled with typescript to start, but some of the features in 1.4 (union types, typedefs) made people happier. We have some very different coding styles, from my end where I want to type everything, to the any-soup we get in some parts.
So, I can't call it an unmitigated success, some of what the codebase needed was just some general structure, but 11k isn't exactly a huge project either, and it's structure is really not very complicated (most of it is completely independent modules).
So, after all that rambling, things I like:
- code navigability (particularly because anything you do a method call tends to be typed)
- code completion
- refactoring is simple
- catches straight forward bugs earlier, rather than me finding them when I test
So, despite it having types, the main benefit has not really less bugs, it's made my life interacting with the code simpler, and it has made bugs caught by the compiler easier to track down.
I think there was a real missed opportunity to have browser definitions split up by browser version so that you could more easily specify a target set and have it show you when you use something not supported though.