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 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
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.