Why You Shouldn’t Be Scared of TypeScript

TypeScript is a compile-to-JavaScript language that brings compile-time type checks, classical object-oriented programming patterns, and powerful typing features to JavaScript.

Unsurprisingly, quite a few people see TypeScript as suspicious, at best. And that's fair enough -- at the end of the day, even TypeScript compiles down to raw JS. It's not like we absolutely need an intermediate step. Being a purist myself, I understand the sentiment!

But, there are real benefits to the extras that TypeScript brings, whether you use it or not; and there's no reason for suspicion, either way.

Why Not Just JavaScript?

The litany of languages that compile to JavaScript seems to grow by the day: CoffeeScript, TypeScript, ClojureScript, GorillaScript ... With all the options, the question arises as to why. Why bother with all the complexity of a new language and a new toolchain, if all we get in the end is just JavaScript? Why not Vanilla JS?

There are a number of reasons people build transpiled languages, but at the top of the list are:

  • Additional features; and
  • Freedom to innovate.

Transpiled Languages Add Features

One substantial advantage to transpiled languages is that they can add features . This is one of TypeScript's main selling points, as it adds interfaces, abstract classes, algebraic data types, and other features to JavaScript, which we wouldn't be able to use otherwise.

The transpiled language implements a feature in raw JavaScript, and lets you work with the interface without having to worry about the details. Truth is, we do this even when we write normal JavaScript: We still use ES6-to-ES5 transpilers to write to use JavaScript's newest features, since the relatively small number of people using browsers with reliable ES6 support is . . . Well, people like us.

Transpiled Languages Are Free to Innovate

CoffeeScript is a good example of a language that innovated atop its JavaScript base. This is immediately obvious syntactically:

# Ruby-style comments w/ hash, no semicolons, only arrow functions
Person = (name) =>
  # @ indicates 'this'
  @name = name

  @speak = () =>
    console.log @name

  return @

Me = Person('Peleke')

It doesn't even look like JavaScript. New syntax includes:

  • @ indicates this, so this.user becomes @user; and
  • Functions are defined with => or ->, not the function keyword

. . . And CoffeeScript doesn't allow ==, either: It forces ===, unless you really want type coercion and embed JavaScript between backticks.

TypeScript has completely different goals, and is much more conservative than this. Rather than experiment with new syntax and opinionated design decisions, it takes JavaScript as its starting point, and adds to it while departing minimally from the standard . With very few exceptions, vanilla ES6 is perfectly valid TypeScript. That makes it much more accessible than other compile-to-JS languages.

A transpiled language is a more radical idea than new JavaScript transpiled to old JavaScript, but the principle is similar, and the value of transpiled languages is well-established: They give us the power to experiment, expand, and express ourselves in new ways .

Strengths of TypeScript

TypeScript brings several new features to the table. The most notable of these are classes, interfaces, and compile-time type checks, but there's quite a bit more than that lurking in the depths.

I'll talk about a few of these, but would like to call out a few of TypeScript's less-discussed strengths:

  • Familiarity;
  • Support & Toolchain Improvements; and
  • Near-Total JavaScript Interop.


There's a lot of talk about TypeScript's features. There's a lot less about why they're there.

That's largely because TypeScript's most famous features -- compile-time type checks, interfaces, class-based design patterns -- are so familiar that many developers from other backgrounds take them for granted. The fact that JavaScript lacks these features is a common pain point for developers coming from other popular curly-brace languages, and TypeScript adds them because classical OOP is the most familiar way for them to design, develop, and discuss software.

You could argue that this is no excuse not to just learn the language you're writing in rather than the one you're used to. It would be a legitimate argument: Asking, say, the Haskell community why you can't "just do IO" won't go over as well as whining about JavaScript's lack of whatever-it-is does amongst web developers.

Regardless, the fact remains that people are more productive when they're comfortable with their tools

If TypeScript makes developers more productive, they can -- and should -- use it. Forcing them through a largely idiolectic learning curve just to get things done is impractical in real projects.

