As the Lead Architect at Ackama, I want to share a short retrospective on our journey with Typescript and what the future might hold. We started using Typescript in production work in 2018. These days, it is our default for all front-end and serverless work (using the Serverless framework).

We are cautious about introducing dependencies for our client work. Our applications live a long time and we need to be confident that any new dependency provides significant value and has a long-term future. We never want a client to need to rewrite an app because the underlying technologies are outdated and/or it is difficult to find developers fluent in them.

Developer-led Adoption

Our usage of Typescript followed our usual process for developer-led adoption of a new technology, namely:

• Experiment: Build enough with it to understand its good and bad parts – all technologies have both.
• Advocate: Convince 1-2 other developers it’s worth pursuing.
• Present: Discuss with our architects group, covering pros and cons.
• Implement: If deemed worthwhile, use for internal tools and applications.
• Evaluate: Pause long enough for us to live with the maintenance consequences (if any).
• Deploy: Start using for production work and integrate into templates where appropriate.

Typescript had some strong internal advocates from the start. Some of the rest of us (myself included) needed a bit of convincing. Strong static typing has always had benefits but, depending on where you first experienced strong static types, your pre-conceptions of the costs can be quite different.

Happily, modern type systems are dramatically more usability focused than older systems. Type inference, good error messages and more are now the norm, and are stated goals of languages such as Rust, Swift and Typescript.

Whatever your feelings on types, Typescript itself is impressive. Adding a gradual types layer to Javascript that works well and is well liked is quite the feat of engineering and communication. I won’t rehash a comparison of Typescript and Javascript here – the pros and cons are extensively (and maybe endlessly) covered elsewhere on the Internet. Suffice it to say that we use it for the same reasons that everybody else does, namely:

• Big wins when refactoring
• Types enable code editors to be more helpful
• Catches some errors earlier than would otherwise happen. Types are not a substitute for tests but they do help.

The majority of the JS community has embraced types and most npm packages provide types now. For packages that don’t, our experience is that DefinitelyTyped (a community maintained set of types for packages that do not provide them) reliably fills the gap. Over the years we have evolved our internal tooling to smooth the adoption of Typescript. Our goal was (and is) to make using Typescript easier than not. Gareth Jones, our Head of Operations and go-to type whisperer led this work, which included:

• Making it part of our ESLint config
• Improving Typescript support in various open source projects e.g eslint-plugin-jest, DefinitelyTyped, Shakapacker, Jest, typescript-eslint
• Adding it to our application templates
• Generally supporting teams getting up to speed.

Looking to the Future

We are excited for the future of Typescript. Node.js recently announced experimental support for running .ts Typescript files directly. This is a very exciting development with the potential to simplify development workflows.

Javascript (and hence Typescript) is also likely to be the best supported dynamic language on new platforms such as Cloudflare workers and WASM platforms. WASM on the server is still nascent but we are watching it closely. It has the potential to become an exciting new way to deploy applications and augment existing platforms with custom code.

As our teams work across multiple projects, we (and our clients) get a lot of advantages from having a consistency in our tooling across projects. An area of active research for us is discovering or building a Typescript stack which gets us close to the productivity we currently get from Rails and Django for apps where a more monolithic approach is appropriate.