First look: adding type annotations to JavaScript

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

Our great sponsors
  • Appwrite - The Open Source Firebase alternative introduces iOS support
  • Klotho - AWS Cloud-aware infrastructure-from-code toolbox [NEW]
  • InfluxDB - Build time-series-based applications quickly and at scale.
  • Sonar - Write Clean JavaScript Code. Always.
  • proposal-types-as-comments

    ECMAScript proposal for type syntax that is erased - Stage 1 [Moved to: https://github.com/tc39/proposal-type-annotations]

    To be frank, I hate to be the typical HN luddite, but this proposal [1] feels like it will add too much parsing complexity to runtime JS.

    The counter-argument to that is: everyone minifies code anyway, but this feels like a very poor argument. "Adding cruft is OK because most people have complicated build chains to get rid of it" is very different from "we've opted into a build chain (tsc) and now have access to adding cruft"; there's a default situation here, which is the many people who write JS (FE or BE) and aren't minifying it.

    Additionally, their pipe dream of allowing TS to become standard JS "if they stick within a certain reasonably large subset of the language" (an actual quote from the TC) is... wild. Wild. No thoughts, just vibes. Typescript is an extremely mature, fast-moving, complex project. Their list of TS features not supported under this TC is only three items long (with enums and namespaces among the list, lol), but I guarantee there are TONS of very complex type-level assertions typescript is capable of which JS is years, maybe decades, from reaching considering the glacial speed ECMA moves at.

    Typescript will always be a superset, which they admit. The problem is: I hold extreme doubt that JS/ECMA is even capable of communicating what that differential is to average users. Will JS support control flow analysis for dependent parameters, aliased conditions, and discriminants? Const assertions? Middle rest elements in tuples?

    Typescript adds all these assertions, and more, every couple months, because it turns out that type systems are something of a pandora's box. Few language-level type systems remain at the simplicity of, say, Go; most become TS, or Rust, or Java. That's not a bad thing, but not everything should be that.

    If this gets traction and built, JS will in-effect, though not in-requirement, turn from an interpreted language to a compiled language, whose compiler isn't even maintained by the core development teams. That's a major, major shift; and I'm not sure the proposers have even considered the ramifications of it.

    [1] https://github.com/giltayar/proposal-types-as-comments/

  • TypeScript

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

    Typescript, by the virtue of not being javascript, has evolved pretty rapidly, and has come pretty far. Would the addition of types to javascript and typescript's conformity to those type annotations slow down typescript's development? There's still some hope, at least on typescript's roadmap[0], for nominal types in addition to structural types. Will the standardisation of type annotations impose further constraints on typescript?

    [0] - https://github.com/microsoft/TypeScript/wiki/Roadmap#future

  • 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!

  • coffeescript

    Unfancy JavaScript

    CoffeeScript, for one, is already at least talking about emitting TS [1]. These kinds of changes are vigorously debated though, e.g. [2]. Once ECMA type comments get to stage 4, CS would probably also adapt the new syntax. Other compile-to-js languages that already ship with their own type system will probably be indifferent to the debated proposal.

    [1] https://github.com/jashkenas/coffeescript/issues/5307

  • typescript-eslint

    :sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript

    This is why "no-explicit-any" should be enforced in every project.

    https://github.com/typescript-eslint/typescript-eslint/blob/...

  • vite

    Next generation frontend tooling. It's fast!

  • Klotho

    AWS Cloud-aware infrastructure-from-code toolbox [NEW]. Build cloud backends with Infrastructure-from-Code (IfC), a revolutionary technique for generating and updating cloud infrastructure. Try IfC with AWS and Klotho now (Now open-source)

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