One semi-legitimate criticism of TypeScript is that it creates the illusion that JavaScript has features that it actually doesn't. The culprits are the usual suspects: Classes, interfaces, and static typing are not features we can expect any time soon in JavaScript, and having them in TypeScript is not the same thing.

Writing TypeScript with the misconception that it implements "true" classes, interfaces, and runtime type checking is guaranteed to lead to awkward code. The fact that TypeScript adds sugar isn't license to ignore its JavaScript underbelly. But, for those who do know their JavaScript well, and think better with TypeScript's extras, using TypeScript can make them better at what they do.


TypeScript also has the advantage of having some giants behind it.

Whereas most compile-to-JS languages are community efforts, TypeScript is an official Microsoft endeavor. They've put a lot of time into developing it, and users can rest assured that they'll have long-term support from the tech giant should they migrate to TypeScript.

TypeScript has support for all the most popular editors including Sublime Text, Atom, Eclipse, Emacs, WebStorm, Vim, and of course Microsoft's Visual Studio family.

It's used in a number of real-world projects, too, so you can trust it's robust enough to handle just about anything you're working on:

Take a look at the list of TypeScript users.

Whether or not you use Angular 2 or Visual Studio, that kind of endorsement from both Microsoft and one of Google's most prominent web teams should help you sleep at night if you're about support and longevity.

TypeScript is also a major step forward for those who use IDEs. According to Hejlsberg, who's at the head of the TypeScript project, JavaScript's lack of type annotations makes it practically impossible to build a robust IDE. For the hacker-types whose custom is one-(wo)manning NPM modules in Vim, that's a low priority. But a powerful development environment can make teams collaborating on large projects substantially more productive.

Near-Total JavaScript Interop

As a bit of a purist, I'd have that TypeScript's most important benefit is that it's just JavaScript. Running raw JavaScript through the TypeScript compiler will rarely cause trouble (the major exception being with class declarations), so migrating to TypeScript can be as gradual as you want.

That means you can use the features that help you think, and forget about the ones that don't. When I write TypeScript, I don't use classes, mixins, generics, or enums, but I do use type annotations, aliases, and ADTs quite a bit.

You might choose to use exactly the tools I don't, or toss in a type annotation only every once in awhile. That's fine with TypeScript: You can use as much, or as little, as you want. It is not an all-or-nothing commitment: It's only as total as you make it.

You can use as much, or as little, as you want. It is not an all-or-nothing commitment: It's only as total as you make it.

TypeScript's History

To quote of core developer Anders Hejlsberg, TypeScript was born in response to complaints from clients and internal teams that JavaScript didn't lend itself well to large applications.

The goal was to "strengthen JavaScript with things like classes, modules, and static typing", without sacrificing the advantage of its being open-standards and cross-platform; the result was a "language for application scale javascript development", built as a superset of the language.

TypeScript vs *Scripts

Even if TypeScript does bring a lot to the table, the question as to why we need another compile-to-JS language remains a fair one.

Different projects pose different engineering challenges, and different languages provide different sets of solutions and tradeoffs. Different compile-to-JS languages take different approaches to solving the problem of simplifying, streamlining, and strengthening the engineering process.

That means they end up solving different problems in dfferent ways, and are particularly suited to specific tasks. CoffeeScript lends itself well to configuration files and beautiful tests, neither of which I'd ever prefer to write with TypeScript.

Two common points of comparison are Dart and CoffeeScript. To be frank, the most these three languags have in common is that they compile to JavaScript: It really is an apples-to-kumquats comparison. Taking a closer look at some of the differences in their design decisions should clarify why.


