4 ms·
I've done a few typescript projects. Some migrating an existing codebase, some starting from scratch. Every time it has been a nice experience, and with every r
by Joeri 10y ago
I've done a few typescript projects. Some migrating an existing codebase, some starting from scratch. Every time it has been a nice experience, and with every release it gets nicer. Two of the projects had very complex requirements, and typescript was instrumental in being able to refactor them with confidence.
I think the upsides are quite well known by now. Honesty requires me to admit that I did run into some downsides:
- Initially it was difficult to understand the exact mechanics of how typescript ... types. Definition files seemed like a bit of a black art, and how to annotate existing code so that it had the proper type wasn't always obvious, especially when you run into libraries with incomplete or wrong type definitions and when you want to do tricky stuff like creating typed mocks in unit tests. The typescript documentation is very good and I haven't needed much beyond it, but some extra real-world type definition chapters would help.
- Setting up a complete dev toolchain is challenging. I wanted everything: source maps, in-IDE debugging with breakpoints, in-IDE unit tests with code coverage, tslint, gradual introduction into an existing codebase, and robust integration into the build of the rest of the app (which in my case meant SBT integration). I still don't have code coverage in my in-IDE unit tests. The way I see it though, if your javascript has any build step at all you already have this pain, so this isn't so much a problem with typescript as a problem with javascript build pipelines in general.
- Convincing other developers typescript has value and isn't javascript's weird ugly nephew is an uphill struggle. Once you do a typescript project you end up understanding the value, even if you might not find it valuable for yourself personally, so it's only a matter of convincing developers to give it a go. However, getting to that point is a bit of a chicken and egg problem.
- KurtMueller 10y ago> Convincing other developers typescript has value and isn't javascript's weird ugly nephew is an uphill struggle. I feel the same way about Elm, F# and Fable, Facebook's ReasonML, and any other language that has an ML type system and compiles to javascript. I think the value becomes more apparent when: a) you work in a large codebase and have to refactor either a large swath of code and/or a critical piece of logic and b) you need to make illegal states unrepresentable. In both cases, I have found having a compiled, ml-typed language extremely helpful. I think for both Typescript or an ML language, having immutable non-nullable types by default really cuts down on complexity - instead of having to specify everything that's immutable with something like a `const` keyword, you instead have to specifically point out which attritibutes on a type are mutable. That's a small win but has huge benefits - especially when you're trying to debug code. That's just my two cents anyway.