Ten Years of TypeScript

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • TypeScript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

    > But they admitted namespaces, enums

    And decorators. But this was very early on and they won’t ever do it again unless there’s a drastic change on principle and probably a reorg of global proportion. They categorically reject anything with runtime implications now, and to the point of decorators are actively working to align them with the standard as it’s approaching stability.

    > and interfaces into the language (the latter becoming more and more confusing as type aliases got more expressive) […] Is "as", "is", or "satisfies" expression-level?

    No. All of this is completely separate from the runtime and on a standards course to be treated effectively as comments.

    > But the enums!

    I’m one of the minority who actually likes TS enums, but I strongly suspect they’ll be deprecated, alongside namespaces, as soon as there’s general consensus around types as comments. The TypeScript team considers these mistakes and would very much like to be able to drop them. I’d welcome that too even though I quite like enums.

    The fact is TS has considerable backwards compatibility expectations, and aligning their mistakes with their goals is great on principle but something which would require thousands upon thousands of hours of labor for people to accommodate.

    You can snipe all you want, but if you think it’s that easy to resolve maybe I can direct you to https://github.com/microsoft/TypeScript/pulls

    I’m not affiliated with the team in any way but I’m almost totally certain they’d welcome a contribution that gets them closer to their stated principles where historical designs are entrenched, without breaking workflows for thousands of people and interrupting releases for millions.

  • rescript-compiler

    The compiler for ReScript.

    Also see https://rescript-lang.org/ if you're considering learning Typescript

    Looking forward to more great ideas in the future of ways to 'fix' Javascript.

  • SurveyJS

    Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  • proposal-pattern-matching

    Pattern matching syntax for ECMAScript

    Pattern matching is actually being discussed in tc39 for JS as a whole (where TS reps are some of the champions, ofc): https://github.com/tc39/proposal-pattern-matching

    The specifics of the proposal will likely shift a bit since it's still stage 1 (2?).

  • Civet

    A TypeScript superset that favors more types and less typing

  • TypeScript-wiki

    A repository to make changes to the TypeScript Wiki on GitHub

    When you can write a busy beaver machine in the type system, LOC ceases to be a good indicator or how long something should take to typecheck, imo. If you're frustrated with your build, you should use the trace tools on the TS wiki[1] to track down what types are slow to check, so you can attribute the slowness to the appropriate library authors/yourself and decide for yourself if the speed/correctness tradeoff they've made is right for you.

    [1]https://github.com/microsoft/TypeScript-wiki/blob/main/Perfo...

  • MIRAI

    Rust mid-level IR Abstract Interpreter

    Traditional design by contract checks the contracts at runtime. They can be understood as a form of dynamic typing with quite complicated types, which may be equivalent to refinement types

    But you can check contracts at compile time too. It's quite the same thing as static typing with something like refinement types. That's because, while with contracts we can add preconditions like "the size of this array passed as parameter must be a prime number", with refinement types we can define the type of arrays whose size is a prime number, and then have this type as the function argument. (likewise, postconditions can be modeled by the return type of the function)

    See for example this Rust library: https://docs.rs/contracts/latest/contracts/

    It will by default check the contracts at runtime, but has an option to check them at compile time with https://github.com/facebookexperimental/MIRAI

    Now, this Rust library isn't generally understood as creating another type system on top of Rust, but we could do the legwork to develop a type theory that models how it works, and show the equivalence.

    Or, another example, Liquid Haskell: https://ucsd-progsys.github.io/liquidhaskell/ it implements a variant of refinement types called liquid types, which is essentially design by contract checked at compile type. In this case, the type theory is already developed. I expect Liquid Haskell to be roughly comparable to Rust's contracts checked by MIRAI.

    Now, what we could perhaps say is that refinement types are so powerful that they don't feel like regular types! And, while that's true, there are type systems even more powerful: dependent types used in languages like Coq, Lean and F* to prove mathematical theorems (your type is a theorem, and your code, if it typechecks, is a proof of that theorem).

    Dependent types were leveraged to create a verified TLS implementation that mathematically proves the absence of large class of bugs, miTLS https://www.mitls.org/ (they discovered a number of vulnerabilities in TLS implementations and proved that their implementation isn't vulnerable), and HACL* https://github.com/hacl-star/hacl-star a verified crypto implementation used by Firefox and Wireguard. They are part of Project Everest https://project-everest.github.io/ which aims to develop provably secure communications software.

  • hacl-star

    HACL*, a formally verified cryptographic library written in F*

    Traditional design by contract checks the contracts at runtime. They can be understood as a form of dynamic typing with quite complicated types, which may be equivalent to refinement types

    But you can check contracts at compile time too. It's quite the same thing as static typing with something like refinement types. That's because, while with contracts we can add preconditions like "the size of this array passed as parameter must be a prime number", with refinement types we can define the type of arrays whose size is a prime number, and then have this type as the function argument. (likewise, postconditions can be modeled by the return type of the function)

    See for example this Rust library: https://docs.rs/contracts/latest/contracts/

    It will by default check the contracts at runtime, but has an option to check them at compile time with https://github.com/facebookexperimental/MIRAI

    Now, this Rust library isn't generally understood as creating another type system on top of Rust, but we could do the legwork to develop a type theory that models how it works, and show the equivalence.

    Or, another example, Liquid Haskell: https://ucsd-progsys.github.io/liquidhaskell/ it implements a variant of refinement types called liquid types, which is essentially design by contract checked at compile type. In this case, the type theory is already developed. I expect Liquid Haskell to be roughly comparable to Rust's contracts checked by MIRAI.

    Now, what we could perhaps say is that refinement types are so powerful that they don't feel like regular types! And, while that's true, there are type systems even more powerful: dependent types used in languages like Coq, Lean and F* to prove mathematical theorems (your type is a theorem, and your code, if it typechecks, is a proof of that theorem).

    Dependent types were leveraged to create a verified TLS implementation that mathematically proves the absence of large class of bugs, miTLS https://www.mitls.org/ (they discovered a number of vulnerabilities in TLS implementations and proved that their implementation isn't vulnerable), and HACL* https://github.com/hacl-star/hacl-star a verified crypto implementation used by Firefox and Wireguard. They are part of Project Everest https://project-everest.github.io/ which aims to develop provably secure communications software.

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

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