For example, the proposal for
Also, you can combine TypeScript types with Babel transpiler, which means you can use anything that Babel supports (which I think is virtually anything). Here’s one example.
TypeScript is very mature, it has been around since October 1st 2012 (about 8 years by the time of this post). Most of the mainstream packages on NPM already have support for TypeScript. About 70% of the common packages in NPM are typed.
You can also find a great resource for types in github/DefinitelyTyped which was created by the community and it has thousands of types.
If you use Visual Studio Code and don’t code in TypeScript yet, you actually are already using TypeScript without even knowing about it.
Is TypeScript like CoffeeScript or DART?
The Learning Curve
If you want to use TypeScript’s features you will have to learn a two basic concepts.
- Configuration file
- Using Basic Types
Your configuration file determines how strict you want your code to be. You can start off without any restrictions and it will only complain when you have actual errors in your code. The simplest configuration would look like this:
The basic syntax to use types is
: <type>, for example:
let foo: string.
You can find the basic types at TypeScript’s handbook
With that you have all you need to get started!
If you want to learn how to use more advanced features you can gradually learn as you go, you’ll never be blocked by not knowing them.
Catching errors before you even run your app
You can see in the screenshot above that we have the exact same code on both the TS and JS files.
If you want more power you can use some basic TypeScript features here to detect errors before you even run this code.
In your own typed code
If I add types on my function parameters I can see that I actually have a typo in the function I’m using to compare the strings (
localCompare which was meant to be
With TypeScript I can see the error before even going to my browser and running the script.
In existing code
We can use the example bellow to observe that TypeScript can prevent an error even before the code is run. Here we’re trying to send a
string in place of a
Implicit vs Explicit
Types doesn’t always have to be explicit, it can be implicit. For example:
Here we have the function
console.time which takes a string as a parameter, you can see that when I try to pass a number in the parameter I get a red squiggly line underneath. That is telling me that there’s something wrong with the variable that I’m sending in the arguments.
You can declare variables that can be multiple types. For example:
let someCode: string | number;
someCode = 'ok'; // ok
someCode = 1; // ok
Type flow in code
TypeScript is able to narrow down your object type inside the scope of a block. So in the example bellow we check for the type in runtime and TypeScript can tell you what the type of your object is going to be inside that scope. The answers are in the
I copied and adapted a bit the example used by Anders Hejlsberg in his talk back in 2016 when this feature was being introduced. He made a quiz asking people what the type of the variable would be at the last bit of code.
In the example above there’s a slight change to the original implementation, now I ask you, what is the type of
emote at the end of the code?
Because TypeScript has all this type information it can help you auto-complete things in your code. You’ll not ever struggle to remember the order of parameters in a function because you don’t have to. TypeScript will give you that.
This also work for packages that support TypeScript (which nowadays is basically any package). For example, using the package
It gives you not only auto-completion but a lot of documentation as well.
Reduce bugs by 15%
TypeScript in large scale applications
Back in 2016 in the Microsoft //build event, Anders Heljsberg talked about how TypeScript is great if you want to work with large scale applicaitons.
— Anders Hejlsberg (//build/2016)
Tooling & Refactor
TypeScript allows you to safely refactor. You can see in the image bellow that you have a function with a parameter called
copy. You also have a function called
copy and multiple comments with the word
copy in it. A find and replace wouldn’t correctly rename because it doesn’t have information about your variable and the scope of it.
But with TypeScript you have all the information you need to rename only references to that actual variable. So changing the name of the variable
copy in the
setCopyPasta function would rename only the reference inside of it.
And refactor also works with multiple files. So if you have modules and rename your exports you’ll be safe because all references across all files will also be renamed.
Here’s a cool GIF showing refactoring:
How much has TypeScript influenced in ECMAScript?
My Personal Opinion and the way I use it
I use TypeScript in everything.
- Auto-complete: I can try to invoke functions and even if I don’t remember the order of the function parameters I can get TypeScript to show me what the parameters are. In a sense it works like JSDoc, but it provides me type information about the parameters and validates my inputs. All of this makes it very safe for me to avoid bugs
- Errors before running: I get instant feedback when I do something wrong. I don’t have to waste time in the back and forth of running checking for errors, fixing, running and so on. This saves me a lot of time and prevents me from creating bugs
- Avoid typos: I can’t make a typo because it won’t allow me to compile the file if there’s something wrong in it
- Refactor: Because it has types and it knows the variables references, I can easily change the name of a variable and everything referencing it. So my code doesn’t have to be “read-only”
- Scalability: I work even on “enterprise” projects and still be able to refactor a lot because of all the tooling that TypeScript gives me and I can feel safe in changing a lot
- Documentation: Everything is documented
I even use in small scripts because it’s so easy to configure and run. I get so many benefits for so little effort.
I like to use TypeScript in Node.js, React, Angular and any other thing. You can try it out going to StackBlitz and choosing a new project.
I like that I can configure the restriction levels in whatever way I want. Often I choose to not use any restrictions for types and just enjoy most of the benefits I get anyway.
TypeScript is supported on
npx create-react-app my-app — template typescript
- Angular: default
- Node.js: you can install
ts-node/ts-node-devand use in place of
- Every mainstream code editor / IDEs
- Second most loved language in 2020
- 7th Top Language in Github
- 38% of bugs at Airbnb could have been prevented by TypeScript according to postmortem analysis
Other technologies like it?
Flow (IMO it sucks).
List of BAD arguments for not using TypeScript
- It’s not going to be around in 5 years: WRONG!!! It has been for about 8 now
- It’s not community-driven: WRONG!!! It’s literally open source and one of the most active on Github
- It is risky because it replaces unit tests: WRONG!!! It DOESN’T replace tests, it only ADDs more things (on top of your tests) that makes your code even safer
- It is messy: WRONG!!! It helps you document your code and gives you a lot of tooling to refactor which makes your code scalable. It also helps you read your code and understand the object structures and how to use them without having to open files to see the definition or log the object to see the structure
- Basarat Gitbook
- TypeScript Handbook
- TypeScript Playground
- TypeScript with Babel presets
- TypeScript Conference 2019
- TypeScript BLD2011
- Dmitry Pashkevich’s: 7 Bad excuses for not using TypeScript
- StackBlitz (create projects on the web, like codepen)