Anders Hejlsberg identifies two fundamental differences between TypeScript and CoffeeScript:

  1. CoffeeScript is a different language . TypeScript is a superset of JavaScript. CoffeeScript targets the JavaScript platform, but is otherwise a different language.
  2. CoffeeScript does not feature static typing . This is mostly relevant to folks who use IDEs (some of us don't).

To quote Hejlsberg further, "if you know JavaScript, you already know TypeScript". You've got to pick up a handful of extras, but the that should take all of a day for those familiar with raw JavaScript and ES6. CoffeeScript, on other hand, requires you to learn a completely different syntax. It's accessible, but the learning curve is steep in comparison.

Maintaining such overlap with the target language was a fundamental tenet of the TypeScript's design. The whole point was to create a language that simplifies the creation of large JavaScript applications , while departing minimally from the standard .

CoffeeScript made no attempt to be a superset of JavaScript. Instead, it sought to "expose the language's good parts", while suppressing its infamous "bad parts" and enhancing expressivity.

The most obvious difference between the two approaches are that:

  • TypeScript is largely unopinionated k but seeks to be better equipped to scale , whereas
  • CoffeeScript builds its opinions into the language , and adds no extras explicitly intended to ease the creation of large applications.

TypeScript is obviously of the opinion that class-oriented programming and static typing are useful tools, but makes no attempt to coerce you into using them. CoffeeScript, by contrast, has strong opinions as to what is good or bad abou JavaScript, and exposes functionality accordingly.

That's not to suggest one is better than the other -- Brendan Eich has mentioned CoffeeScript's influence on JavaScript multiple times. The point is rather that they're different beasts, with different goals, and different solutions.


Dart is syntactically more similar to TypeScript than CoffeeScript, but departs substantially from both languages with regard to its design philosophy.

Dart and CoffeeScript agree that JavaScript needs fixing, but solve the problem differently. The Dart team identifies two substantial differences with CoffeeScript:

  1. Dart makes different syntactical choices; and
  2. "Dart introduces new semantics, while CoffeeScript retains the semantics of JavaScript."

Similarly, Dart and TypeScript "have similar goals [of making] building large-scale web applications easier", but take different approaches to achieving that end: " Dart purposely made a break from certain parts of JavaScript’s syntax and semantics in order to eradicate large classes of bugs and to improve performance ", whereas "TypeScript maintains backwards compatability with JavaScript".

This is a substantial difference in opinion from that of the TypeScript team, which asked, "what are, qualitatively, the few things that are missing from JavaScript itself, and how can we add those without disturbing all of the advantages of JavaScript", and aligned its additions against the answer.

"What are, qualitatively, the few things that are missing from JavaScript itself, and how can we add those without disturbing all of the advantages of JavaScript?" ~ Hejlsberg

The Dart team decided there are more than "a few things missing from JavaScript", and designed the language accordingly. And, where TypeScript is concerned exclusively with improving the development experience on the web, Dart is built with mobile app development, as well. That's a whole new can of worms to consider as a language designer and, while it's a fantastic language, it's also a very different one.


JavaScript has done its job just fine for 20 years. At the end of the day, it's hard to argue that we need extras. On the other hand, it's hard to argue that we can't benefit from them. TypeScript:

  • Is more comfortable for a lot of people than raw JavaScript;
  • Is flexible with what you leave and what you take;
  • Enables more powerful tooling; and
  • At the end of the day, can still just be JavaScript .

For my part, I use TypeScript whenever I work with Angular 2 or Rx.js, and when writing heavily functional code (I've got a habit of typing functions). The rest of the time, I stick to vanilla JS. Switching between the two is simple enough I don't think about it anymore.

"JavaScript has some quirks, but you can teach a compiler about the quirks and you can have it check all of these things." ~ Anders Hejlsberg

Whether you use it or not, TypeScript has some indisputable strengths, and experimenting with it is instructive. If you're open to trying something new, give the documentation a glance, write something small, and see how you feel. If you love it, now you know. If you hate it, that's fine too -- just change the extension back to .js and get back to it!

How do you feel about TypeScript? Love it? Hate it? No opinion? Whatever they are, leave your thoughts in the comments, or shoot them to me on Twitter (@PelekeS)!

Peleke Sengstacke

Peleke Sengstacke is a web and Android developer with a soft spot for functional programming.

He likes linguistics, Haskell, and powerlifting. He dislikes mosquitoes, cramped bus rides , and merge conflicts.

Catch him on Twitter (@PelekeS), or sign up for his email list on what to learn and where to learn it (http://www.tinyletter.com/PelekeS). It's wicked educational.