It's 2018, and it's time to use TypeScript

TypeScript can have a profound, positive effect on making complex JavaScript codebases easier to maintain. You definitely should be using it, regardless of where you sit on the static vs dynamic-typing debate.

It’s 2018, and it’s time to use TypeScript One of the best things I’ve done this year is starting to push for moving everything over from JavaScript to TypeScript. The difference it makes on the maintainability of codebases simply cannot be understated.


The controversy around TypeScript comes from that fact that JavaScript is powerful precisely because it doesn’t have any static typing. It’s easy to read the statement “you should use TypeScript” as “JavaScript is bad, because it doesn’t have static typing”.

JavaScript is everywhere, and that tells us that it solves a significant problem. Software developers are lazy people, and if something is fiddly or fussy to use, it won’t get used. Ipso facto, JavaScript must be good.

The reason why JavaScript is so good is because as a language it is so expressive. It’s also highly forgiving, and simple. (It is, crazily, a bit like Visual Basic.) In today’s modern development environment, it’s particularly good at operating like a kind of “glue” allowing loosely-connected, disparate systems to be strung together.


The problem with JavaScript is that any application bigger than a proof-of-concept becomes impossible to maintain. (This was, I might add, the same problem with Visual Basic.) That very flexibility it gives you through its dynamic typing that provides that “everything is an object, and anything can have any property”, makes it a nightmare when you go back and read it at some point in the future. Just what does that xyz call return? What’s the URI for the zyx call? When I make that call, what values do I get back? Every POST payload is a lump of JSON-encoded data, and so is every return value.

A statically-typed language requires you to lay out ahead of time how everything is put together. The advantage of this static typing is that you can get very good design-time intelligence about how everything is put together, particularly if you have access to Roslyn.

The problem with static-typed languages is that you don’t necessarily need all this overhead. It’s not very fluid. You’re trying to move around and modify data – parts of your system may translate well to some sort of object model, but other parts will not. And in any system, some parts of it will benefit from a strict object-modelling approach, and other parts will not. Statically-typed languages compared to dynamically-typed languages require the direct opposite compromises compared to each other. JavaScript is lousy for object-modelling, and C# (or Java), or lousy for things that don’t map onto objects.


The problem comes from the fact that, regardless of how much you’d like to get away from it, we still need to map things down to columns and rows in relational databases. There will always be a Customers table, an Invoices table, and so on, and we’ll be finding ever more ingenious ways of returning a set of customers back from a server and putting them on the screen. There will always be, somewhere, a Customer class, and a property on it called LastName. Or, was it Surname? Or did someone else up calling it Lastname?

And that is the problem that makes JavaScript so unmaintainable, and it’s also the number one reason why you should be using TypeScript. With a static, design-time definition of exactly what a customer is, and what it looks like, you will find maintaining that code less arduous.

TypeScript works extremely well is in allowing you to model what the underlying structure of your data looks like, system-wide using static types. You don’t have to do everything – you can pick and choose whether other aspects of your system would benefit from having some sort of “pre-set definition of intent”. This is the advantage of TypeScript – you can use it to “season” the codebase with some static types when it makes sense for you to do that, and use vanilla JavaScript when you do not.

To use the example above, you can create an interface in TypeScript called ICustomer that specifically has a LastName property. You can then create a proxy class that returns an array of ICustomer interfaces. Anyone using this then knows exactly what they are getting. This may not seem like a huge advantage whilst you are actually building the system – the benefits come when you come back to do maintenance in six months time.


In reading around for this piece, there is substantial debate around this topic. This debate tends to look at the issue from the perspective of initial development. The advantage isn’t there – it’s in maintenance. It is straightforwardly logical to “document” in some way what the system components that you are interfacing with look like, and TypeScript allows you do to that very inexpensively.


Our evolving "Digital 247" Software Architecture Methodology helps us guide our technical leadership. We maintain it in two forms — a benchmark that you can fill out to get a feel as to where you are with regards to your peers and competitors, and a 7,000-word downloadable white paper that is free to download and is full of helpful information and advice.


Social Media