# Optional Typing **URL:** \ **Category:** 💡 Ideas\ **Created:** [December 23, 2021, 4:26pm UTC](https://es.discourse.group/t/optional-typing/1137 "2021-12-23T16:26:13Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ReinsBrain](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/reinsbrain/32/1165_2.png) [@ReinsBrain](https://es.discourse.group/u/ReinsBrain)\ **Post date:** [December 23, 2021, 4:26pm UTC](https://es.discourse.group/t/optional-typing/1137/1 "2021-12-23T16:26:13Z")
Is there any hope of optional typing landing in ecmascript in future? Checking arguments at top of scope in functions, methods and constructors is getting really boring. It could even open the door to allow ecmascript to be a reasonable option for writing wasm. ---
**Author:** ![aclaymore](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/aclaymore/32/501_2.png) [@aclaymore](https://es.discourse.group/u/aclaymore)\ **Post date:** [December 23, 2021, 7:31pm UTC](https://es.discourse.group/t/optional-typing/1137/2 "2021-12-23T19:31:13Z")
Have you experimented with TypeScript at all? ---
**Author:** ![senocular](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/senocular/32/642_2.png) [@senocular](https://es.discourse.group/u/senocular)\ **Post date:** [December 23, 2021, 8:03pm UTC](https://es.discourse.group/t/optional-typing/1137/3 "2021-12-23T20:03:47Z")
There's also [AssemblyScript](https://www.assemblyscript.org/). ---
**Author:** ![trusktr](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/trusktr/32/183_2.png) [@trusktr](https://es.discourse.group/u/trusktr)\ **Post date:** [December 30, 2021, 11:02pm UTC](https://es.discourse.group/t/optional-typing/1137/4 "2021-12-30T23:02:39Z")
@aclaymore @senocular I use both TypeScript and AssemblyScript, and I'm avid in the AssemblyScript community, working on projects like, > **[GitHub - lume/asdom: Use DOM APIs in AssemblyScript](https://github.com/lume/asdom)** > > Use DOM APIs in AssemblyScript. Contribute to lume/asdom development by creating an account on GitHub. > **[GitHub - lume/glas: WebGL in WebAssembly with AssemblyScript](https://github.com/lume/glas)** > > WebGL in WebAssembly with AssemblyScript. Contribute to lume/glas development by creating an account on GitHub. and others. It would be really nice to have type syntax officially in EcmasScript. This would also, as @ReinsBrain mentioned, open the door to compiling to WebAssembly (or even native) in a standard way, and would allow multiple implementations (even the browser engine) to exist and be interoperable. If people could opt into type syntax and get type checking in the JS engine without any tooling, that'd be a huge win for the large amount of entry developers looking to easily start writing apps with minimal barrier to entry. TypeScript and AssemblyScript both require a fair amount of build system knowledge in comparison. ---
**Author:** ![trusktr](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/trusktr/32/183_2.png) [@trusktr](https://es.discourse.group/u/trusktr)\ **Post date:** [December 30, 2021, 11:43pm UTC](https://es.discourse.group/t/optional-typing/1137/5 "2021-12-30T23:43:49Z")
The following discussion moved here: > > > Hi, > > I understand this is an ambitious request, and probably aimed at ES8 or eve…n ES9, but considering the direction many web based technologies are heading, this request definitely makes sense in my mind. > > This request is for optional, TypeScript-esque, static typing for ECMAScript. > > There are tools and transpilers that already support optional static typing, and Google are also looking at supporting optional static typing directly in their virtual machine with \[SoundScript\](https://developers.google.com/v8/experiments#soundscript). That being said, a formal and specified syntax for optional static typing in ECMAScript would obviously be beneficial in numerous ways. It would allow developers to remove one or more layers from their workflow, therefore improving productivity across the board, and it would also allow virtual machines to produce highly optimized native code from the source files it consumes. I am honestly struggling to think of downsides. > > I believe the time is now right to consider adding option static typing to ECMAScript. The language is evolving extremely well now, and optional static typing is one feature that is still sorely missed. > > If required, I am willing to compose a full proposal to support this request. @ljharb the last thing you mentioned about the possibility of preventing (with string pragmas) a backwards compatibility nightmare if we were to enable optional types that the interpreter ignores and then making then errors later, was > [@trusktr](https://github.com/trusktr) at present i don't believe it can ever possibly be prevented. Would it better if we started with a tiny set of type features that introduce errors at the same time, so we con move forward towards the eventual best path? (avoiding a big all-at-once thing that might include mistakes we may regret?) What I'm imagining is then something like what @WebReflection [mentioned](https://github.com/tc39/ecma262/issues/45#issuecomment-392484440): ```js // no types used here let a = 123 let b = a // ok let c = b // ok a = "string" // ok b = a // ok c = b // ok ``` then we can start to introduce types: ```js // type annotations added to the file // do we want more-specific number types? Maybe `number` is the most generic and we can add more later? let a: number = 123 let b = a // ok, b inferred as `number` let c = b // ok, c inferred as `number` a = "string" // causes an error (at runtime? or at parse time?), 'string' not assignable to 'number' // These would be ok according to the inferred types, but this code is irrelevant due to the previous error. b = a // ok c = b // ok ``` The following is a live example of the type error using Hegel.js: [Hegel Playground example](https://hegel.js.org/try#DYUwLgBAhgXBB2BXAtgIxAJwgXggRgCYBmAKFElR2jPAgGMrUSSoqByAZzAwEt4BzNhAD0wiAFEMGAPYY4AFQCeABxAQARJ259B6iDw774dacmVQwPVKAgB3HmAAWEMCrXqkaTOpKVcUEgZcVCA) Hegel is a highly-inferring type system that is capable of making meaningful types out of plain JavaScript without type annotations, but type annotations can be used to specify intent as needed in order to override inference. TypeScript on the other hand likes to make everything type `any`, which is less beneficial. > **[Index](https://hegel.js.org)** > > Feel power of types A new version of Hegel is in the works but not released yet: [https://twitter.com/rage\_monk/status/1468917558078283779?s=20](https://twitter.com/rage_monk/status/1468917558078283779?s=20) Here is another example showing Hegel's type inference on the same example, but without a type annotation: [Hegel Playground example](https://hegel.js.org/try#DYUwLgBAhhC8EEYBMBmAUKSAjO0PggGNcs00Z4ByAZzACcBLAOwHNKIB6DiAUTroD2dAFwQAKgE8ADiAgAiGvWZs5EBtTVNCAgLZSoYBllAQA7gzAALCGGmy5TAK46sIOnLQ54UNMXhYgA) Here's a more advanced example including a function, still with no type annotations: [Hegel Playground example](https://hegel.js.org/try#G4QwTgBAVhC8EEYBMBmAsAKEwMwK4DsBjAFwEsB7fCUogCnwEoIBvTCdiMAU2NzCqoBqRJgC+mTIUoBnYhCrwahWlAYSMU-LIjS41OgHJkKA2qwaZc7HqXrN2-Eht0ALGcxLaAVgZA) I'm not sure how we could enable such a type inferring system in JavaScript without it being a breaking change (@ljharb any ideas?). Maybe the only way is to opt in with type annotations? Being able to have the sort of type inference as in Hegel without requiring type annotations is really convenient and useful. ---
**Author:** ![mhofman](https://avatars.discourse-cdn.com/v4/letter/m/f14d63/32.png) [@mhofman](https://es.discourse.group/u/mhofman)\ **Post date:** [December 31, 2021, 1:18am UTC](https://es.discourse.group/t/optional-typing/1137/6 "2021-12-31T01:18:55Z")
I don't understand how string pragmas can help in any way with syntax additions. My understanding of string pragmas is that they change the runtime behavior in a backwards compatible way, so that implementations that don't recognize the pragma simply ignores it. Thus the changes enabled have to be strictly runtime and less permissive that without the pragma. Type annotations are usually in the form of new syntax (except for JSDoc style), which wouldn't be parse time compatible. The only thing I can imagine is a one time breaking change to carve out a place where typing syntax can live an be ignored at runtime (aka make TS/Flow valid JS syntax), then in the future add string pragmas to opt into some kind of runtime check based on a specific flavor of the typings. However my understanding is that even a syntax carve out for typings previously failed or got stuck. For example [GitHub - samuelgoto/proposal-optional-types: A proposal for an optional type system for JS.](https://github.com/samuelgoto/proposal-optional-types) ---
**Author:** ![ljharb](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/ljharb/32/8_2.png) [@ljharb](https://es.discourse.group/u/ljharb)\ **Post date:** [December 31, 2021, 1:35am UTC](https://es.discourse.group/t/optional-typing/1137/7 "2021-12-31T01:35:43Z")
Or, we could go with what we already have: lintable comments that provide non-runtime annotations and can never cause runtime behavior in any edition of the spec. JSDoc is one flavor (or set of flavors, since there’s multiple kinds of jsdoc), but you could certainly invent your own. ---
**Author:** ![mhofman](https://avatars.discourse-cdn.com/v4/letter/m/f14d63/32.png) [@mhofman](https://es.discourse.group/u/mhofman)\ **Post date:** [December 31, 2021, 1:44am UTC](https://es.discourse.group/t/optional-typing/1137/8 "2021-12-31T01:44:11Z")
Having done, JSDoc style typing as well as Flow and TypeScript, I admit that there is a significant overhead with stuffing type annotations into structured comments. JSDoc is fairly cumbersome compared to TS/Flow. Furthermore, most syntax used by TS/Flow is virtually unavailable to JavaScript at this point (as-is JSX unfortunately), so an argument could be made that introducing type carve outs is codifying reality. While I'd personally love to see inert typing syntax in JavaScript, I sure am not willing to pick up that battle. ---
**Author:** ![trusktr](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/trusktr/32/183_2.png) [@trusktr](https://es.discourse.group/u/trusktr)\ **Post date:** [February 23, 2022, 7:42pm UTC](https://es.discourse.group/t/optional-typing/1137/9 "2022-02-23T19:42:25Z")
runtime type checks would be so awesome though. So the syntax would have to have runtime behavior up front to make that possible, and to avoid having one inert syntax, and one runtime syntax (if the first syntax takes up all the space, just imagine what the second one would look like). ---
**Author:** ![aclaymore](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/aclaymore/32/501_2.png) [@aclaymore](https://es.discourse.group/u/aclaymore)\ **Post date:** [February 23, 2022, 8:11pm UTC](https://es.discourse.group/t/optional-typing/1137/10 "2022-02-23T20:11:38Z")
If you haven't seen them, [there are libraries](https://github.com/fabiandev/ts-runtime) that have looked at taking the 'inert' syntax and outputting the necessary runtime checks: e.g. ```javascript function f(v: string) { ... } ``` compiles to something like: ```javascript function f(v) { assertString(v); ... } ``` ---
**Author:** ![trusktr](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/trusktr/32/183_2.png) [@trusktr](https://es.discourse.group/u/trusktr)\ **Post date:** [February 24, 2022, 8:11am UTC](https://es.discourse.group/t/optional-typing/1137/11 "2022-02-24T08:11:42Z")
Look what people voted for in [State of JS](https://2021.stateofjs.com/en-US/opinions/#currently_missing_from_js_wins): ![image](https://global.discourse-cdn.com/free1/uploads/es/original/2X/6/643f4c808c9f666a899e045b2ecb58b696189954.png) ---
**Author:** ![trusktr](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/trusktr/32/183_2.png) [@trusktr](https://es.discourse.group/u/trusktr)\ **Post date:** [March 9, 2022, 11:29pm UTC](https://es.discourse.group/t/optional-typing/1137/12 "2022-03-09T23:29:05Z")
Microsoft is putting inertia behind this proposal: > ---
**Author:** ![jithujoshyjy](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/jithujoshyjy/32/399_2.png) [@jithujoshyjy](https://es.discourse.group/u/jithujoshyjy)\ **Post date:** [March 10, 2022, 12:42pm UTC](https://es.discourse.group/t/optional-typing/1137/13 "2022-03-10T12:42:23Z")
They're doing the same thing I suggested "type hinting", a.k.a types as comments; Which nobody here's interested in unfortunately. ---
**Author:** ![ReinsBrain](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/reinsbrain/32/1165_2.png) [@ReinsBrain](https://es.discourse.group/u/ReinsBrain)\ **Post date:** [August 14, 2022, 2:35pm UTC](https://es.discourse.group/t/optional-typing/1137/14 "2022-08-14T14:35:09Z")
I have used typescript - i think it would be a great basis upon which to include optional typing into javascript. i'm thinking `'use strict-typing'` declaration at the top would be nice way to inform the javascript engine of intent ---
**Author:** ![ReinsBrain](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/reinsbrain/32/1165_2.png) [@ReinsBrain](https://es.discourse.group/u/ReinsBrain)\ **Post date:** [January 11, 2023, 3:54pm UTC](https://es.discourse.group/t/optional-typing/1137/15 "2023-01-11T15:54:10Z")
just checked back on assemblyscript after a few years - really nice progress on that project ---
**Author:** ![ReinsBrain](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/reinsbrain/32/1165_2.png) [@ReinsBrain](https://es.discourse.group/u/ReinsBrain)\ **Post date:** [January 11, 2023, 3:54pm UTC](https://es.discourse.group/t/optional-typing/1137/16 "2023-01-11T15:54:51Z")
looks like it's number 1 again this year : [The State of JS 2022: Opinions](https://2022.stateofjs.com/en-US/opinions/#top_currently_missing_from_js) although i might add that #5 on the list is Observable ( seems many missed the memo re: Proxy ) ---
**Author:** ![ReinsBrain](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/reinsbrain/32/1165_2.png) [@ReinsBrain](https://es.discourse.group/u/ReinsBrain)\ **Post date:** [January 9, 2025, 5:34pm UTC](https://es.discourse.group/t/optional-typing/1137/17 "2025-01-09T17:34:51Z")
number 1 again (and #4) on state of js 2024: [State of JavaScript 2024: Features](https://2024.stateofjs.com/en-US/features/#language_pain_points) ... looking forward to seeing [Type Annotations proposal](https://github.com/tc39/proposal-type-annotations) moving forward. ---
**Author:** ![conartist6](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/conartist6/32/515_2.png) [@conartist6](https://es.discourse.group/u/conartist6)\ **Post date:** [January 9, 2025, 11:37pm UTC](https://es.discourse.group/t/optional-typing/1137/18 "2025-01-09T23:37:02Z")
To progress to Stage 2 the proposal needs to show that the solution space has been fully explored, and that's difficult because the proposal has not articulated (does not articulate) a generalized problem statement. It is my feeling that any such generalized problem statement would make it clear that the Type Annotations proposal competes directly with other proposals for generalized parser augmentation including [DMChurch's](https://es.discourse.group/t/proposal-parser-augmentation-mechanism/2008) and [mine, BABLR](https://github.com/bablr-lang/). My solution is under very active development and specifically innovates in permitting parser extension without requiring central blessing of new syntaxes by TC39. I think central blessing of specific syntax extensions is improper in general because it creates an unlevel playing field which favors the incumbent technologies by forcing would-be new players to have a (clearly-reviled) build step unless they choose to look exactly like TS looks. If you agree with the premise that blessing a particular syntax extension is wrong but that syntax extensions in general are a proven concept which deserve support (at runtime), then it starts to look like there was tremendous progress on achieving these much-voted-for goals in 2024. I would hope that the committee will see things in the same light and will consider these as three competing proposals in the same solution space so that it would be appropriate to consider all of them before one advances to Stage 2. ---
**Author:** ![ReinsBrain](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/reinsbrain/32/1165_2.png) [@ReinsBrain](https://es.discourse.group/u/ReinsBrain)\ **Post date:** [January 10, 2025, 2:40pm UTC](https://es.discourse.group/t/optional-typing/1137/19 "2025-01-10T14:40:57Z")
Thanks for responding. I can only offer my subjective opinion which is I favor whatever gets us there sooner because it's taking a long time :) ---
**Author:** ![conartist6](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/conartist6/32/515_2.png) [@conartist6](https://es.discourse.group/u/conartist6)\ **Post date:** [January 11, 2025, 4:51pm UTC](https://es.discourse.group/t/optional-typing/1137/20 "2025-01-11T16:51:43Z")
At this point I believe I am the expert on this topic, not by way of official designation but because I've done the work of exploring the complete design space and coming up with a concrete proposal and a reference implementation for that proposal. What makes it strange is that my proposal takes the form of a bootstrapped compiler -- a system of grammars which uses its own grammars to define itself. This is really the only way to build this since BABLR is intended to replace Babel as the way in which syntaxes are proposed to (and accepted by) TC39. I don't believe that any committee is likely to be able to give me permission to do this though -- there is no process document for replacing the whole process. Should I succeed though I will create a de-facto standard which, once established, should be a natural candidate for actual standardization. [Next page](https://es.discourse.group/t/optional-typing/1137.md?page=2)