Why we chose and why we don’t switch away from TypeScript?

Written by Dmitri Gabbasov

In this post we are going to explore the reasons why we have chosen TypeScript as our main development language at Sixfold and why we are happy with it.

Thank JavaScript

Even before TypeScript came into existence, JavaScript had already been, for a very long time, the only language natively supported by one of the most important interactive content delivery channels — the Web. Or rather by the programs that people use to access it — web browsers.

JavaScript implements a specification that defines a language called ECMAScript. For all practical purposes, the two names refer to the same thing. JavaScript was simply the name of the original implementation, and ECMAScript was the name chosen later when a specification was produced. Brendan Eich — the creator of JavaScript — has called ECMAScript “an unwanted trade name”.

The ECMAScript standard, first published in 1997, reached its 5th edition in 2009. The development of this edition took a long time and involved disputes between the two major contributors — Netscape and Microsoft.

Throughout the process, features like classes, modules and even static typing were already discussed, however, none of them actually made it into ES5. If you are interested in the history of ECMAScript then I suggest you read this paper by Brendan Eich and Allen Wirfs-Brock.

The next major update (6th edition) came in 2015, finally introducing classes, arrow functions, modules and some other things. It took web browsers considerable time to catch up with the specification, and so JavaScript transpilers entered the scene.

One could write modern JavaScript and have it transformed into ES5 as part of the build process. However, people wanted to use the new language constructs even before ES2015 was published. This lead to the creation of multiple alternative languages that could be compiled to ES5. Among them were for example CoffeeScript (released in 2010) and TypeScript (released in 2012).

Since 2015, the ECMAScript standard has continuously evolved, releasing a new edition every year. Similarly, other web-related technologies and standards were also evolving rapidly. Various APIs were being added that gave web pages more and more power (e.g. <canvas>, <video>, History, Storage, File and Blob, Crypto, WebRTC).

There were also significant improvements in JavaScript engines. In 2008 three major JavaScript runtimes started compiling JavaScript to native code. V8 (Chrome) came out that year with Just-In-Time (JIT) compilation support from the get-go. SpiderMonkey (Firefox) gained JIT compilation support through a new engine called TraceMonkey. And WebKit (Safari) started generating native code in its next generation engine called SquirrelFish Extreme. Opera and Internet Explorer followed suit in 2009. These improvements constituted a landmark advancement in the history of JavaScript engine performance.

Lastly, Node.js was released in 2009, eventually becoming a popular server-side stack choice.

All this naturally lead to larger and more sophisticated JavaScript codebases. Nobody could any longer cast a shadow on the fact that JavaScript was one of the most popular languages at the time. You can also see this from the StackOverflow developer survey of 2013:

SO Survey 2013. Share of respondents that are proficient in a given language.

Also, here is some reasoning provided by Anders Hejlsberg — one of the creators of TypeScript — back when TypeScript was released in 2012:

Over the last five years we’ve increasingly heard from customers that writing application-scale JavaScript is just too hard.

JavaScript was created as a scripting language. It wasn’t designed to structure medium- to large-scale code bases such as classes or modules. JavaScript is an entirely dynamic language that has no static typing, and static typing is really the thing that powers today’s rich IDEs.

What we like about it

Why Node.js? Well, that question warrants an entire blog post of its own. Maybe we’ll write about that in the future. For now, here are some of the key things that our engineers like about TypeScript.

IDE support

Actually, the fact that TypeScript ships with a language-server-like module, which allows clients to query information about symbols and perform refactorings by sending messages over a TCP socket, has probably made it easier for various IDEs and text editors to so quickly provide full-fledged support for the language. Compare this with older languages where an IDE would need to essentially reimplement the compiler for every language it wants to support.

The available type information also makes it easier to explore new APIs, as well as use familiar ones, by way of showing auto-complete and parameter information popups.

Type checking

It is a well known idea, that the earlier a bug is discovered, the cheaper it is to fix it. Being able to detect errors during compilation, or right inside your IDE as you type, can therefore help avoid many costly mistakes.

Gradual typing

It is also possible to migrate an existing JavaScript codebase to TypeScript one file at a time. So you don’t have to rewrite all your code at once, instead you can start by ensuring that all new code is written in TypeScript, and then, piece-by-piece, migrate the old.

Familiarity

Readability

Additionally, types also serve as documentation. Indeed, it is common in JavaScript to include type information inside JSDoc comments. The TypeScript compiler can even make use of those comments and extract type information from them, making the whole experience even smoother.

Typed libraries

It is also one of the features that set TypeScript apart — being able to create “library type definitions” for existing JavaScript code. This means the typing information can live independently from the actual library code, allowing types to be defined even for abandoned or otherwise inaccessible codebases.

Documentation

Big company backing

What makes it harder to like

Strictly JavaScript

The proper way to get such features is to propose (and champion) them in the ECMAScript technical committee (TC39). In other words, these features should be added to the JavaScript language first. A good example of this are the nullish coalescing (??) and the optional chaining (?.) operators. The latter in particular had been a requested feature in TypeScript since 2014, but was not implemented until November 2019, after it had become a stage 3 proposal in TC39. The proposal was then accepted into ES2020.

Advanced type system

Also, TypeScript’s type system is quite advanced and allows to do various “tricks” that are not possible elsewhere. For example, union types make it possible for a property or variable to have multiple types, which can be discerned, if necessary, via various operations. Mapped types allow transforming one type into a different looking one, by applying certain transformations to it. All this can initially stump developers who have worked with other languages in the past.

Unsoundness

Since the beginning TypeScript has tried to strike a good balance in this matter — being as sound as possible, without forcing users to write complex code. In fact, soundness in TypeScript is highly configurable through various “strictness” flags, which turn certain language features on or off. Ideally, one would write TypeScript code with maximum strictness turned on, which we also do here at Sixfold.

A few times however, we have encountered errors at runtime, that we wish were preventable at the type level. These issues typically have something to do with the more “forgiving” aspects of the type checker, such as indexed property accessor types (think someArray[i] not including undefined in its type), and the lack of distinction between optional properties and required properties with undefined in their type.

Final words

Taking the plunge and adding your own types leads to code that is more robust, often easier to read and faster to work with in modern IDEs, all the while remaining familiar to anyone with JavaScript experience.

Sixfold is Europe’s leading real-time transportation visibility platform, solving supply chain visibility challenges for the world’s biggest companies.

Sixfold is Europe’s leading real-time transportation visibility platform, solving supply chain visibility challenges for the world’s biggest companies.