TLDR: TypeScript simply adds types to JavaScript.  We can reduce run-time errors by catching more bugs at design-time. It doesn’t ruin the flexibility and expressiveness of JavaScript and it’s easy to start using TypeScript in your SAP development today.

JavaScript is one of the most important programming languages. In the 2023 Stack Overflow developer survey it was listed as the most commonly used language amongst professional developers.   I enjoy using JavaScript because I find it’s flexibility is conducive to good ‘flow‘. It’s easy for me to ‘express myself’ as I write.

It’s also pervasive because it runs almost everywhere. Every modern browser has a JavaScript runtime, but of course it can run on servers too.

A downside of the dynamic typing inherent in JavaScript (as opposed to the static typing of Java, for example) is that it’s easy for type-related bugs to slip through the net and materialise as run-time errors.

What if there was a way to catch these bugs at design-time, without spoiling the expressiveness and flexibility of JavaScript? Such a tool would have a big potential to change the world, because of the near-ubiquity of JavaScript . Happily there is such a tool, and it goes by the name of TypeScript.

In this short series I would like to introduce you to TypeScript and explain how it can improve your JavaScript development.  I will focus on the SAP ecosystem and I hope to share the perspective of a new convert, not an expert (because I am not a TypeScript expert).

To learn more we must head to the ‘old west’ where we will meet the TypeScript Sheriff.  He’s tough on type errors but don’t worry for your safety.  As long as you aren’t a cowboy coder you have nothing to fear…

The TypeScript Sheriff

Why TypeScript?

The easiest way to explain why TypeScript exists is to consider a simple example. Here we scaffold a function to book a ticket on a stagecoach, then we call the function to book a seat from San Francisco to Boulder City

function stagecoachBook(startPoint, endPoint, date) {
    //logic here
}

stagecoachBook(new Date("1860-06-17T00:00:00"), "San Francisco", "Boulder City");

This JavaScript code looks good, but when we run it what will happen? A run-time error!  Whilst we have the correct number of parameters, they aren’t in the right order.  Many IDEs (& linters) won’t pick this up.  It might be easy enough to find the bug (depending on our test coverage) but what if the mistake is in a obscure piece of code that only runs in exceptional circumstances?

Far better to introduce static types, as in this TypeScript example below.  Now we specify the types of the function parameters

function stagecoachBook(startPoint: string, endpoint: string, date: Date) {
    //logic here
}

stagecoachBook(new Date("1860-06-17T00:00:00"), "San Francisco", "Boulder City");

The IDE will give us an error like this:

Argument of type ‘Date’ is not assignable to parameter of type ‘string’.

So much better to find our error at design-time! Other common type errors prevented are typos in function names and assignments to constants (using const when you should have used let).

Zooming up from the desert weeds to a wider vista it should be obvious that the advantages are more than just avoiding the errors shown in these simple examples.  Explicitly declaring types makes code easier to read. In larger codebases it makes life much easier if consumers of library functions can see exactly what parameters they should pass.

Another big advantage is that including types enables the IDE to support code completion, which makes us more productive. Imagine if you have an entity with a large number of properties. How great to have code completion on those property names.

Do you think TypeScript might assist you in your JavaScript programming?  Would you like to reduce the number of runtime errors you have to remediate?  If so move on to Part 2 in the series, in which we will discuss how to use TypeScript in the SAP ecosystem. Part 3 will cover some tips to help you get started.