loading...
Cover image for Consider Using TypeScript

Consider Using TypeScript

nickytonline profile image Nick Taylor (he/him) Updated on ・5 min read

Originally posted at iamdeveloper.com

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?

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.

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.

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. In a later post I'll go into how to migrate an existing codebase to TypeScript. If you're interested in seeing what a project looks like after being converted to TypeScript, check out ts-react-slingshot.

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.

P.S. Happy 5th birthday TypeScript!

Posted on by:

nickytonline profile

Nick Taylor (he/him)

@nickytonline

Senior software engineer at DEV/Forem. Caught the live coding bug on Twitch at livecoding.ca

Discussion

markdown guide
 

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.

 

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.

 

Order into Chaos, light in the dark, types in anarchy, may the TypeScript God conquer more & more projects.

 

Another project that migrated to TypeScript

 

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.

 

Looks like the next major version of Vue will be written in TypeScript. 🔥