Hacker News new | ask | show | jobs
by lewisl9029 3148 days ago
I'd be much more enthusiastic about using a type system if it was a part of an official ES-next spec. Right now community efforts around static typing are divided between two very similar, but incompatible type systems, similar to the situation we had a few years ago with CommonJS and AMD modules (though the two module systems are much more dissimmilar than Flow and TypeScript). The module debate has been been mostly laid to rest with the introduction of the official ES modules spec (at least from the perspective of the application developer when it comes to module code they actually write), and I'm hoping an official type annotation spec can do the same for the JS static type checking landscape.

Flow has already long-since demonstrated that it's perfectly possible to introduce useful type annotations to JS code without changing any runtime behavior whatsoever, and Flow and TypeScript have mostly converged on similar syntax and semantics when it comes to the type annotations. Given all this, I'd have thought that the standardization process would be pretty far along by now. Maybe someone more familiar with these matters can offer some insight on the seeming lack of progress?

2 comments

Interestingly, a type system was proposed for JavaScript around 2007 as part of ES4, which was later abandoned [1]. The proposed details in [2] are strikingly similar to what we've ended up with in Flow and TypeScript.

[1] https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28aban... [2] https://www.ecma-international.org/activities/Languages/Lang...

See also ActionScript [1] which was the closest real world language to an ES4 implementation, and how much it seems like Typescript/Flow.

[1] https://en.wikipedia.org/wiki/ActionScript

It feels a little bit like if you'd want a linter to be part of an ES spec. As in: I appreciate TypeScript for the compile-time guarantees it gives me.
A good comparison here is the Python approach: Python 3 made the syntax for type annotations a first-class part of the language but only to the point of parsing that syntax and providing an AST, it did not (and at least for now will not) define "compile time" or "run time" meanings for them.

The immediate benefit to adding Typescript/Flow-like annotations to the ES spec would be that you could run Typescript files unchanged (without transpilation) in the browser, even if the Browser didn't do any type checks for you. You could still use TS or Flow to do the type checks in a separate process, but you could potentially drop the type-stripping steps in TS or Babel. The possibility exists that eventually the browser could also start to enforce basic type checks, but the immediate benefit of slightly faster build processes with no type-stripping step shouldn't be overlooked.

That makes sense. I can also imagine not wanting to start too quickly with that though, to learn what such a syntax would have to support from Flow and TypeScript.
The point of having type annotations in the spec is so that library and tooling authors can focus on providing and refining a single set of type annotations that any tool (Flow, TypeScript, anything else that comes up) can check for correctness and perform static analysis (for things like autocomplete, find references, go-to definition, etc) against. Over time, this would vastly improve the quantity and quality of available type definitions compared to what's available for either the Flow or TypeScript camp alone.

And once type annotations are part of the language proper, the possibility opens up for browsers to use type annotations to provide runtime safeguards, optimizations, and reflections, all of which would be invaluable since static checking alone is often not enough to provide correctness guarantees in all cases in JavaScript. When all is said and done, JavaScript is a dynamic language, and the ability to reuse the same type annotations for both static and dynamic checks is the piece that I'm sorely missing from both the Flow and TypeScript ecosystems so far.