rob.rho.org.uk

At work, we use web technology for something a little unusual — delivering realtime augmented reality to operating rooms to support image-guided surgery. We’re constantly looking for ways to stay on top of the complexity involved, whilst still being able to add new functionality. To this end, we just migrated this from vanilla JavaScript to TypeScript, the statically typed variant from Microsoft Research that’s just hit 2.0. All in all, I’ve been very pleased with the results.

For those of you not familiar with it, TypeScript is essentially a superset of ECMAScript 6, with a type system added on. The decision to base the language on ECMAScript, rather than just using it as a compilation target, gives a far clearer migration path — you can simply change the extension on your existing source file and start adding type annotations. Compared to the prospect of a complete rewrite, this makes migrating an existing code base a far less… courageous endeavour.

Another benefit is that you get to use all of the nice features of ES6 (lexical let and const, arrow functions, default arguments) without having to worry about support on various platforms (the TypeScript compiler takes care of it). On the other side of the scales, it’s true that TypeScript inherits all of JavaScript’s flaws. However, I quite like JavaScript, especially the recent versions. Moreover, the vast majority of the issues that remain (numerical representation, limited tooling, anaemic standard library) are characteristics of the environment rather than the language itself.

The idea of glomming a type system onto a formerly dynamic language is one that could go horribly wrong, but TypeScript does a very good job of it (unsurprisingly, given it’s pedigree). Firstly, the type system is gradual; by default, things get the permissive any type, so your unmodified JavaScript will work out of the box. Once you’ve annotated everything, you can turn this default off to keep everyone honest.

This doesn’t mean you have to have annotations for every function and variable, though; like any modern language worth its salt, it uses type inference to fill in the blanks. The type system also supports algebraic types, including (in TypeScipt 2.0) discriminated unions. If you tend towards a functional rather than object oriented style anyway, the result is something that feels very much like an ML for the working programmer.

While TypeScript has a lot of details that I like, there’s one feature in particular that has won me over: strict null checks¹. This means that, if the type system says that something is a string, it’s actually a string; it can’t be null (or undefined). This eliminates a pervasive flaw in JavaScript, and indeed almost all other languages that use reference types (Tony Hoare called it the “billion dollar mistake”). If a null value is a possibility, you have to account for that, or your code won’t type check. The impact of this seemingly simple change is immense; in fact, I’d recommend adopting TypeScript on the strength of this feature alone.

The only significant snag we hit in moving to TypeScript is the build process. We try and keep third party dependencies to an absolute minimum, which meant we’d previously been able to get away with a very minimal build system based on RequireJS. With TypeScript introducing a mandatory build step, we decided to bite the bullet and go with something more fully featured.

We picked webpack, and while we have a system that works I’ve not been particularly impressed. On the plus side, it’s allowed us to adopt SCSS, and supports things like source maps. However, it’s a prime example of the JavaScript community’s tendency to have hundreds of micro-dependencies. This isn’t a deal breaker for us in this case, as they’re development rather than runtime, but is still far from ideal. Related to this, much of the functionality (even basic things, such as returning a failing exit code if one of your build steps doesn’t work) is in the form of third party plugins. The TypeScript plugin we’re using seems to be having some kind of configuration turf war with the compiler’s own configuration system, which means we can’t benefit from a lot of the deep tool support that the latter provides.

The specific issues we’re seeing are relatively minor, and I expect that we’ll solve them with a little tweaking. The underlying problem will still be there: there seems to be an unnecessary amount of accidental complexity to solve a relatively simple problem. This isn’t just webpack, though — we went with it because it looked like the least bad JavaScript build system. If we replace it with anything, it’ll be good old-fashioned make (“the worst build system, except for all the others”).

When compared to more established languages like Python, the JavaScript landscape is, to put it mildly, somewhat turbulent. Innovation and pace are valued over stability and rigour. However, as the web platform is used for more and more critical things, this is starting to change. TypeScript is definitely a move in the right direction.