Over the last few years, TypeScript has emerged as a powerhouse in the frontend world, helping teams build and maintain large, complex frontend software projects across a variety of frontend technologies.
At Ionic, we’ve gone all-in on TypeScript, building not only our flagship Ionic Framework in TypeScript, but building customer dashboards, utilities like Stencil, and product documentation generation tools, all based around the language.
After a few years of investing in TypeScript, we’ve experienced both the predictable benefits of incorporating static typing, but also a number of surprising advantages, both in terms of engineering and our business. I’d like to reflect on some of those surprising benefits of building a company around TypeScript.
Benefit #1: Static Typing
At the core, TypeScript simply brings static typing at build time to JavaScript. So, any benefits of a traditional static typing system when it comes to code quality, refactoring ability, and maintenance, are to be expected with TypeScript.
I think it’s safe to say that TypeScript has been a boon to our frontend engineering in this regard. Our first version of Ionic Framework was written in ES5, and development and maintenance was quite a bit more challenging without the static type system. I don’t think any on the team would ever go back to that. We now use TypeScript in our open source Framework, CLI, tooling, and increasingly frontend commercial products as well, across a variety of frameworks and un-frameworks.
Beyond typing, I find that our TypeScript code bases tend to be more homogenous, making it easier to move between projects and to spin up engineers. This could be a side effect of modern JS being a bit more prescriptive, but it’s a nice side effect.
None of this is surprising, so let’s move on to the more interesting second-order effects.
Benefit #2: Free Documentation
Static typing for engineering is awesome but widely understood at this point. One of the surprise benefits of using a statically-typed language like TypeScript on the frontend is being able to generate rich documentation for a code base essentially as a side effect of all the type metadata in your code.
Java/C# developers would laugh at this as they’ve had auto doc generation for years, but this hasn’t been widely distributed on the frontend. Tools like jsdoc and the like worked on cumbersome comment-doc requirements, forcing developers to create a lot of extra annotation work on top of their existing code just for documentation purposes.
In contrast, simply by using the language, rich documentation can be generated from any TypeScript codebase easily, either through custom Compiler API tools (see next point), or ready-made ones like typedoc.
Here’s an example of a TypeDoc generated reference site that is good enough for teams that don’t have time to customize it more.
Here’s an example of a fully custom documentation generation process using the Compiler API (see next point). This is generated by walking the AST and outputting HTML.
Benefit #3: Tooling
Unlike traditional statically-typed languages like Java and C#, TypeScript ships with a first-class Compiler API, exposing the parsing and AST-generation engine of the language. This API can be used for walking the Abstract Syntax Tree (AST) of the language, and for modifying the code on the fly.
We’ve used this API in a lot of different ways, including generating documentation (building bespoke doc generators is easy with this API, see link at end of last section), building utilities like Stencil that sit between your TypeScript build and the transformed output, generating framework-specific bindings for Ionic Framework by walking our type information and generating react/vue/etc. bindings, and for loading type information about libraries into our products.
This is probably the #1 under-appreciated feature of TypeScript, and I hope the project improves the documentation of this feature, as there is a wealth of opportunity for tooling authors.
For those curious about how this API works, the Stencil code base is filled with examples of using this API, and given that this API is relatively obscure, Adam Bradley is always teaching me new tricks that aren’t in the documentation.
Benefit #4: Product
The last big benefit actually impacts Ionic the business in a very material way, though that may be because our business is in the developer tool world.
The first big benefit is that TypeScript has seen incredible adoption in mid-to-large Enterprise companies (which makes sense, Enterprises love statically typed languages). This is great for Ionic as we can speak their language and easily ship code they can use and understand.
Beyond that, we’ve been working on a visual development tool that lets developers easily add arbitrary Web Components to the designer as long as they have TypeScript types for them. This lets us offer a non-proprietary component model that currently doesn’t exist in the market (all of our competitors have custom component models that only work in their tools/technology).
By providing a .d.ts file, we can pull out all of the props and attributes for the component, allowing the user to pull this component in and easily customize all the available properties for the control. Since TypeScript ships with a bunch of HTML5 components already typed, we can import those easily as well!
It remains to be seen how this one will play out, but the moment I realized that the language we picked had given us a tangible product benefit, I realized that TypeScript brings so much more to the table than just static typing during development. The information TypeScript adds to your code has so much value beyond type checking!
I don’t think we’re alone in this, either. Some of the key features in Angular, for example, rely on having rich types available in your code. (fun fact: Angular was the reason our team got into TypeScript in the first place. Thanks, Angular Team!)
Never Looking Back
Are you on the fence about incorporating TypeScript into your team’s frontend stack? If so, I think it’s important to think beyond the static typing benefits during development, to the rich tooling and self-documenting capabilities, and the expanding tooling ecosystem that understands TypeScript types and can help you do more with your code base.
I was not sold on TypeScript at first, thinking it would get in the way of development and force rigorous typing that would add unnecessary overhead. What I discovered instead was a language that hit the sweet spot between typing and type inference (sorry Java), while offering so many other benefits. I appreciated that TypeScript could be as typed or as untyped as you wanted, and it would still add value.
I’m completely sold now on using TypeScript for every single frontend project I ever work on and for every project we build at Ionic. Thankfully, it’s not a hard sell, since nearly everyone working on frontend projects here adores TypeScript.
Has TypeScript has helped your team beyond type checking? I’d love to hear your story in a response below!
