the day I'll disable autocorrect everywhere will be always too late ... transpolar => transpilers trample => transpile
On Mon, Mar 25, 2019 at 10:13 AM Andrea Giammarchi < [email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> > [email protected] >>>> > https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
