Why choose TypeScript?

Why choose TypeScript?

Add a follower, don t miss the follow-up updates~

Authorized by the author, this article is translated and summarized from the personal blog "Understanding TypeScript's Popularity" of a member of the TypeScript Team orta.

Original author: orta

Original link: orta.io/notes/js/wh...

Translation: ycaptain

TypeScript is a very popular JavaScript language extension. It adds a type layer on top of the existing JavaScript syntax, and even if this layer is deleted, it will not affect the original performance at runtime. Many people think that TypeScript is "just a compiler", but a better understanding is actually to treat TypeScript as two independent systems: the compiler (that is, the part that handles syntax) and the language tool (that is, the part that handles the integration with the editor) . By looking at these two systems independently, we can get two important perspectives that can explain our previous decisions.

On npm , TypeScript downloads are doubling every year. Today (blog published on April 14, 2021), it has about 20 million downloads per week. In April last year, this number was about 10 million times. It still maintains a trend of rapid growth without any signs of slowing down.

1. How did we make it so popular?

Starting from version 2.0, TypeScript regularly releases a release every two months. But now we have slowed down the pace of release and changed to release once every three months. Among them, we will spend one month writing new features and releasing the beta version, and the remaining two months for testing and bug fixes on the beta version, which makes subsequent releases more stable.

1.1 Timeline of major events

