<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I am having hard time understanding the counter argument "you need a transpolar anyway".<div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>Moreover ...</div><div><br></div><div>> the real value of strict types, in my view, is at development time, not at run time.</div><div><br></div><div>This is not correct. Check what AssemblyScript managed to do via types, targeting WASM instead of non-typed JS</div><div><br></div><div>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).</div><div><br></div><div>Is this where we are with JS?</div><div><br></div><div>> I would be curious to know if anybody has a usage for them at run time</div><div><br></div><div>Developers might not have such usage, but V8 / Chackra / JSC / SpiderMonkey might spin up optimizations ahead of time, enabling right away hot code.</div><div><br></div><div>> a "toolchain" that allows strict typing using JavaScript without having to "use TypeScript".</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Best Regards</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2019 at 9:55 AM Naveen Chawla <<a href="mailto:naveen.chwl@gmail.com">naveen.chwl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Yes the real value of strict types, in my view, is at development time, not at run time.<div><br></div><div>However I would be curious to know if anybody has a usage for them at run time, and an example of such a case...</div><div><br></div><div>Otherwise, yes a "toolchain" that allows strict typing using JavaScript without having to "use TypeScript".</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 25 Mar 2019 at 04:58, Ranando King <<a href="mailto:kingmph@gmail.com" target="_blank">kingmph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 24, 2019 at 8:48 PM kai zhu <<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">i share a similar concern that static-typing makes little sense in high-churn-rate UX-workflow-programming.<br>
<br>
it encourage people to bikeshed for correctness, on low-level code that frequently gets rewritten every few weeks/months -- and with often demoralizing effects.<br>
<br>
> On 24 Mar 2019, at 17:26, Bergi <<a href="mailto:a.d.bergi@web.de" target="_blank">a.d.bergi@web.de</a>> wrote:<br>
> <br>
> Hello,<br>
> to play the devils advocate: why does JavaScript need static typing?<br>
> <br>
> Your proposal doesn't really answer that. Sure, it mentions tooling and<br>
> IDEs that can provide you with type hints and complain on mistakes, but<br>
> things like Flow and Typescript do this today already.<br>
> What's your goal, to have JS engines run Typescript(-like) code natively<br>
> without transpiling? For backwards-compatibility you'd have to do that<br>
> anyway, especially if new type system features are introduced incrementally.<br>
> <br>
> What's the point of building this feature into engines? It just provides<br>
> additional complexity. Not to mention the difficulty of finding a<br>
> suitable type system that is both sophisticated enough to describe all<br>
> useful code (not taking away too much flexibility) and simple enough to<br>
> understand without a CS degree. And which interfaces well with un-typed<br>
> completely dynamic code.<br>
> <br>
> What does "static typing" even mean to you in a dynamic scripting<br>
> language? JavaScript is not compiled by the developer, it is run by the<br>
> user. Where (when) do you expect types to be checked? Should the engine<br>
> throw early errors (during parsing)? During parsing of which parts of<br>
> the code, even when "normal" (untyped) code is calling into typed code?<br>
> Or do you expect dynamic runtime errors, like when assigning an invalid<br>
> value to a "typed variable" or calling a "typed function" with wrong<br>
> arguments? Are type definitions completely constant or could they be<br>
> mutated/extended/etc dynamically (and what happens when you introduce<br>
> new types with `eval` or by loading another script)?<br>
> <br>
> A proposal would need to provide an objective that answers all these<br>
> questions, before even considering any particular type system or syntax.<br>
> <br>
> One way to go forward that I can see would be a proposal that reserves a<br>
> relatively unrestricted syntax for type annotations (which are already<br>
> considered during every grammar amendment anyway, for compatibility with<br>
> Flow/Typescript), but not assign any semantics to them and require<br>
> engines to simply ignore them. External tooling could then use these<br>
> annotations according to its own rules.<br>
> <br>
> kind regards,<br>
> Bergi<br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>