Joining the TypeScript community
Downsides and upsides
The community I am coming from
I've previously enjoyed building services in Scala. One of the most valuable lessons that taught me was that community matters. The language road map matters too. With more mature languages like Java and C++ you never even think about this because they are so ubiquitous, and generally stable. In Scala there were tons of poorly maintained libraries, and unresolved gotchas in the compiler that when you encountered, you simply bookmarked the issue in Github.
The TypeScript community
So entering the typescript community I started looking at the TypeScript repository, what their mission statement was and where they are planning to go. TypeScript is sort of self-aware about points which may stop adoption, but here are some things I take note of:
- To that end, it really avoids polyfilling features - because that would be generating new logic.
- However, practicality is king. TypeScript 2.1 ships with async/await support with a target output as low as ES3, which is only possible with a polyfill.
- Sticking with "practicality is king", the type system is not perfect, nor was it meant to be. But it is easy to learn and generally unambiguous, without the screaming complexity of other languages.
- There is excellent support for TypeScript in Visual Studio Code, Atom, Sublime, and more. It is very easy to edit across a team.
- TypeScript is hyper-aware of issues involved in meshing with regular JS projects, and constantly works to improve migration and quality of integration.
The actual people in the TypeScript community are awesome. They tend to be very professional, helpful, and courteous - seriously considering your problems as something that should work. Even if it wasn't originally part of the design. Maybe something isn't possible the way you think it is - they will still help you find a way to do your job. There are also a few super prolific characters in the community who constantly write about, promote, and build examples for TypeScript - I often refer to basarat as an example.
So where's the rub?
There is a ton of work going on in the typescript community to help fix this, and generally the problem is easily smoothed over. Use the typings or tsd, or use the most recent solution at this point which is to install types from npm using npm install @types .
Why does all of this matter?
In discussions with JS programmers who use babel and test everything to oblivion, they often say they do not see the added value of a type system. Their tests catch simple run time errors, because they unit test everything, because they use TDD. This is true if the tests are flawless, and they can even argue that the mistakes in typings are roughly equivalent to the nooks and crannies that tests sometimes miss.
There is a fundamental issue with this discussion - one which seems highly controversial - which is whether or not that test code is added technical debt. The answer to me is simply that there is more code, so yes, there is new debt introduced. Maintaining tests can be a nightmare. Running tests on large systems can be slow, and really - not everyone has the luxury of testing every trivial function just to be sure it will actually be able to run when it is invoked.
Testing is still important, but for critical code paths, not for every code path. Using TypeScript is an important step to take if you do not test every code path that you build.
Why I enjoy TypeScript every day
At the end of the day, I feel that using TypeScript makes me faster:
- intellisense is very convenient
- having automatic imports with tools like typescript-hero,
- being able to safely change a function signature and have compiler warnings about usages
- show-usages is wonderful too