In my opinion, these are the big events that have allowed TypeScript to continue to push the limits of popularity:

  • 2014-Rewrite TypeScript, TS v1.1-After TypeScript went live, we reviewed the TypeScript code base again and figured out what it is, so we discarded the original code and rewritten it in a functional style (different (From the original class with variable characteristics)-This architecture has been in use today, and it can run stably and efficiently for a long time in a process that rarely changes. Someone once mentioned that the predecessor of TypeScript was written in C++, and I am not sure of its authenticity.

  • 2015-Angular adopts TypeScript, TS v1.5-Google was considering building their own language for Angular instead of choosing to use TypeScript. In order for TypeScript to be considered, TypeScript broke one of its basic rules: Don't implement TC39 too early. In this way, TypeScript supports experimentalDecorators. Even if this feature has not been added to JavaScript in six years, for all those involved in the development, this result is completely worth their debt to this technology.

  • 2015-Support JSX in TypeScript, TS v1.6-At this time React has grown into a very popular UI library. And React uses JSX: a JS language extension that can efficiently write HTML in JavaScript. TypeScript's support for JSX allows others to support TypeScript's React support (maintained by @types/react, not built into TypeScript)

  • 2016-Undefined types, static type analysis based on control flow-TS v2.0-Based on the union types released in version 1.4, TypeScript supports undefined and null types. This allows the type system to truly model most JavaScript code. At the same time, code control flow analysis enables if statements and other user codes to affect the type analysis results of variables at different positions.

  • 2016-Embrace DefinitedTyped, TS v2.0-DefinitelyTyped is a side project written by volunteers. At that time there were some other systems similar to DefinitelyTyped. The TypeScript team adopted DefinitelyTyped and incorporated the concept of @types/x into their compilers. In the process of adopting and maintaining DefinitelyTyped, the TypeScript team conducted serious tests and improved the workflow, which helped it become one of the most active Repo on GitHub. The story about DT is worth reading.

  • 2016-Support JavaScript, TS v2.3-Although there were already some language toolchains supporting JavaScript projects at that time, support for JSDoc enabled JavaScript projects to get some of its benefits even if they didn't use TypeScript. This not only opened the way for JavaScript to migrate to TypeScript, but also provided tool support for existing JavaScript projects.

  • 2018-Added TypeScript support in Babel, Babel 7-This is the starting point for TypeScript to become the end of the code base. TypeScript increase support to TypeScript added some constraints (Translator's Note: In Babel in Isolated modules ), but it is worth it. Since then, TypeScript no longer needs the complicated migration process from eslint to tslint, but is as easy as checking a checkbox.

  • 2018-Composite Projects, TS v3.0-There are many ways to deal with large-scale source code libraries, and TypeScript's processing method is Composite Projects. By using the .d.ts file as the boundary of the project, you can maintain many TypeScript sub-projects in a single code base. This saves time and memory, and most importantly it allows you to expand it into a very large code base.

  • 2019-Optional Chaining, TS v3.7-Although some larger language features are missing from this list, the perfect combination of Optional Chaining with TC39 makes people very excited about TypeScript support. As an excellent participant in the JS ecosystem and tools, the process of adding optional chain features to JavaScript is a perfect example of TypeScript's expected positioning. TypeScript should do more of this kind of project.

  • 2020-esbuild/swc/sucrase-These new compilers and JavaScript runtimes support TypeScript syntax from the first version, and any projects based on these tools can directly use TypeScript. The TypeScript syntax is directly enabled in the .ts file to further legitimize it as a built-in extension of JavaScript.

  • 2020-Rewriting user documentation-It is my job to rewrite the documentation, so don't trust this part of the description, but TypeScript documentation has been weak over the years. I work with many older people in the compiler team to rewrite user-oriented documents and provide them with an online editor that helps them understand TypeScript. This is the first step in answering language questions, and good documentation allows the compiler team to focus on the compiler.

My opinion: TypeScript is popular because it continuously lowers the entry barrier through tools (DT/- isolatedModules/JSDoc), cooperates with other tools and organizations (Babel/TC39), and displays tools and types in a progressive way The value of security in JavaScript. Today, those who write JSDoc are actually TypeScript users, just like those who use --strict.

1.2 Who are the competitors of TypeScript?

The goal of TypeScript is to provide people with tools to write large JavaScript projects and have confidence in subsequent maintenance. There is no syntax support in JavaScript itself to express the type of each identifier, unless JavaScript is run and checked at runtime. To solve this problem, TypeScript added additional syntax.

So, if our goal is to provide support as a tool, there are a few competitors in this field that TypeScript cannot compete with:

  • ESLint and TSLint: Same positioning as TypeScript. They are both used to highlight possible errors in the code, but they do not add new syntax to the inspection process. Neither is intended to run as IDE-integrated tools, and TS and TS/ESLint often say that features that are not meaningful to the project are "the domain of the other." In modern code, the existence of TS/ESLint allows TypeScript to do fewer checks, which are not applicable to all code bases. Although some functions overlap, they can be used as good supplementary tools.

  • CoffeeScript: Hey, TypeScript was released in 2012! The difference between CoffeeScript and TypeScript is that CoffeeScript wants to improve the JavaScript language, such as adding some features to JavaScript. This means understanding the difference between CoffeeScript and the JavaScript it outputs. Over time, the best idea of CoffeeScript turned it into another JavaScript, and people were troubled by CoffeeScript, which had almost become JavaScript.

  • Flow: This is Facebook's JavaScript type checking tool and IDE tool language. Just like TypeScript, Flow adds some additional syntax support to JavaScript, allowing you to have a richer type system, which can then be deleted 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, and it has a different goal than TypeScript. Any invisible type layer system must constantly make correct or feeling correct enough decisions, Flow s goal is correct (Translator s Note: Flow favors soundness and is more pessimistic in type judgment), and The goal of TypeScript is to "feel correct in most situations" (Translator's Note: TS officially claims that TS is not type complete , allows unsound behavior, favors completeness, and is more optimistic in type judgment). Fish and bear's paw can't have both, complete type derivation, good development experience and perfect JS collaboration (Perfect JavaScript Interop) can only choose the second.

So why did most of the open source Flow codebase eventually migrate to TypeScript? In my opinion, it is largely determined by the different focuses of the two teams. Flow was built to maintain Facebook's code base, and TypeScript was built as an independent language. There are two pieces of evidence to prove:

  1. Facebook's code base is a huge monorepo can not be divided, and the Flow team in order to make the type of operation in such a large code base made under a lot of incredible work . On the other hand, TypeScript can be said to be "use projects to make sets of smaller codebases" because it fits the way people write JavaScript modules in the open source community. I think it is reasonable to say that TypeScript cannot run on Facebook's code base like Flow. It either requires a lot of rewriting of Facebook's code to build the project, or a lot of changes to TypeScript, which may affect TypeScript developers as a whole Experience.

  2. Comparing DefinitelyTyped and Flow's approach to types, the TypeScript team will take turns to have a compiler engineer to support our build tools for DefinitelyTyped and help manage the community. And Flow, it is almost completely maintained by the community. DT is now larger, because they have been working on the development of non-Facebook code, it will be difficult to obtain financial support from the Flow team.

The independent environment that Microsoft created internally for TypeScript allows it to freely focus on tool development and maintenance of the entire ecosystem, instead of just focusing on solving a particularly difficult problem. This allows the TypeScript team to work with many people and continue to release features the community wants. As time goes by, I guess that because of the slowdown in external demand growth, it becomes increasingly difficult for the Flow team to allocate time for community work. This forms a vicious circle. This makes Flow today no longer a direct "competitor" of TypeScript, but an interesting perspective on how to use different constraints to solve similar problems from different perspectives.

2. The future

2.1 What do you think about the future of TypeScript?

The biggest obstacle currently preventing people from using TypeScript is that it requires building tools. I think that type syntax is unlikely to be added to JavaScript, but the possibility of "defining types with annotations" in JavaScript is very high.

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

const a: string = "1234" //will become like this const a /*: string */ = "1234" //Pass in the JS engine to copy the code

In this example, the JS engine will know: string is a type comment, ending at =. This actual way of working is complicated and it takes time to figure it out. However, allowing TypeScript to run "natively" in JavaScript will lower the barriers to its use. It will impose some constraints on TypeScript just like when Babel added TypeScript support. But I think it is worth it.

Deno is a key example to eliminate all TS obstacles. It can quickly compile TS to JS by running a tool written in Rust, simulating the current JavaScript engine's support for native TypeScript.

2.2 Today's competitors

  • JetBrains WebStorm-This is an IDE supported by advanced JavaScript tools. They have their own engine for refactoring, code flow analysis, and JavaScript syntax checking. This is good, JetBrains has done a solid work on all of their IDEs. I used to use AppCode to handle iOS work. When you have a TypeScript project, WebStorm will mix TypeScript language tools with its own tools, which is a win-win for you.

  • Languages compiled to JS-current examples are Elm, ReScript, KotlinScript, the core goal of these languages is to interact with JavaScript. For TypeScript, these are very interesting languages, they have a clean environment to implement the type system-that is, no JS baggage. As competitors, they tend to be more segmented markets because their core is not JavaScript, and the community has also been troubled by the migration from CoffeeScript.

  • WASM-I heard the view of WASM as a TypeScript competitor that WASM can be used as a language instead of JS to control the browser DOM. Those who oppose this view generally believe that WASM has no DOM bindings and may never have. TypeScript contains the shortcomings of JavaScript, if you have added WASM to the JavaScript runtime, you will almost always like it more. In other words, AssemblyScript has done some good work in this regard. Perhaps it would be better to think of WASM as JSON. It is another tool that composes the project and is unlikely to become a competitor to JavaScript unless the way WASM interacts with the DOM changes.

  • Languages that compile to WASM-such as Rust, Go, Swift, and other languages that can be compiled to WASM. These languages may occupy TypeScript's current position as a tool and core building block of the web, but the world is unpredictable, who knows what will happen? These languages can provide a variety of different basic types and build from scratch based on different goals. If WASM and WASI finally succeed, then I think it will be platform-related (think about the implementation of functions such as apps), and it will be interesting to see where they are going. To be honest, they will not be competitors of TypeScript, but JavaScript.

2.3 How does TypeScript see its position in the ecosystem?

TypeScript hopes to innovate in the field of type systems and editor tools. We have one of the most expressive type systems in mainstream programming languages.

When TypeScript was first created, the process of modifying JavaScript was very different from what it is now, so some features in TypeScript are actually the domain of TC39, but they still need to be backward compatible. These features may exist in JavaScript for many years and have gone through many iterations, which means that TypeScript must maintain two versions of a specific language feature.

So our goal is to become an excellent member of the TC39 JavaScript Language Committee, to provide feedback on the language features supported by the editor, and to support the features that TypeScript users want to see. In this way of collaboration, TC39 controls JavaScript, and TypeScript also supports them.

2.4 How does TypeScript see its audience?

The main audiences of TypeScript are:

  • JavaScript users (as a language tool)
  • JS + JSDoc users (as a language tool)
  • TypeScript users (as a compiler, language tool)
  • TypeScript strict mode (as a compiler, language tool)

Although the project is built with tools such as babel/swc/sucrase/esbuild, tsc is optional, but the above audiences can still get new features every time or at least every two TS version releases (Translator's Note: babel , Esbuild, etc. will be updated to support new features of TS. The TS team may go directly to these projects, or they may provide features for these projects without tsc, such as through vscode. You can learn more about the release plan in the TS roadmap ).

2.5 How does TypeScript track the JS ecology?

The team listens to feedback in the following ways:

  • GitHub issues has a constant stream of comments
  • Microsoft internal team asked for features or asked us to help debug their slow code base
  • Connect with the community through Gitter or Discord in the TypeScript community
  • User testing of ideas/designs through Microsoft's internal tools
  • It has a very close relationship with VS Code, and feedback from many language tools comes from them
  • We will read every tweet of the @TypeScript team
  • We will track blog posts about migrating to TypeScript and migrating from TypeScript
  • We will track industry surveys and programming language overviews

Reference

[1] orta: twitter.com/orta

[2] Original: orta.io/notes/js/wh...

[3] npm: www.npmjs.com/

[4] DT's story: blog.johnnyreilly.com/2019/10/08/

[5] isolated modules: www.typescriptlang.org/tsconfig#is...

[6] soundness: logan.tw/posts/2014/

[7] TS is not type complete: www.typescriptlang.org/docs/handbo...

[8] Large code base: flow.org/en/docs/lan...

[9] A lot of incredible work: medium.com/flow-type/i...

[10] TS roadmap: github.com/microsoft/T...