Omer Elbaz

Posted on Jun 22, 2022

Why you should learn TypeScript today

#webdev #javascript #typescript #beginners

1. TypeScript makes code easier to read and understand.

When you use TypeScript, you can see the types of variables and functions as you're writing your code. This helps you to understand what your code is doing and makes it easier to find bugs. type annotations also make it easier for other developers to understand your code.

2. TypeScript can help you catch bugs early.

Because TypeScript is a typed language, the TypeScript compiler can catch errors in your code before you even run it. This means that you can find and fix bugs more quickly, and your code will be more reliable.

3. TypeScript is easy to learn for existing JavaScript developers.

If you know JavaScript, then you already know the syntax of TypeScript. You can start using TypeScript immediately, without learning a new language. And because TypeScript is a superset of JavaScript, any existing JavaScript code will work with TypeScript without any changes.

4. The TypeScript compiler is available for free.

The TypeScript compiler is open source and available for free from Microsoft. You can use the compiler in any project, without paying any license fees. And because the compiler is written in TypeScript, it's easy to extend and customize for your own needs.

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open source.

Background

JavaScript is a dynamic language with a loosely typed system. This can lead to some issues as your code scales in size and complexity. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. This means that you can use TypeScript with any existing JavaScript code and be confident that it will run correctly. TypeScript also offers strong typing and other features that can make your code more robust and easier to maintain.
In this article, we'll take a look at some of the key features of TypeScript and how they can help you write better code.

Types

One of the most important features of TypeScript is the ability to define types for your variables, functions, and classes. By using types, you can add an extra level of safety to your code and make sure that you're always working with the correct data type.
For example, let's say you have a function that takes an array of numbers and returns the sum of all the numbers in the array. With TypeScript, you could define the type of the input parameter as follows:

function sum(numbers: number[]) {  }

This way, if you try to pass anything other than an array of numbers into the function, you'll get an error from the TypeScript compiler. This can help you catch bugs early on and make sure your code is always running correctly.

Classes

In addition to variables and functions, you can also use types with classes in TypeScript. For example, here's a simple class definition:

class Point {  }

You can then create instances of this class and specify their types:

let point1: Point = new Point();

By adding types to your classes, you can again catch bugs early on and ensure that your code is always running correctly.

Interfaces

In addition to classes, TypeScript also has interfaces which are used to define contracts within your codebase. Interfaces allow you to specify what methods and properties a class must have in order for it to be considered as implementing the interface.
For example, let's say you have an interface called Shape with a method called area(). You could then create a class called Square that implements this interface:

class Square implements Shape {  }

If you try to create a Square instance but forget to implement the area() method, you'll get an error from the TypeScript compiler letting you know that something is wrong.
This helps you avoid accidentally introducing bugs into your code by forgetting to implement required methods or properties

TypeScript adds optional types, classes, and modules to JavaScript.

TypeScript is designed for the development of large applications and transcompiles to JavaScript.

TypeScript adds optional types, classes, and modules to JavaScript. These features can be used by developers to help prevent errors in their code and to make their code more maintainable.

TypeScript supports tools for largescale JavaScript applications for any browser, host, and OS.

The TypeScript type system allows developers to catch errors during compilation time.

In this blog post, we'll take a closer look at the TypeScript type system and how it can help you write better code.

When you're writing code in TypeScript, you'll often see the following two terms:

Static type checking: This is the process of checking the correctness of your program at compile time.
Type inference: This is the process of automatically inferring the types of variables and expressions based on their usage.
Static type checking is what enables the TypeScript compiler to catch errors during compilation time. With static type checking, you can catch errors such as:

misspelled variable names,
calling a function with the wrong number or type of arguments,
accessing an object property that doesn't exist,
etc.

Type inference is what allows TypeScript to automatically infer the types of variables and expressions based on their usage. This is a big advantage over JavaScript, which doesn't have this feature. With type inference, you don't have to explicitly declare the types of your variables and expressions. The TypeScript compiler will automatically infer their types based on their usage.

