“Self-Documenting Code”

“World-Class Tooling”

“Type-Safety”

By this point, you probably know what TypeScript is: a typed superset of JavaScript, meaning it compiles directly to JavaScript. All JavaScript is valid TypeScript, and you can even use the TypeScript Compiler (the thing that turns TypeScript files into JavaScript files) to check existing JavaScript code for bugs. (a tiny bit more on that later).

TypeScript is based directly on the ECMAScript standard. It is not like CoffeeScript or Dart, which have completely different syntaxes. Because of that, it’s easy to switch over to. You also don’t have to use every feature all the time.

There are things like “implicit any’s” and type inference and JS-Doc flags like @js-check that allow the transition to feel like an easily controlled volume dial: turn on what you need when you need it. But of course

“true and complete type-safety comes when all the features are on, which while an admirable goal, isn’t all that necessary with a language like JavaScript.”

You can lose a lot of JavaScript’s unique qualities and capabilities by going all-in on TypeScript and static-types. (Think Variadic Types and any other complicated typing situations.) The point is, you don’t have to go 100% in on TypeScript to see big benefits. The interface feature that TypeScript provides is reasonably enough for me to use it alone. But what is an interface? 

Interfaces 

export interface IDataItem {
    author: string;
    caption?: string;
    date: Date | string;
    description: string;
    id: number;
    image: string;
    liked?: boolean;
    location: string;
    popularity?: string | number;
    title: string;
    viewed?: boolean;
}
 
This “interface” is a functioning, consumable piece of code that is required for this program to run. (view the code here at app/core/data.service.ts) I encourage you to follow the metaphorical “threads” of the data through this demo NativeScript application to really get a sense of how powerful this is. (check out app/home/home.component.ts, line 26 and go from there).
 
There aren’t any comments but you can directly infer what it takes to render the Tinder-like Card in this demo. (you can check out more cool NativeScript demos here)
 
This interface is telling us exactly what shape the data is in. This will enable an editor like VSCode to intelligently serve up suggestions on what to type next. (Intellisense) You may know that a more basic version of functionality is available by simply installing and configuring the TypeScript compiler in an existing project and enabling the flag checkJS”.
 
That will tell our IDE to “hint” us with the properties and methods of whatever we’re working with but it won’t be able to stop us when we pass in the wrong type of data – that’s only possible with a true TypeScript file – enabling type-safety, interfaces, decorators, generics, and the rest

Conclusions

The number of bugs that come from improperly typed code isn’t that high, at least as a percentage of total bugs in software. (read Eric Elliot’s article on the subject here) Stopping type-based errors is not the main reason why I’m advocating for you to use TypeScript.
 
It’s the languages innovative features like interfaces, the never type and the exhaustiveness-checking it allows you to do, decorators, and the incredible tooling and time-saving guidance it provides that makes it special.
 
It’s a typed-language that isn’t like any other we can effectively use today: you don’t have to go all-in, and its underlying type-system itself is incredibly innovative.
 
“Type” might be the languages name, but checking types is not the only thing this language can do. If you don’t believe in static-types, you don’t use them, ever or everywhere, but let TypeScript’s other incredible features help you write better code!

LEAVE A REPLY

Please enter your comment!
Please enter your name here