How TypeScript Won Over Developers and JavaScript Frameworks
Initially created at Microsoft and then released as an open source project under the Apache License 2.0, TypeScript is often described as a “superset of JavaScript” or “JavaScript with types.” Since its announcement in 2012, it has become the dominant player among JavaScript “flavors” according to the 2020 State of JS Report (it was used by 78% of respondents). It was also the third most loved language in the recent Stack Overflow developer survey, behind only Rust and Clojure.
TypeScript comprises four components: the programming language itself; a type checker providing optional static typing for JavaScript; a compiler which turns TypeScript code into JavaScript code; and a language services program that uses the type checker to tell editors, such as VS Code, how to provide helpful utilities to developers.
Many of the early adopters of TypeScript were the JavaScript framework developers, in particular the teams behind Angular and Dojo. “Fundamentally where TypeScript was first interesting to me was that it introduced interfaces to the language,” Dylan Schiemann, CEO of Living Spec and creator of the Dojo framework, told The New Stack.
“Without an interface definition you can’t safely swap a dependency because you don’t know what the dependency is supposed to be doing,” said Schiemann. “So if you were a framework author or building a large app, you had no control of whether something would behave in the way it had before. We’d been bitten by that, so Dojo was an early adopter of TypeScript for that reason.”
Static Typing
TypeScript’s support for static typing shouldn’t be underestimated either. JavaScript is still dynamically typed, which can lead to a variety of hard-to-catch bugs in larger codebases. The Vue framework, for example, is 100% built with TypeScript as of version 3, with the official documentation stating that “a static type system can help prevent many potential runtime errors as applications grow, which is why Vue 3 is written in TypeScript”.
“When the world shifted to ES6, they also shifted to TypeScript.”
-Dylan Schiemann, CEO of Living Spec and creator of the Dojo framework
In 2015, Google decided Angular 2 would also be built using TypeScript, citing static typing as one of the reasons. Ryan Cavanaugh, the principal engineering lead for the TypeScript language at Microsoft, believes this was a major spur for wider TypeScript adoption. In a discussion with Ryan Donovan of Stack Overflow, he said:
“…if you look at the graphs for TypeScript, literally any graph — GitHub stars, downloads, pull requests — you can see the exact point when that Angular announcement came out. And the graph just changes. It never looks back. You can’t see that little bend in the curve anymore because the curve kept going. That was a real inflection point.
And I think it’s been interesting that people thought at the time that TypeScript was going to be just what Angular people use and not much else. That didn’t turn out to be the case. Obviously, we’re still popular among Angular devs. But that was a real momentum builder for us.”
Conversely, Schiemann believes that it was the arrival of ECMAScript 6 that triggered the tipping point: “I think that when the world shifted to ES6, they also shifted to TypeScript, because they said, ‘well if I’m going to go this route, let me look at TypeScript while I do this.’”
The Importance of Community
In Schiemann’s view though, Microsoft’s management of the community is even more important.
“If the TypeScript folks were at all untrustworthy as a team, I think people wouldn’t have adopted TypeScript,” he said. “The thing is that with Anders [Hejlsberg] you have this person who’s super smart, but super approachable. And the whole team is like that — they are like the most humble, unassuming team I’ve ever worked with, with that level of technical aptitude.”
Schiemann explained that when the team behind Angular first started using TypeScript, they forked it to add a feature they needed called Decorators. Seeing this, the TypeScript team reached out and suggested they work together to add the feature into TypeScript itself.
“And then when React became more widely adopted, the TypeScript team said, ‘well, how about we work with the React ecosystem to help make TypeScript better to work with React’, and then they did a similar thing when Svelte started to gain popularity. So they do a good job of reaching out to frameworks and saying, ‘Hey, how can we support you?’”
This reaching out has paid dividends, with the Svelte team (like Vue) adopting TypeScript for their version 3 release. Even at Facebook, which has its own Flow JavaScript type checker, TypeScript is increasingly being used — including for projects like the JavaScript testing framework Jest.
Developer Tooling
Microsoft’s emphasis on community also extends to developer tooling; another reason the Angular team cited for their decision to adopt the language. Microsoft’s own VS Code naturally has great support for TypeScript, but the TypeScript Language Server provides a common set of editor operations — like statement completions, signature help, code formatting, and outlining. This simplifies the job for vendors of alternative IDEs, such as JetBrains with WebStorm (and some of their other IDEs).
Ekaterina Prigara, WebStorm project manager at JetBrains, told the New Stack that “this integration works side-by-side with our own support of TypeScript – some of the features of the language support are powered by the server, whilst others, e.g. most of the refactorings and the auto import mechanism, by the IDE’s own support.”
The availability of the TypeScript Language Server reduces the development burden for tool makers.
The details of the integration are quite complex. Continued Prigara, “Completion suggestions from the server are shown but they could, in some cases, be enhanced with the IDE’s suggestions. It’s the same with the error detection and quick fixes. Formatting is done by the IDE. Inferred types shown on hover, if I’m not mistaken, come from the server. But there’s always a fallback provided by the IDE in case the server takes too long to respond.”
However, the availability of the TypeScript Language Server still reduces the development burden for tool makers. Because of this, it is used by a large number of tools and frameworks — e.g. ESLint for type checking, and Vue for it’s Typescript support. Indeed the tooling angle is so important that, according to Schiemann, “the TypeScript team won’t ship a feature that can’t be made fast enough for an IDE”.
Moreover, because TypeScript is a compiler, it can compile a codebase to support older browsers and environments. Add to this a linter and the built-in support for documentation, and it is easy to see why TypeScript is so compelling. “At this point I can’t imagine really writing anything significant without it,” Schiemann said, “because it just helps me write clearer code that is easier to maintain.”
Not Your Father’s Microsoft
Given Microsoft’s history with open source, it is interesting to reflect on how we got here.
When TypeScript first launched, the TC-39 committee — which is responsible for maintaining and developing the definition of JavaScript — had failed to reach a consensus on ECMAScript 4. This was partly down to Microsoft: Allen Wirfs-Brock, Microsoft’s representative on the TC-39, viewed the language as too complex for its own good, expressing concern about “the ability of the web to ‘digest’ such large changes”. JavaScript tools like Dojo, JQuery and MooTools dominated the web development landscape in 2012, but writing large-scale applications in JavaScript remained challenging.
The reason for this, according to Anders Hejlsberg, was that “JavaScript was never really designed to be a programming language for big applications. It’s a scripting language. It doesn’t have static typing, but more importantly, perhaps it lacks some of the structuring mechanisms that you need in large applications, like classes, modules and, perhaps, interfaces.”
As Hejlsberg notes, a popular option at the time was to leverage existing mature ecosystems and then transpile the application to JavaScript. Perhaps the best-known example of this was Google Web Toolkit (GWT), which leveraged the Java ecosystem, allowing developers to write code in Java and work with IDEs such as Eclipse and IntelliJ. ScriptSharp took a similar approach for developers wanting to use C# and the .NET ecosystem.
The challenge was that if you wanted to leverage anything from the JavaScript ecosystem, you first had to encapsulate it; and, as Hejlsberg puts it, “you’re sort of at an arm’s length at all times from the thing that you are targeting.”
Since TypeScript is based on JavaScript, any JavaScript program is also a valid TypeScript program.
One solution would have been to add things like classes and modules to the language, but this isn’t the straightforward win it might, at first sight, appear to be. Like software architecture, language design involves a complex set of tradeoffs. JavaScript’s early success was at least in part down to the fact that it was relatively easy for web designers to pick up and build working scripts with, even if it was a difficult language to really master. By adding features to support larger codebases, you also increase the learning curve and make it harder to use for the simple scripting tasks it was originally intended for.
Rather than changing JavaScript itself, Microsoft’s solution was to build a new language on top of it, adding the things they saw as missing for developers working on more complex applications — such as static typing, classes and modules — and leaving JavaScript as a simple scripting language for those who needed that.
This meant that TypeScript could still benefit from the broader JavaScript ecosystem. Since TypeScript is based on JavaScript, any JavaScript program is also a valid TypeScript program.
And, of course, being open source made it possible for a community to develop around the language.
Still, it was easy at the time to be skeptical. Microsoft had earned itself a bad reputation in the open source community. In 2001, Microsoft’s then CEO Steve Ballmer declared that “Linux is a cancer.” The company sponsored SCO’s copyright attack on Linux, claimed that Linux violated unnamed Microsoft patents, and forced Linux-based Android vendors to pay for dubious patent claims.
The TypeScript team has joined TC-39, becoming part of the broader community trying to improve JavaScript.
Long-term industry watchers will also remember Microsoft’s use of “embrace, extend, and extinguish”, particularly in the second half of the 1990s, leading to deliberate browser incompatibilities, preventing Office documents from being rendered properly in browsers other than IE, and breaking Java’s portability.
By contrast, the TypeScript team has now joined TC-39, becoming part of the broader community trying to improve JavaScript, rather than seeking to replace it. Moreover, TypeScript has always been run as a proper open source project. When dealing with issues, JetBrains’ Prigara told me, “We mostly rely on the publicly available info (roadmap, issues, commits) on GitHub. We have a contact for their PM, but in general we would prefer to file an issue on GitHub.”
Schiemann agreed. “One thing the TypeScript team told me,” he said, “was [that] when they fully embraced open source, they’d still get enterprise requests like, ‘can you add this feature to TypeScript for company X,’ and they’d respond ‘well, no, you have to open an issue in GitHub, make your case and maybe provide a PR. If you want this open source, you have to run it like an open source project’.”
Ultimately, TypeScript has won through Microsoft being good open source stewards and citizens.