For example, consider the following code:

let x = 3;     // The type of x is inferred to be 'number' 
let y = ""foo""; // The type of y is inferred to be 'string' 
let z = x + y; // The type of z is inferred to be 'string'

In this code, we don't explicitly declare the types of our variables x, y, and z. However, we can see from their usage that the types of x and y are 'number' and 'string', respectively. Similarly, we can see that the type of z must be 'string', since it's the result of adding two values with different types (x is a 'number' and y is a 'string').
Type inference is a powerful tool that can help you write cleaner and more concise code. In many cases, you won't even need to explicitly declare the types of your variables and expressions. The TypeScript compiler will automatically infer their types based on their usage.

Many popular libraries are written in TypeScript including AngularJS 2, Ionic 2, and Lodash

If you are interested in learning TypeScript, there are many resources available online, including the TypeScript documentation, tutorials, and webcasts. Additionally, there are many IDEs and text editors that support TypeScript development.

If you're not already using TypeScript, you're missing out on one of the best parts of the JavaScript ecosystem. Not only will TypeScript make you a more proficient JavaScript developer, but it also comes with a lot of benefits that can make your life easier. So what are you waiting for? Start learning TypeScript today!

Help us out by starring our Github repo!

And join the discussion in our Discord channel
Test your API for free now at BLST!

Top comments (9)

Mike Talbot ⭐ • Jun 22 '22

A very well put response Luke, couldn't agree more... I find JS (plus JSDoc) easier for projects that I'll mainly work on alone or in a small team and TypeScript beneficial when many people will work on the project.

peerreynders • Jun 23 '22 • Edited

