Is TypeScript actually worth It?

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • Appwrite - The Open Source Firebase alternative introduces iOS support
  • InfluxDB - Access the most powerful time series database as a service
  • Sonar - Write Clean JavaScript Code. Always.
  • d2-playground

    An online runner to play, learn, and create with D2, the modern diagram scripting language that turns text to diagrams.

    if you're talking about the playground, I did the initial version in a weekend or so (, which includes building a WASM version of D2 (written in Go), putting a text editor, some UI stuff like dropdowns/menu, hooking it up together, layouts and responsiveness whatnot.

    If you're talking about D2 language itself, ~2 devs over 3/4 of a year.

  • proposal-type-annotations

    ECMAScript proposal for type syntax that is erased - Stage 1

    My biggest fear with TS is people forgeting why TS exist in the first place and stop trying to solve the problem TS solves because it's already solved. It's not solved, TS is by far the best option, but its far from being ideal. Deno coming out of the box with TypeScript support and the JavaScript Type Annotations Proposal [1] gives me faith that we will grow past TS.


  • Appwrite

    Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!

  • ts-proto

    An idiomatic protobuf generator for TypeScript

    Re libraries incompatible with certain typescript versions - e.g. protobufjs fix - it’s been my experience that you want to try and only use compilers specific to each library and compile libraries separately. It’s unfortunate but the JS community often tries to run all JS for a project through the same single compiler tool chain, using one global version of the compiler instead of relying on and effectively linking the JS output for each library. Unless you routinely rewrite third-party libraries to match your toolchain’s expectations, you’re going to have a hard time doing that.

    For a library that generates code, that’s a special case, as the code it generates must target a particular language version. You have three choices: 1. Upstream a fix as you propose; 2. Side-by-side install both TS 4.6 and TS 4.7 using workspaces or sub-projects and have some of your code compile with 4.6 and then link the results or 3. Find a replacement that is updated to 4.7. For example, has 4.7 support listed in its readme.

  • DefinitelyTyped

    The repository for high quality TypeScript type definitions.

  • TDungeon

    TDungeon is a small adventure game that runs in the Typescript type system

    I did not write the blog post, it was just a simple infer/extends non-trivial example explained in depth, commonly used in packages like express and so forth. TDungeon [1], a game running on the TypeScript type system, really showcases how powerful the type system truly is.

    Why not C#? Probably because Anders Hejlsberg [2], lead architect of C# and core developer of TypeScript, wanted something different.



  • flyweight

    An ORM for SQLite

    I wrote in JavaScript, not TypeScript. It generates TypeScript declaration files as it types SQL, which helps with intellisense support in VSCode. That is the only reason I use TypeScript.

    I don't like TypeScript though, and would never write anything in it. I have a long history with C# and I came to conclusions about this topic a long time ago. I just prefer writing JavaScript, it is more fun and more productive.

    Flyweight is quite a complex library. It parses arbitrarily complex SQL. This is more complex than most of the things people work on and claim they need static typing. It isn't millions of lines of code, but often those codebases aren't complex, they are just many independent components that in themselves are not that complex.

    The amount of time I spend having to update the TypeScript aspect of my library is really quite annoying. Also, with regards to your point about libraries not including type information - this is also true for the actual native APIs in the browser and so on as well. For example, TypeScript doesn't recognise the "indices" property of regular expression matches.

  • rescript-compiler

    The compiler for ReScript.

    I find ReScript ( fundamentally better than TypeScript. It has easy FFI and a sound typesystem. With Rescript you wont have any runtime errors, like you can with typescript. But compared to vanilla javascript typescript is a big improvement.

  • InfluxDB

    Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.

  • proposals

    Tracking ECMAScript Proposals

  • React

    The library for web and native user interfaces

    The TS type system is incredibly powerful, and I wish I could apply to other languages out there. The biggest annoyances with it come from the fact that it isn't its own language; you get runtime errors due to incorrect or out-of-date types (often maintained by people other than the library authors). Also, "any" and "unknown" types tend to sneak in via default generic arguments, vague external module typedefs, etc. These types can spread through your codebase, preventing the type checker from doing its job, and the "strict" mode doesn't do much about it!

    Generally speaking, I have to be extremely careful with working on a JS/TS project. I use the strictest modes possible and enable as much linting as possible. I also use the type-coverage module and fail the build if the `any` type gets applied anywhere.

    As another general complaint, NPM doesn't do enough to incentivize its users to release quality software. JS/TS has always been very trend-based and social, and even just running a few simple lints and prominently displaying a score on NPM would probably really help the community improve its standards.

    Take (Dart), for example. Here's a module page: The score is displayed prominently, and if you click on it you get a full breakdown of how it was calculated: static analysis, up-to-date dependencies, and documentation (although the coverage is not 100% for this module, so I think it's wrong to assign full points). When you upload to, you want a score of 100! It doesn't guarantee that the module is fantastic software, but at least the basics have been taken care of.

    In my opinion, the most important piece missing from the score on is test coverage. Take for example a page from Metacpan (Perl packages). Here's a module I've released: On the left you see displayed the automated test results, including the test coverage, which has been submitted by volunteers who downloaded and tested the code on a variety of platforms and Perl versions. There's also link to a "kwalitee" page, which is similar to the score (though this could be much improved by having an actual score and displaying it prominently on the main module page).

    Now an NPM module: What info do we have about the quality of the package? Essentially just the activity from the community (open PR's and issues, downloads). We have no idea how well it's tested, what kind of static checks have been performed, whether your editor will be able to display documentation or typing when you mouse over a method from the library, etc. (TypeScript is mainstream enough now that it should be fine for NPM to provide a bit of special handling for it.) Most 3rd party libraries are from individual authors and probably have very little activity. When deciding whether or not to use them, right now you need to dive through the code to check if the basics are taken care of. Having some of this automated would save a lot of time.

  • protobuf.js

    Protocol Buffers for JavaScript. Finally. (by apollographql)

    > Can I just open an issue in the TypeScript repo for this sort of thing if I have a concrete suggestion?

    My former colleague Arthur has already answered this one - but yes! If you have a concrete suggestion, that's fair game and we can brainstorm on the issue to think of something. We might not come up with something general enough to implement, but it's often a good seed to plant.

    > which in turn broke a type used from ProtobufJS.

    I am curious to hear what sort of issue you ran into. Was this the Apollo fork (, or the original?

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts