This article is an authorized translation from TypeScript Team member Orta’s Understanding TypeScript’s Popularity blog. Orta. IO /notes/js/wh…

Translation: ycaptain

TypeScript is a popular extension to the JavaScript language. It adds a type layer on top of the existing JavaScript syntax, and even if this layer is removed, it doesn’t affect the original performance of the runtime at all. Many people think of TypeScript as “just a compiler,” but it’s better to think of TypeScript as two separate systems: the compiler (which deals with syntax) and the language tool (which deals with integration with the editor). By looking at these two systems independently, we get two important perspectives that explain our previous decisions.

Downloads of TypeScript on NPM are doubling every year. Today (the blog was launched on April 14, 2021), it is being downloaded about 20 million times a week. In April last year, there were about 10 million. It continues to grow at a high rate and shows no signs of slowing down.

1. How did we make it so popular?

Since version 2.0, TypeScript has released a release every two months. But now we’ve slowed down the pace of release to release every three months. We spent one month writing the new features and releasing the beta, and the other two months testing and bug-fixing the beta, which made subsequent releases more stable.

1.1 Timeline of major events

In my opinion, these are the big things that push TypeScript beyond its popular limits:

  • When TypeScript went live, we reviewed the TypeScript code base to figure out what it was, so we threw away the original code. Rewritten in a functional style (as opposed to classes with mutable features) – this architecture is still in use today, and it can run steadily and efficiently for long periods of time with minimal change. Some people have mentioned that TypeScript’s predecessor was written in C++, which I’m not sure is true.

  • 2015 – Angular adopts TypeScript, TS V1.5 – At that time Google was considering building their own language for Angular rather than opting for TypeScript. In order for TypeScript to be considered, TypeScript breaks one of its basic rules: Don’t implement TC39 too soon. As such, TypeScript supports experimentalDecorators. Even if the feature isn’t added to JavaScript six years later, the result is totally worth it to everyone involved in the development of the technology who took on the debt.

  • 2015 – JSX support in TypeScript, TS V1.6 – React has grown into a very popular UI library. React uses JSX: a JavaScript extension that allows you to write HTML efficiently in JavaScript. TypeScript support for JSX makes it possible for others to do TypeScript support for React (maintained by @types/ React rather than built into TypeScript)

  • 2016 – Undefined types, static type analysis based on control flow – TS V2.0 – TypeScript supports undefined and NULL types, building on the union Types feature released in version 1.4. This allows the type system to really model most JavaScript code. At the same time, code control flow analysis allows if statements and other user code to influence the type analysis results of variables at different locations.

  • 2016 – Embrace DefinitedTyped, TS V2.0 – DefinitelyTyped is a side project written by volunteers. There were other systems like DefinitelyTyped, and the TypeScript team adopted DefinitelyTyped and incorporated the concept of @types/x into their compilers. In adopting and maintaining DefinitelyTyped, the TypeScript team did serious testing and improved workflows, which helped it become one of the most active repOs on GitHub. The story about DT is worth reading.

  • 2016 – JavaScript support, TS V2.3 – While there are already language toolchains that support JavaScript projects, support for JSDoc allows JavaScript projects to benefit from TypeScript even if they don’t use it. This not only opens the way for JavaScript to migrate to TypeScript, but also provides tooling support for existing JavaScript projects.

  • 2018 – Add TypeScript support to Babel, Babel 7 – This is where TypeScript becomes a home for code libraries. Adding TypeScript support to Babel adds some constraints to TypeScript, but it’s worth it. TypeScript no longer requires the complicated process of migrating from ESLint to TSLint, but is as easy as checking a checkbox.

  • 2018 – Composite Projects, TS V3.0 – There are many ways to handle large source libraries, and TypeScript handles Composite Projects. You can maintain many TypeScript child projects within a single code base by using.d.ts files as project boundaries. This saves time and memory, and most importantly allows you to scale it to very large code bases.

  • 2019 – Optional Chaining, TS V3.7 – While some larger language features are missing from this list, the perfect Optional Chaining feature in conjunction with TC39 makes people very excited about TypeScript support. As a good participant in the JS ecosystem and tools, the process of incorporating optional chain features into JavaScript is a perfect example of how TypeScript expects to position itself. TypeScript should do more of these projects.

  • 2020 – esbuild/SWC/sucrase – These new compilers and JavaScript runtimes support TypeScript syntax from the first release, and any project based on these tools can use TypeScript directly. The direct enablement of TypeScript syntax in.ts files further legitimizes it as a built-in extension to JavaScript.

  • Rewrite user Documentation – It’s my job to rewrite documentation, so take this part of the description with a bit of faith, but TypeScript documentation has been weak for years. I worked with a lot of older people on the compiler team to rewrite user-facing documentation and provide them with an online editor to help them understand TypeScript. This is the first step towards answering the language question, and good documentation allows the compiler team to focus on the compiler.

My view: TypeScript is popular because it keeps lowering barriers to entry through tools (DT / — isolatedModules/JSDoc), collaborating with other tools and organizations (Babel/TC39), It also demonstrates the value of tools and type safety in JavaScript in an incremental way. Today, people who write JSDoc are actually TypeScript users, just like people who use –strict.

1.2 Who are TypeScript’s competitors?

The goal of TypeScript is to give people the tools to write large JavaScript projects and have confidence in maintenance. JavaScript itself has no syntax to support representing the type of each identifier, unless JavaScript is run and checked at run time. To address this issue, TypeScript adds additional syntax.

So if our goal is to provide support as a tool, there are a few competitors in this space that TypeScript can’t compete with:

  • ESLint and TSLint: Similar to TypeScript, they both highlight possible errors in code, but don’t add new syntax to the checking process. Neither is intended to run as an IDE integrated tool, and TS and TS/ESLint often refer to features that don’t make sense to the project as “the other’s domain.” In modern code, the existence of TS/ESLint allows TypeScript to do fewer checks that don’t apply to all code bases. There is some overlap, but they are good complementary tools.

  • CoffeeScript: Hey, TypeScript was released in 2012! The difference between CoffeeScript and TypeScript is that CoffeeScript wants to improve the JavaScript language by adding features to JavaScript. This means understanding the difference between CoffeeScript and the JavaScript it outputs. Over time, CoffeeScript’s best idea turned it into just another JavaScript, and people became obsessed with CoffeeScript being almost JavaScript.

  • Flow: This is Facebook’s JavaScript type checking tool and IDE tool language. Just like TypeScript, Flow adds some extra syntactic support to JavaScript, giving you a richer type system that can then be removed at compile time. When I first started writing JavaScript, Flow was the first tool I used because it was closer to standard JavaScript. Flow is a great type system that has different goals than TypeScript. Any unseen type-level system must constantly make “right” or “feels right enough” decisions, and Flow aims to be “right”. Flow leans toward Soundness and is more pessimistic in its type judgment, while TypeScript aims to “feel mostly right.” While TS officially claimed that TS is not type-complete, allowing unsound behaviour, biased towards yan, and more optimistic in type judgment). You can’t have your cake and eat it too. Complete type derivation, good development experience, and Perfect JavaScript Interop are the only two choices.

So why did most of the open source Flow code base end up migrating to TypeScript? In my opinion, it was largely determined by the different priorities of the two teams. Flow is built to maintain Facebook’s code base, whereas TypeScript is built as a standalone language. Here are two pieces of evidence:

  1. Facebook’s codebase is a huge monorepo that can’t be partitioned, and the Flow team did an incredible job of making types run under such a large codebase. On the other hand, TypeScript can be said to “use projects to make sets of smaller codebases,” because that’s how people write JavaScript modules in the open source community. I think it’s fair to say that TypeScript doesn’t run on Facebook’s code base the way Flow does, and it either requires a lot of rewriting of Facebook code to build projects or a lot of changes to TypeScript, This can affect the overall TypeScript developer experience.

  2. In contrast to what DefinitelyTyped does to types with Flow, the TypeScript team has a compiler engineer on rotation to support our build tools for DefinitelyTyped and help manage the community. Flow, on the other hand, is almost entirely maintained by the community. DT is bigger now because they have been working on non-Facebook code, which would have been hard to get funding from the Flow team.

Microsoft has created a separate environment for TypeScript internally that frees it to focus on tool development and overall ecosystem maintenance, rather than solving a particularly difficult problem. This allows the TypeScript team to work with many people to continuously release features that the community wants. As time went on, I suspect the Flow team had a harder time allocating time to community work as external demand growth slowed. This creates a vicious circle. This makes Flow today no longer a direct “competitor” to TypeScript, but rather an interesting perspective on how to solve similar problems from different perspectives with different constraints.

2. In the future

2.1 What do you think of TypeScript’s future?

One of the biggest barriers to using TypeScript today is the need for build tools. I don’t think it’s likely that type syntax will be added to JavaScript, but the possibility of “annotating types” in JavaScript is very high.

The idea is to create a syntax for a type system like TypeScript, but not define what happens when JS runs.


const a: string = "1234"

// It will look like this

const a/_: string_ / ="1234"

// Pass in the JS engine

Copy the code

In this case, the JS engine will know that string is a type annotation that ends at =. How this actually works is complicated and takes time to figure out. However, making TypeScript run “natively” in JavaScript lowers the barriers to its use. It imposes the same constraints on TypeScript that Babel added TypeScript support. But I think it’s worth it.

Deno is a key example of removing any BARRIERS to TS, emulating current JavaScript engines’ support for native TypeScript by running a tool written in Rust that compiles TS to JS very quickly.

2.2 Competitors today

  • JetBrins WebStorm – This is an IDE with advanced JavaScript tool support. They have their own engine for refactoring, code flow analysis, and checking JavaScript syntax. That’s good, JetBrains has done solid work on all of their ides. I used to use AppCode a lot for iOS work. When you have a TypeScript project, WebStorm mixes TypeScript language tools with its own tools, which is a win-win for you.

  • Languages compiled to JS – current examples are Elm, ReScript, KotlinScript, and the core goal of these languages is to interact with JavaScript. These are interesting languages for TypeScript, and they have a clean environment for implementing type systems — that is, no JS baggage. As competitors, they tend to be more niche because their core is not JavaScript and the community has been plagued by migration from CoffeeScript.

  • WASM – THE argument I’ve heard about WASM as a competitor to TypeScript is that WASM can be used as a language to control the browser DOM instead of JS. The common argument against this is that WASM doesn’t have DOM binding and probably never will. TypeScript includes JavaScript’s drawbacks, and you’ll almost always like it better if you’ve included WASM in your JavaScript runtime. That said, AssemblyScript does some good work in this area. It’s probably better to think of WASM as JSON, which is another tool that makes up a project and is unlikely to become a JavaScript competitor unless there are changes in the way WASM interacts with the DOM.

  • Build to WASM languages – such as Rust, Go, Swift, and other languages that can be compiled to WASM. Each of these languages could occupy TypeScript’s current position as a tool and core building block for the Web, but you never know. These languages can provide a variety of different base types and are built from scratch with different goals. If WASM and WASI are ultimately successful, I think it will be platform-specific (think apps and other feature implementations) and it will be interesting to see where they go. To be honest, they won’t be a competitor to TypeScript, but JavaScript.

2.3 How does TypeScript fit into the ecosystem?

TypeScript wants to innovate in the area of the type system and editor tools. We have one of the most expressive type systems in any major programming language.

When TypeScript was first created, the process of making changes to JavaScript was very different than it is today, so there are some features in TypeScript that are really the domain of TC39, but backward compatibility is still required. These features can exist in JavaScript for many years and have been iterated many times, which means that TypeScript must maintain two versions of a particular language-specific feature.

So our goal is to be a good member of the TC39 JavaScript language Committee, providing feedback on the language features supported by the editor and supporting the features that TypeScript users want to see. In this collaborative way, TC39 controls JavaScript and TypeScript supports them.

2.4 What does TypeScript think of its audience?

TypeScript’s audience includes:

  • JavaScript users (as language tools)

  • JS + JSDoc user (as a language tool)

  • TypeScript users (as compilers, language tools)

  • TypeScript strict schema (as compiler, language tool)

While TSC is optional when a project is built using tools such as Babel/SWC/Sucrase/esbuild, the above audiences can still get new features in every or at least every two TS releases. Babel, esbuild, etc will be updated to support new TS features. The TS team may work directly on these projects, or they may provide features for these projects without TSC, such as through vscode. Learn more about launch plans under TS roadmap).

2.5 How does TypeScript track the JS ecosystem?

Teams listen to feedback in several ways:

  • GitHub Issues has a constant stream of comments

  • Internal Microsoft teams ask for features or ask for help debugging their slow code base

  • Connect with the community through Gitter or TypeScript Community Discord

  • User testing of ideas/designs via microgroup’s internal tools

  • Has a very close relationship with VS Code, and a lot of feedback from language tools comes from them

  • We read every tweet from the @typescript team

  • We keep track of blog posts migrated to and from TypeScript

  • We track industry surveys and programming language overviews

Front-end team of Bytedance data platform, responsible for r&d of big data-related products within the company. We have a strong passion in front-end technology. In addition to research and development related to data products, we have a lot of exploration and accumulation in data visualization, mass data processing optimization, Web Excel, WebIDE, private deployment and engineering tools. If you are interested, please feel free to contact us.