Proposal: Static Typing

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 25 09:13:55 UTC 2019


I am having hard time understanding the counter argument "you need a
transpolar anyway".

That's been the case since ES2015 landed with breaking syntax that has been
required mandatory transpilation to keep it backward compatible, with
things also not really transpilble such as classes with built-in extends
ability.

Why suddenly the "need to transpile" is considered a point against any new
JS feature? Are we already done with JS, if that's the case?

TypeScript exists and it has its own problems, 'cause its slightly
diversions from what's defined via TC39 causes just confusion (i.e. private
fields, to name one, built-in extends still broken if you target ES5, while
Babel 7 fixed that, and template literals behave differently too - Babel 7
is the only one producing a standard behavior)

On top of that, many things recently landed in JS has been inspired by
CoffeeScript ... where was the "just use CoffeeScript" argument at that
time? Transpilers were already a thing then too.

Moreover ...

> the real value of strict types, in my view, is at development time, not
at run time.

This is not correct. Check what AssemblyScript managed to do via types,
targeting WASM instead of non-typed JS

If TypeScript, with its quirks, will be the language that help developers
and win JS in the WASM field, we can start considering JS a second class
citizen of the Web (and soon of the backend too, see deno).

Is this where we are with JS?

> I would be curious to know if anybody has a usage for them at run time

Developers might not have such usage, but V8 / Chackra / JSC / SpiderMonkey
might spin up optimizations ahead of time, enabling right away hot code.

> a "toolchain" that allows strict typing using JavaScript without having
to "use TypeScript".

even if it'll end up being identical or redundant, but I doubt it, for many
companies/teams the least third parts dependencies you have the better is
for code reliability.

I personally don't trust TS because it breaks when it targets ES5 and I
cannot control what other people target, but I would trust the standard
path and tools aiming at all cost to trample it right, whenever transpiring
is needed.

With Edge moving to use Chrome, and Firefox and WebKit always catching up,
these days introducing anything new might need transpilers just for a
couple of years, instead of decades.

Best Regards





On Mon, Mar 25, 2019 at 9:55 AM Naveen Chawla <naveen.chwl at gmail.com> wrote:

> Yes the real value of strict types, in my view, is at development time,
> not at run time.
>
> However I would be curious to know if anybody has a usage for them at run
> time, and an example of such a case...
>
> Otherwise, yes a "toolchain" that allows strict typing using JavaScript
> without having to "use TypeScript".
>
> On Mon, 25 Mar 2019 at 04:58, Ranando King <kingmph at gmail.com> wrote:
>
>> One thing is definitively true. Any static type system added to ES must
>> not be mandatory. Untyped code must be able to call typed code without
>> forcing references into a fixed type. Likewise, typed code must be able to
>> call untyped code without forcing references to give up type guarantees.
>>
>> On Sun, Mar 24, 2019 at 8:48 PM kai zhu <kaizhu256 at gmail.com> wrote:
>>
>>> 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 web.de> 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 mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190325/9f92f270/attachment.html>


More information about the es-discuss mailing list