Consider ecmascript-types instead

[jimmywarting]

Just saw this landed stage1

i fear that this will land into browser, this will only do type annotations and dose literally nothing about type safety.
It's as you said: "At runtime, a JavaScript engine ignores them, treating the types as comments"

I don't like this proposal. we already have comments /**/, // and we already have jsdoc that works as equally well as anything else.

I'm all for type system languages but this will not bring in any benefit into the browser what so ever. it will only make the parser more complex and more slow. with 0 benefit.

ecmascript-types on the other hand is way better, it lets you use real type system. it won't just to give developers static type checking. It's to offer information to engines to use native types and optimize callstacks and memory usage. Ideally engines could inline and optimize code paths that are fully typed offering closer to native performance.

[Andrew-Cottrell]

This is partially addressed in the README, in the section Why not define a type system for JS in TC39 instead?

In summary, the three points mentioned are

1. Performance of non-erased type checks at application startup and application runtime.
2. Improved type analyses would become breaking changes for end users.
3. Enormous multi-year effort that may never reach consensus.

How would the suggested alternative address those three points? Or could it be argued those three points may be incorrect or mitigated by some means?

JSDoc annotations and inline comments provide a solution already (as used by Closure Compiler and supported by TypeScript), but -- as mentioned in Why not stick to existing JS comment syntax? -- they are considered by many to be verbose and unergonomic. Are there some arguments that might convince people otherwise?

In addition, one of the ideas/goals for the current proposal is to partially un-fork JavaScript variants (e.g., Flow, TypeScript) by enabling use of large parts of Flow, TypeScript, and other syntaxes within standard JavaScript syntax. Would the suggested alternative help to partially un-fork JavaScript variants? Or is there an argument against attempting to achieve this goal?

[jimmywarting]

no matter if we add "type annotations" or "ecmascript-types" then it's going to be breaking changes.

if you write this "optional" "type annotations" as an example:

function sum(this: SomeType, x: number, y: number) {
}

then you have already broken the web b/c this syntax dose not work as of right now. This too is also a breaking change. if they are going to be optional then they have to be removed even before it reaches the JS engine.

IMO i think a browser extension or NodeJS "Transpiler loader" should be in order. or even a server that transpiles TS files on the fly.

I don't think Type Annotations should be a part of the javascript language. as it dosen't bring any befits what so ever into the the javascript runtime. it's only going to break websites even more and making the parser slower. some browser will not be able to catch up with all new things that happens and will only lead up to more browser war monopoly

if we had things like int8, int16, bool etc then that is something that could be optimize of how javascript allocates memory and how it operates and that is something i can stand behind and support. i would feel at ease knowing that a variable could not be anything else. and not via some losed optional typed annotations that dose nothing.

---

I have actually used TypeScript a lot myself (with the help of JSDoc ofc) but what i have learned over the years are that most often you don't even have to annotate your code to get type support either with typescript or jsdoc

and instead of writing code like this:

function getAudioDuration(url) {
  var audio = new Audio(url)
  
  return new Promise<number>(function(resolve) {
    audio.onloadedmetadata = () => resolve(audio.duration)
  })
}

then you can write code like this:

async function getAudioDuration(url) {
  var audio = new Audio(url)
  await new Promise(resolve => audio.onloadedmetadata = resolve)
  return audio.duration
}

VScode can successfully figure out that you return a promise that resolves with a number. you get just as much type info back from it if you only think a little bit more differently

---

the only reason why we want type annotations is b/c of better IDE, to that i say that we can just improve the code editor intelligence instead.

[spenserblack]

I'm likely in the minority in this opinion, but I care less about how types can enforce checks at runtime or compile-time, and more about how they can improve code readability and documentation. Personally, I've found generated documentation with types to be far more readable and navigable than without types (see docs.rs and pkg.go.dev for examples). This is because the majority of the time that I go to read docs I'm not looking for a highly detailed guide, but just a quick reference on what utilities are available, what I need to pass to an API, and what do I get back.

this will not bring in any benefit into the browser what so ever.

I'd say that type annotations are useful the same way that documentation comments are useful.

Consider this example code (pretend that [].forEach didn't exist):

function traverse(array, fn) {}

traverse(array is pretty self-documenting. I don't need types nor doc comments to figure out that it traverses an array. But what's fn? Likely a function, but what does that function take? Likely an item in the array, but what about any other args? Does it take an index, for example? If so, which order are the args in?

Now, consider this (typescript used for familiarity):

function traverse<T>(array: T[], fn: (item: T, index: number) => void) {}

Now I know that fn takes an item from the array and an index, in that order. Personally, I find this function signature to be self-documenting enough that doc comments aren't needed. Of course, the reverse is true: if I had used doc comments, I wouldn't have needed type annotations to fully describe the traverse function. But (again, just my personal experience) I think it's much easier to learn how to write type annotations than to learn how to write doc comments like JSDoc. A tool to generate documentation can use those type annotations to achieve the behavior of @param, @return, and @link together.

For more complex documentation (e.g. example usage, deprecation notices) type annotations alone aren't enough. But for the documentation of small, simple utilities provided by a library, I'm hopeful that the ability to write type annotations can improve documentation in the future.

When talking about types in this proposal's issues, I've seen a lot of conversation focusing on the behavior of code with types. In this context, I would call writing types human-to-machine communication ("I want the compiler to ensure this is the type I want"), and type check errors machine-to-human communication ("you made a mistake and need to fix your types"). But I would encourage more thinking on how type annotations can achieve human-to-human communication ("this is the library I provided and here's how to use it").

[romulocintra]

Just saw this landed stage1

i fear that this crap will land into browser, this will only do type annotations and dose literally nothing about type safety. It's as you said: "At runtime, a JavaScript engine ignores them, treating the types as comments"

I hate this proposal. we already have comments /**/, // and we already have jsdoc that works as equally well as anything else.

I'm all for type system languages but this will not bring in any benefit into the browser what so ever. it will only make the parser more complex and more slow. with 0 benefit.

ecmascript-types on the other hand is way better, it lets you use real type system. it won't just to give developers static type checking. It's to offer information to engines to use native types and optimize callstacks and memory usage. Ideally engines could inline and optimize code paths that are fully typed offering closer to native performance.

Hi @jimmywarting we welcome all feedback, opinions, and ideas but first, all contributions should align with CoC, OSS and community are free places to speak but always be respectful for the work , authors, champions or colleagues are doing trying to bring what they believe is the best for the language, However all opinions matter and feel free to give feedback but in a constructive manner so we all can collaborate and try to make the language we all ❤️ the best place for everyone. cc @ljharb

[jimmywarting]

@romulocintra why did you close this issue? i want others to hear about ecmascript-types too and fill in what other ppl think of this. doe i would rather have posted this in a discussion but that was not enabled in this repo.

[ljharb]

I'm not sure how an issue opened with this kind of vitriol can evolve into a reasoned discussion on an alternative proposal.

Separately, ecmacript-types seems quite out of date; it still references SIMD which was withdrawn in 2017, for example.

[jimmywarting]

okey... but are there any other issue open that addresses the importance of having real type system instead of just annotating?

[ljharb]

#43

[hinell]

ecmascript-types on the other hand is way better

Neither are good IMO. They introduce awful syntax: generics.