WebIDL

[nstansbury]

Whilst I absolutely applaud the proposal and appreciated the TS community has a long standing usage of this syntax style, I am puzzled why integrating WebIDL https://webidl.spec.whatwg.org isn't the ideal design choice for ECMAScript?

WebIDL is a well defined, existing standard for the web that is widely used. WebIDL already has ECMAScript bindings. WebIDL maps ECMAScript types neatly to existing web interfaces WebIDL allows bindings into other languages. WebIDL is far less verbose and more precise than JSDoc. WebIDL fragments could be declared inline as well as in external interface files. External WebIDL files could be imported into a runtime environment in the same way source maps are.

This proposal feels like a lost opportunity to take advantage of a powerful existing standard.

[jimmywarting]

IMO i don't think that we need new type flavoured syntax suger, what we really need is a IDE/editor that can work with existing WebIDL/ECMAScript bindings and be able to hook in to the engine instead maybe via devtool-protocol.

This proposal don't bring any real benefits to the table like https://github.com/sirisian/ecmascript-types dose. This is just seen as optional type hinting that are simply just striped away at runtime, there is no type safety checks to this what so ever. so i don't understand why we would need this.

DefinitelyTyped is always going to be one step behind in what's actually implemented into the browser and it just keeps on growing and making lots of typing mistakes. Here is just some few examples:

// here is just a few examples:
new ArrayBuffer() // Expected 1 arguments, but got 0.
fetch(new URL('/')) // Argument is not of type `RequestInfo`
new Date() + 1000 // Operator '+' cannot be applied to other types
new Blob([{}]).text() // is not assignable to type 'BlobPart'.
1 + true // Operator '+' cannot be applied to other types

Javascript is a dynamic language so it don't sit well along with a typed language. WebIDL conversion in all of the above samples works just fine, but TypeScript don't see it that way and has no understanding of what is going on or what the return type will be... it has no toPrimitive or WebIDL understanding of what's really going on.

I think that if you are really into the typed languages then maybe javascript isn't the right fit for you and you should maybe look into rust, go or any other typed language and instead compile it to WebAssembly instead...

DefinitelyTyped is also very selective in what browser features it should bring in only if two vendor agree to implement something would it actually bring it in and it's a manual process. if we had true bindings to browsers WebIDL stuff then we wouldn't need to redefine every new feature that comes our way manually.

Do you wish to use what's new and available in google canary? nope, you can't without getting red lines everywhere cuz there isn't any d.ts for it yet. but the inspector (devtool protocol) knows exactly what properties eg FileSystemDirectoryHandle.prototype has and dose not have including things like moz, webkit prefixes. Hooking a editor into any engine's WebIDL would be a game changer.

I don't like to use TypeScript sytax due to how many things it complains about that is perfectly legit usecases. In my eyes TypeScript is just seen as any other compile-to-javascript language like coffeescript or flow that isn't really a language that runs natively without being compiled to javascript in the first place. I don't like to use it cuz types don't fit into javascript dynamic language features, it's like trying to fit a square into a circle.

[ljharb]

See https://github.com/tc39/proposal-idl

There’s all sorts of reasons web IDL is actually not a good fit for the language - it’s built to describe what web APIs do, which is a subset of what JS can do, and also doesn’t exactly match what people do with existing type systems.

[simonbuchan]

@jimmywarting You are largely complaining about typescript complaining about implicit type coercion, which is a common source of bugs and a goal of typescript to help you to avoid. For example, you are very unlikely to actually want new Date() + 1000 to give you "<current date toString() result>1000" or new Blob([{}]).text() to return "[object Object]", and if you do it's clearer to do it explicitly: new Blob([String({})]).text(). In all these cases, it's nothing to do with the typing declarations and everything to do with the language behavior. A typing system that never complains is quite easy to write, after-all.

There's a better argument for the first two... except:

• ArrayBuffer is specified to take a length argument, which has the internal semantic operation ToIndex() called on it unconditionally. This has the effect of it defaulting to 0, but it's equivalent to calling any function that expects a number argument that happens to behave like you passed 0 - a coincidence, not a design goal.
• fetch() is defined by WebIDL to take a a RequestInfo, which is defined by WebIDL to be either a string or a Request instance. Moving to WebIDL isn't going to save you here - you would, like above, also need to provide the semantic specification, which is that the fetch() arguments are treated as-if passed to new Request()... which is also specced to take a RequestInfo as it's first argument... and it's semantic specification is "5. If input is a string, then: ...; 6. Otherwise: { 1. Assert: input is a Request object. ... }" ... so technically fetch() shouldn't accept a URL.

Incidentally, these types are already generated from spec WebIDL (and MDN compat data), and you can choose to provide different, including more up to date, typings if you have an issue (and ambient declarations / declaration merging doesn't work for you):

• https://github.com/microsoft/TypeScript-DOM-lib-generator
• https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modules