Proposal: Static Typing

kai zhu kaizhu256 at
Mon Mar 25 01:48:15 UTC 2019

i share a similar concern that static-typing makes little sense in high-churn-rate UX-workflow-programming.

it encourage people to bikeshed for correctness, on low-level code that frequently gets rewritten every few weeks/months -- and with often demoralizing effects.

> On 24 Mar 2019, at 17:26, Bergi <a.d.bergi at> wrote:
> Hello,
> to play the devils advocate: why does JavaScript need static typing?
> Your proposal doesn't really answer that. Sure, it mentions tooling and
> IDEs that can provide you with type hints and complain on mistakes, but
> things like Flow and Typescript do this today already.
> What's your goal, to have JS engines run Typescript(-like) code natively
> without transpiling? For backwards-compatibility you'd have to do that
> anyway, especially if new type system features are introduced incrementally.
> What's the point of building this feature into engines? It just provides
> additional complexity. Not to mention the difficulty of finding a
> suitable type system that is both sophisticated enough to describe all
> useful code (not taking away too much flexibility) and simple enough to
> understand without a CS degree. And which interfaces well with un-typed
> completely dynamic code.
> What does "static typing" even mean to you in a dynamic scripting
> language? JavaScript is not compiled by the developer, it is run by the
> user. Where (when) do you expect types to be checked? Should the engine
> throw early errors (during parsing)? During parsing of which parts of
> the code, even when "normal" (untyped) code is calling into typed code?
> Or do you expect dynamic runtime errors, like when assigning an invalid
> value to a "typed variable" or calling a "typed function" with wrong
> arguments? Are type definitions completely constant or could they be
> mutated/extended/etc dynamically (and what happens when you introduce
> new types with `eval` or by loading another script)?
> A proposal would need to provide an objective that answers all these
> questions, before even considering any particular type system or syntax.
> One way to go forward that I can see would be a proposal that reserves a
> relatively unrestricted syntax for type annotations (which are already
> considered during every grammar amendment anyway, for compatibility with
> Flow/Typescript), but not assign any semantics to them and require
> engines to simply ignore them. External tooling could then use these
> annotations according to its own rules.
> kind regards,
> Bergi
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list