Strangely enough it was Vite which significantly lowered the adoption barrier for me (I don't use VS Code).

esbuild's transform is so fast and the "To hell with the TypeScript errors, lets run this code now!" approach means that I don't constantly get stalled having to explain (right now, this very moment) to TypeScript what I'm doing. It's only once I get far enough into the weeds that I switch gears and go into "type linting" mode to shore up the work already done.

I do think there are two significant milestones in TypeScript competence:

type consumer
type producer

It's fairly easy to get to the "type consumer" level and that's typically all that's required when duct-taping dependencies together to "make a thing".

Maintainers of dependencies however need to aspire to the "type producer" level and that is quite a bit more work because TypeScript has a lot of concepts that other statically typed languages simply don't need (they aren't trying to bridge the gap to a dynamically typed language where it isn't unusual (and sometimes even desirable) for types to morph at run time).

The less you rely on dependencies and the more you are crafting bespoke capabilities, the more you need to push into "type producer" territory.

The one thing I still don't like is the pressure TypeScript places on coding style. Just recently I ended up this the tight ball of code:

async function rootAndRun<T>(
  timeoutMs: number,
  factory: Factory<T>
): Promise<T> {
  let disposeFn: (() => void) | undefined;
  let timeoutId;
  try {
    return await new Promise((resolve, reject) => {
      createRoot((dispose) => {
        disposeFn = dispose;

        timeoutId = setTimeout(function timeout() {
          timeoutId = undefined;
          reject(new Error('Timed out'));
        }, timeoutMs);

        // queueMicrotask/setTimeout allows `setup` to finish
        // before exercising the reactive graph with `run`
        const run = factory(function done(data, err) {
          if (data === undefined) reject(err);
          else resolve(data);
        });
        if (typeof run === 'function') queueMicrotask(run);
      });
    });
  } finally {
    if (disposeFn) {
      disposeFn();
      disposeFn = undefined;
    }
    if (timeoutId) {
      clearTimeout(timeoutId);
      timeoutId = undefined;
    }
  }
}

The JavaScript version was neatly pulled apart into separate functions

async function rootAndRun(timeoutMs, factory) {
  let disposeFn;
  let timeoutId;
  try {
    return await new Promise(executor);
  } finally {
    if (disposeFn) {
      disposeFn();
      disposeFn = undefined;
    }
    if (timeoutId) {
      clearTimeout(timeoutId);
      timeoutId = undefined;
    }
  }

  // ---
  function executor(resolve, reject) {
    createRoot((dispose) => {
      disposeFn = dispose;
      timeoutId = setTimeout(timeout, timeoutMs);
      // queueMicrotask/setTimeout allows `setup` to finish
      // before exercising the reactive graph with `run`
      const run = factory(done);
      if (typeof run === 'function') queueMicrotask(run);
    });

    // ---
    function timeout() {
      timeoutId = undefined;
      reject(new Error('Timed out'));
    }

    function done(data, err) {
      if (err != undefined) reject(err);
      else resolve(data);
    }
  }
}

When I started typing it, TypeScript was constantly complaining how the same T could end up being different types. It's only once I inlined the functions that TypeScript finally "got it".

So when people claim that TypeScript makes refactoring easier they simply mean that it (likely) rings the alarm bells when something doesn't quite line up after you moved some code around.

However I claim that TypeScript doesn't encourage refactoring—in the sense of authoring code that is broken down into easily digestible chunks.

TypeScript's type inference pushes you toward an "inlined" coding style (which I absolutely despise) because inlined code is easier on the type inference. If you want to break things down into sensibly named and sized chunks it penalizes you with a hefty explicit typing tax which most people aren't willing to pay—leading to heavily inlined code which the JavaScript ecosystem already has enough of.

Mike Rozner • Jun 29 '22

Type script made me a lover not a fighter

peerreynders • Jun 27 '22

So my "type parameters inside closures" needs more work; figures. The Maybe makes sense, I'm constantly surprised it's not with the utility types.

I just try to keep my functions small and make them do one job and do it right which makes them far easier to test, maintain …

I'm right there with you in terms of small and focused but I'm not prescient so it's far too easy for me to fall prey to premature reuse/abstraction—OO or functional.

Thank You for the assist!

John Peters • Jun 23 '22

I love working with TypeScript. It also taught me Javascript so now I know both.
When I build webcomponents I use raw Html and Javascript.

But when working on large applications, I use TypeScript. Intellisense is too good to ignore.

peerreynders • Jun 26 '22

TIL: There needs to be a comma after the type parameter for an arrow function otherwise TS thinks it's JSX.

const wait =
  (milliseconds: number) =>
  <Value,>(executor: Executor<Value>) =>
    new Promise((resolve, reject) =>
      setTimeout(executor, milliseconds, resolve, reject)
    );

The error message I was fighting:

"Argument of type T is not assignable to parameter of type T. T could be instantiated with an arbitrary type which could be unrelated to T."

CodeSandBox

Which seems to imply:

"The caller of the function specifies the type parameter, not the implementer"

If you refer back to my TypeScript version please note that I require Promise<T>.

Your version only gives me Promise<unknown>. The moment I put Promise<T> on rootAndRun() everything lights up red. The Promise<T> based on Factory<T> was the point of making rootAndRun() generic.

For Promise<unknown> we don't need generics to begin with. CodeSandbox

unknown is extremely useful under very specific circumstances but when overused it reminds me of the Java pre-Generic Object fiasco in terms of type safety.

that could be reused

How OO of you 😁

In this case reuse isn't the goal as this is only for testing support, so not being coupled via reuse (Beware of the Share) is a good thing.

Also in general I try to stick to the Rule of Three:

You must have looked at at least three systems to understand what is common across them (and therefore reusable)
It takes three times as much effort to make something reusable as to make it usable
You will receive payback after the third release.

In this case the goal was to "unroll" it enough to make it more understandable.

GitRog555 • Jun 28 '22 • Edited

Using a timescript is a sign of the coder's respect for other developers, it is a sign of the programmer's maturity and high level of team responsibility. For me, one source was an example of using a timescript; their authors do my programming homework with understandable hints and clarifications in the code.