Why do we need TypeScript in EBO?

This article describes why we should invest our resources into TypeScript and do it now.

What problems do we have in EBO?

Interfaces for programming entities are not defined properly

Ebury Online and Chameleon are complex projects with lots of legacy code(Marionette, Vue Options API etc) that will be replaced with modern ones, and all the frontend code is written in JavaScript. It means that we can’t precisely say what is the interface of a particular programming entity without spending time investigating the structure of the code. A simple example is a parameter of this function.

function someFunction(someParameter){
  return someParameter.a;
}

Here we have yet to learn what someParameter is. Is it string, Object, number or something else? Moreover, even though we know somehow that this is an Object, we have yet to learn what is the structure of that object. What properties does it have, and what are those properties types?

This lack of definition leads us to confusion due to the development process, spending time to solve that confusion and even after all that, we still have no description of the function interface. It means that next time another developer will spend additional time solving the same confusion.

Example with TypeScript:

function someFunction(someParameter: {a: string}){
    return someParameter.a
}

After this change, TS will track all usages of this function in TypeScript code and notify us about errors. Moreover, our developer tools will become robust with precise code completion, prompts and documentation support.

We can’t use interface definitions of third-party libraries and tools

In our code, we use some libraries and tools such as currency.js, for example. Almost every of those has type definitions that could help our team track changes and refactor code according to those changes. Otherwise, those changes should be found manually by our developers which takes more time.

We can’t introduce schema contract between the backend and frontend

Despite potentially having an API and entities schema that can be provided by an Graphql endpoint for example, we won’t be able to use it on our frontend correctly because JavaScript doesn’t support type checking natively. As a result we can’t use the schema to confirm that our frontend code supports the established contract in CI or with pre-commit hooks.

Legacy code migration is challenging.

Legacy code migration is complex because we have to be confident and sure that we’ve considered all cases and usages and covered them in the new code. We have to do that manually, yet with TypeScript, it can do that for us as it won’t compile correctly if the code is not compliant.

What will TypeScript bring to us?

Strict program entities interfaces

As TypeScript is a strongly typed programming language, it will bring this typing support into the EBO.

Better tooling support

TypeScript is the leading strongly typed language in the Frontend ecosystem. Moreover, according to data from https://madnight.github.io/githut it’s fast growing popularity and, in the nearest future, will be above JS by PRs and Pushes on Github. Today TypeScript has outstanding support in IDEs and in most of the development tooling. We use VueJS as a frontend framework and have recently moved to version 3, which is written in TypeScript, so it has the best TypeScript support from the core VueJS team.

Below there are charts about TypeScript and JavaScript tendentious. We can see how JS is losing its popularity and TS is gaining. Diagram - Edit Trade Request Diagram - Edit Trade Request

The State of Frontend 2022 survey shows that 84% of respondents used TS. Diagram - Edit Trade Request

https://newsletter.pragmaticengineer.com/i/83341079/technologies

Better new team member's adaptation

As TypeScript brings typing, interface declaration and code documentation, new members will dive into the project more smoothly and faster, especially the Senior Level developers and those familiar with TypeScript.

Hiring advantage

In the next few years, TypeScript projects will become a hiring advantage over JS projects as the number of developers familiar with it increases, and the willingness to use it will increase too. Further JS usage as the primary language may lead to a hiring disadvantage, especially on a big project.

What do we need to introduce TypeScript in EBO?

Prepare infrastructure

  • One-time TypeScript setup(compilation, linting, build) in Chameleon and EBO
  • Add documentation about using TypeScript in new code and how to migrate legacy.

Move legacy and use TypeScript in new tasks

  • Incremental migration of Chameleon and Eburyonline codebase to TypeScript
  • Define API contract between frontend and backend and use types from that contract in the frontend and backend code.

The dark side…

There are cons too.

  • The necessity for our team to learn another language: although TS is an extension of JS, it has an extended type system that developers need to know.
  • The longer development process at the start of using TS in our projects