I'm not going to be one of those that tells you have to use TypeScript (or Flow for that matter). I'm also not going to go into the whole TS vs. Flow debate. There are plenty of people already doing that. All I want to do is present some good reasons why you might want to consider using TypeScript. After that, I leave it up to you.
I've been using TypeScript since fall 2014 (v. 1.3). It's come a long way. The amount of care that has gone into the language to keep it as a superset of JavaScript (not altering the JS language) is amazing. Kudos to Anders Hejlsberg, the entire TypeScript team and OSS peeps that have made this such a great project.
Why TypeScript?
So let's get to it. If you've never used a statically typed language like Java or C#, this may seem foreign to you. You're probably asking yourself, why TypeScript?
- Type Safety: During development, if a type is not correct, it is caught during compile time. e.g.
const index: number = 'hi'; // index can't be a stringor if a property on an object has a typo. This allows us to catch errors early on during development instead of at run-time (since JS is a dynamically typed language). Here's a good explanation of statically typed vs. dynamic languages. - Refactoring and Intellisense capabilities when using a TypeScript enabled editor or plugin.
- Visual Studio Code, my preferred editor. Here's my setup, vscode.iamdeveloper.com.
- TypeScript Atom Plugin
- TypeScript Sublime Text Plugin
- WebStorm
- IntelliJ Ultimate
- TypeScript for Visual Studio 2015
- Visual Studio 2017 (includes TypeScript support)
- alm.tools
- Did I miss one?
- Intellisense when using npm packages that have TypeScript declaration files even if your project isn't written in TypeScript (As far as I know this only applies to VS Code. Please chime in if this is not the case.)
Great, looks awesome, but what about consuming npm packages from projects that don't use TypeScript? As mentioned briefly above, Visual Studio Code can grab the declaration files even if your project doesn't use TypeScript. So where are these declaration files coming from?
TypeScript Declaration Files
What is a TypeScript declaration file? In a nutshell, it's a file that describes what types are in a package. For authors of TypeScript based projects, they will almost always author TypeScript declaration files. For projects that aren't written in TypeScript, sometimes, package authors will write the declaration files by hand and maintain them in their projects. In most cases though, the community has stepped in/up to write declaration files by hand of projects that aren't written in TypeScript. They're all housed in a repository called DefinitelyTyped, a repository of high quality TypeScript type definitions maintained by the JS/TS OSS community.
To add types for a package that does not have its own declaration file, install its equivalent @types package. e.g. npm install lodash --save;npm install @types/lodash --save-dev; Now when you use lodash in your TS project in a TS capable editor, you will get typed Intellisense.
Who's Using It?
The hard (smart) work and love that has gone into TypeScript has not gone unnoticed. In recent times, some fairly large projects that you may know have migrated to TypeScript.
Note: I update this list from time to time.
- Fun fact, Visual Studio Code is written in TypeScript!
- Angular adopted TypeScript in version 2 (related Dart, Typescript and official languages at Google)
- TypeScript at Slack – Several People Are Coding
- GitHub Rewrites its Desktop Client Using Electron
- Apollo GraphQL
- MobX
- Formik
- Razzle
- TypeScript at Lyft
- RxJS
- glimmer.js (of Ember fame), also related Glimmer.js: What’s the Deal with TypeScript?
- Rollup
- Lighter than Lightweight: How We Built the Same App Twice with Preact and Glimmer.js | LinkedIn Engineering
I'm sure there are others, but these are the big ones I'm aware of. You can always check GitHub for trending TypeScript projects.
Additional Resources
Here are some additional resources to get you up and running.
- TypeScript Playground
- Unofficial TypeScript Playground (update May 2019)
- TypeScript Deep Dive
- TypeScript Fundamentals (Great free course)
- Marius Schulz’s Blog
- Quokka.js (live scratchpad for JS with TypeScript support)
- The TypeScript team’s Type | Treat series on DEV
- Accounts to follow on Twitter:
- The Offical TypeScript account (@typescriptlang)
- Daniel Rosenwasser (@drosenwasser)
- Mohamed Hegazy (@fdsmars)
- Marius Schulz (@mariusschulz)
- Basarat Ali Syed (@basarat)
- James Henry (@mrjameshenry)
- If I missed one that you think should be on this list, let me know (nick at iamdeveloper dot com).
To summarize, TypeScript is a great option if you're looking to scale a team up quickly on a codebase (Intellisense, refactoring) as well as catching silly errors via type checking.
Thanks goes out to @drosenwasser, @RichSeviora and @nojvek for taking the time to review this blog post. 💯 🔥
Questions or comments? Hit me up on Twitter @nickytonline.
Latest comments (9)
Static type checking is so useful.
Looks like the next major version of Vue will be written in TypeScript. 🔥
Another project that migrated to TypeScript
This video that just came out very recently explains a lot of the benefits of TypeScript, #FiveThings that TypeScript Can Do for You. Super funny and worth a watch.
Actually, I find the main case for type systems in JS (no matter if flow or typescript) to be in-code documentation, with the added advantage that it doesn't inflate your code as much as JSdoc or similar syntax extensions do, so it doesn't break my reading flow.
For teams of more than 2-3 persons, I would definitely recommend using a type system. If you have an existing code base, flow with its powerful type inference and the ability to add type descriptions in comments (so you don't even need to change your build chain) will be the better choice in my opinion. If you have a new project, either choice is fine.
Thanks for the feedback.
The in-code documentation is great. I mention it indirectly, i.e. Intellisense. I might update the article to mention that point more explicitly.
Switching build chains is not really pertinent to this article as the premise is to use TypeScript. I understand though that the Babel ecosystem is what most are used to, so transitioning to the TS build chain could be a pain to some.
Thanks for your answer. About the in-code documentation: even if you don't use Intellisense, it helps: you can get an idea about how to use a library much faster with type annotations.
As about the transitioning Even if the legacy project doesn't use babel, but plain ES5, maybe with jQuery, you can still add some type comments like /* : string[] */ (or even let flow's type inference do its magic; it will usually cover ~50% of your project without you doing anything) and enjoy at least a bit of type safety without changing anything else.
Order into Chaos, light in the dark, types in anarchy, may the TypeScript God conquer more & more projects.
I have been using Typescript recently. It has helped catching syntax problems and forced to change the way I think about the paradigm in OOP.