Why to use a static type checker when building JavaScript apps

Lessons learned building complex web and mobile applications based on JavaScript.

Giacomo Alonzi

Developer

JavaScript is one of the main technologies we use in our projects. It has evolved over the years from a simple scripting language to a real development environment, suitable for creating increasingly interactive and complex web applications.

The rise of complexity

The spread of rendering libraries such as React has accelerated this transition, allowing the development of client-side websites and applications using a declarative (i.e. the programmer focuses on the “what” and not the “how”) and component-oriented paradigm. Today JavaScript is no longer just the language used to manage user interface interactivity, but also to generate much of the HTML markup that makes up the pages of a web solution.

As the code becomes increasingly complex, the likelihood of bugs, often concerning trivial aspects of programming and therefore easily avoidable, increases accordingly. For example, they may involve passing an incorrect parameter to a function – perhaps because it’s part of an outdated portion of code or the result of another developer’s unreadable contribution.

A static type checker to the rescue

To solve this type of problem, in some projects we have adopted the TypeScript language. It is an open source technology, developed by Microsoft, which allows you to extend the functionality of JavaScript by adding a type system. What’s special about TypeScript is that this technology signals the occurrence of errors when writing code, before it runs at runtime.

When designing React components, for example, we use TypeScript to define the type of values that the function or class expects as parameters. By working in this way we reduce the probability of bugs by reporting an error in the code in advance and – no less important – we write a “living documentation” of the code, which can save us a lot of time when we come back to work on it after a while, or if other developers get their hands on it later.

Using TypeScript in a project is a bit like having a person by your side correcting you and alerting you to problems as you write an application’s code.

Do it early

In the past we’ve had to start a web development project without being able to include a type checking system: at the beginning we didn’t experience any particular problems, but as the codebase expanded and new developers were added to the team, the number of bugs and the time needed to reuse existing components and functions increased. Using TypeScript (or another type checker) at the start of a new project is good practice in order to avoid getting in trouble when complexity inevitably increases later on. To be frank, using a static type checker generally means more work for the programmer, because they will have to design the type management for each feature to be implemented in advance; however, the additional effort will be largely repaid in the future by fewer bugs and the ease of reading old portions of code.

TypeScript & Flow

In addition to TypeScript, we have gained experience using Flow, an open source static type checker created by Facebook. In this case it is not a programming language, but a simple library that can be installed in the local development environment. It is really difficult to say which of the two solutions is the best: both have strengths that distinguish them. Flow, being an add-on to the normal development process, represents a less radical change than the adoption of a new programming language (such as TypeScript), although this represents a JavaScript superset (i.e. a component capable of extending its functionality). Another aspect that could affect the choice is the greater popularity of TypeScript, which translates into greater support from the development community.

These are the reasons why, when developing new projects strongly based on JavaScript, we suggest adopting a static type checker such as TypeScript or Flow – thereby minimising the number of bugs and making it easier for other developers to read the code.



    Press ENTER

    We will use the data you share with us only to reply to your information request. Read our privacy policy

    Something went wrong, please contact us by email

    Proceed

    press ENTER

    Thank You

    We'll be in touch soon.