Adding More Guard Rails, Speeding up
Compiling with typescript is like using git branches. It is another layer of protection that allows developers to think about the abstract nature of code, rather than the blocking and tackling of development.
A major appeal of any dynamically typed scripting language is a low level of friction. The cycle of writing and running code in Node or on the browser feels very smooth and freeing. Adding a static type check can feel like an impediment. A simple counterexample to this perspective is misspelling a variable name. This can be annoying to figure out at runtime, especially across a call stack.
“ESLint can detect problems like this!” I hear you say. Quite right! ESLint is an excellent static analysis tool that has rules that can help detect problems before the code is run. I love using ESLint in my JS projects. I only wish that it could do more. I wish that ESLint could tell me if I’m trying to invoke on a token that is not a function, or if I’m referencing a key that doesn’t exist on a given type. I wish ESLint knew what types were at all. The tool that knows these things, and catches my errors is the TypeScript compiler.
It’s true if you are writing plain CommonJS modules that run in NodeJS directly, adding any precompile step is a non-zero effort. However, if you want that code to run on the client, you know are going to have to make some choices about how to be compatible with NodeJS and whatever browsers. Why not choose TypeScript. It’s the same amount of work to set up babel, but TypeScript adds in an additional level of checking.
Use the Best Tools (VSCode)
The Intellisense is especially satisfying when new types can be pulled
in via the Definitely
This project has type declarations for lots of popular repos. This
allows for compiled type checking and improved autocomplete in VSCode.
I’ve found this especially useful when working with
chai. I highly recommend checking this project out and using it to
work with your dependencies.
Debugging node applications (run with the
--inspect option) is also
much better using VSCode than with Atom or the built in Chrome frame.
The source maps load seamlessly and the debugging tools work seamlessly.
It’s a bit of a pain to set up on the project (I’ve got a snippet that
but it’s worth the extra effort.
Developer can often be hesitant to try out new editors. My belief is that it is our responsibility to find the best tools for the job. Sentimentality doesn’t help write/read/debug code faster.
Take full advantage, but know the target
Try to take full advantage of Typescript. Use the access modifiers
abstract to define
desired inheritance patterns. Use interfaces and type aliases to express
intention more concretely. But also understand that these concepts don’t
exists at runtime.
modules can instantiate exported
abstract classes. If there isn’t a
compile time check there is nothing stopping JS from instantiating the
prototypes. However, if you try to call an abstract method, you’ll get
an exception because those methods won’t be included in compiled module
I love the expressive power of these features, but it is crucial to understand the runtime implication, or lack thereof.
I’m still jealous of the runtime performance and advanced refactoring features. But typescript give me a taste of the latter, and I can enjoy a larger toolset for expressing ideas and modelling concepts.