TypeScript: What's the Point?

TypeScript is just a superset of JavaScript, meaning it's just JavaScript - but with enhanced functionality. When you run an application built in TypeScript, the code is compiled into the same JavaScript you know and love before being run in your browser. (btw - for this reason, you can use TypeScript anywhere youd normally use JavaScript on the frontend and on the backend!)

The only issue with is that TypeScript - to someone who has never used a statically-typed language - is annoying af. When youre used to the carefree life of declaring variables without having to worry about their future, what theyll eventually become, and the functions theyll have to interact with, adding types to your code just seems like a bunch of extra work for little reward.

So, Why Not Just Use JavaScript?

The short answer is: TypeScript makes code less error prone and more readable than JavaScript. It was designed especially for projects that meet the following criteria:

• Large or complex (enterprise-level applications)
• Maintained by multiple people
• Will evolve or be updated over time

Less Error Prone

The big difference between TypeScript and JavaScript is when typechecking happens.

First, what is typechecking? Typecheckers are type police built into JavaScript to enforce the type laws (for example, its against the rules to multiply a string with an array). Typechecking is the process where typecheckers verify that your code follows all of the rules of the language.

In dynamically-typed languages like JavaScript, typechecking occurs during runtime. This means youll find out about your mistakes when you run your program. This may happen locally as youre testing, during your unit tests or smoke tests, or even in production after youve shipped it to your customers.

By contrast, statically-typed languages like TypeScript check types during compile time - right in your text editor! This means that youll instantaneously see mistakes that could potentially break your code as you make them. Not only does this prevent you from shipping a buggy app, it also closes the gap between when you make the mistake and when you find out youve made a mistake, getting you to a fix, faster.

More Readable

With explicitly typed code, others can look at your code and easily understand what its meant to do. If youre working in a huge code base with other engineers, this added level of readability is crucial for preventing new type errors.

Once youve got a solid understanding of how to use TypeScript, youll also notice that the way you think about code will start to change. Because static typing forces you to think about types before youve even declared any values, you'll get great at mapping out the relationships between your components and their functions in your head before you even declare any variables! You'll be able to identify and account for new edge cases before deploying to production. Overall, you can expect that your code will be sturdier and much easier to maintain.

JavaScript vs TypeScript

Now let's look at some examples.

Example 1:

Adding two numbers to calculate padding on a button.

  const a = icon ? 0 : 4  const buttonPadding = `${(a + 6) + px}`

You wrote the above code earlier today to calculate the amount of padding for buttons in your app. If the button does not have an icon, we want 6px of extra padding. const a is the potential amount of padding well have, and well concatenate a and px before plugging it into our CSS.

As long as a and b are both numbers, buttonPadding will work fine! But lets say that youre coding along and accidentally change a to this:

  const a = icon ? '0px' : '4px'  const buttonPadding = `${(a + 6) + px}`

It's a small mistake, but now a will return a string. If youre using JavaScript, this may still run just fine, but youll wonder why you're not getting any of that extra padding on that button. It's because buttonPadding is now undefined. And lets be honest - its always silly little code errors like that these take up so much of our debugging time and patience to try to resolve!

If you instead used TypeScript, though, you wouldve gotten one of those annoying super helpful red squigglies under buttonPadding as you were coding, letting you know that we expected a to be a number, but its a string. When you hover over the squiggly, you will see this error message:

    const a = icon ? '0px' : '4px'    const buttonPadding: number = `${(a + 6) + px}`  // error: Type 'string' is not assignable to type 'number'.

TypeScript gives you the context you need to easily find out whats wrong and where the mistake happened, saving you a huge headache.

Example 2:

Calling an array method

  const southernBreakfastItems = ['biscuits', 'gravy', 'sausage', 'grits']  const breakfastList = southernBreakfast.map(food => food)

You wrote this block of code 6 months ago. breakfastList maps over this array (southernBreakfastItems) of food items youve gotten back from a menu API (let's just imagine that this is what your Promise is returning) and just returns the name of each item.

Your colleague opens the codebase today and starts working with this old component. They unknowingly change the Promise returned in southernBreakfast to a single string:

  const southernBreakfast = 'biscuits'  const breakfastList = southernBreakfast.map(food => food)

A type error like this has the potential to break your app. Without static types, it can be really difficult to track down where the source of the issue is coming from.

If you use explicit types instead, you get a helpful error line under the .map in the text editor letting you know that you're trying to run a .map on a string instead of an array. TypeScript once again saves you from 3 hours of console.log-ing.

// Property 'map' does not exist on type 'string'

Example 3:

Accessing the properties on an object

const musician = {  firstName: Duke,  lastName: Ellington,  genre: jazz,  birthplace: Washington, D.C.,}const placeOfBirth = musician.brthplace //typoconst yearsActive = musician.years // years does not exist on this object

Neither placeOfBirth or yearsActive will actually work, but if youre using JavaScript you wont find out that they dont work until you run your app locally (or worse - after you ship it to the customer). By contrast, TypeScript gives you helpful and specific feedback within your text editor as you type!

const placeOfBirth = musician.brthplace// Property 'brthplace' does not exist on type `'{ firstName: string; lastName: string; genre: string; birthplace: string; }'`. Did you mean 'birthplace'?

Above, TypeScript sees that you made a small spelling typo and tries to gently guide you toward the error as youre coding.

const yearsActive = musician.years// Property 'years' does not exist on type '{ firstName: string; lastName: string; genre: string; birthplace: string; }'.

Here, TypeScript tells you that this wont work because you said musician would have 4 key-value pairs, none of which have years as a key.

I hope this post has convinced you that TypeScript is a worthwhile tool for scaling and managing large apps. Now go add some static to your app!

Connect with me on Twitter and on LinkedIn.