[Tracker] Implemented Web APIs

[crowlKats]

This is a list to track the Web APIs (as per MDN API specifications list) that are implemented in Deno.

• Ambient Light Events

• Background Tasks

• Beacon

• Bluetooth API

• Broadcast Channel API

• CSS Counter Styles

• CSS Font Loading API

• CSSOM

• Canvas API

• Channel Messaging API

• Console API

• Credential Management API

• DOM

• Encoding API

• Encrypted Media Extensions

• Fetch API

• File System API

• Frame Timing API

• Fullscreen API

• Gamepad API

• Geolocation API

• HTML Drag and Drop API

• High Resolution Time

• History API

• Image Capture API

• IndexedDB

• Intersection Observer API

• Long Tasks API

• Media Capabilities API

• Media Capture and Streams

• Media Session API

• Media Source Extensions

• MediaStream Recording

• Navigation Timing

• Network Information API

• Page Visibility API

• Payment Request API

• Performance API

• Performance Timeline API

• Permissions API

• Pointer Events

• Pointer Lock API

• Proximity Events

• Push API

• Resize Observer API

• Resource Timing API

• Server Sent Events

• Service Workers API

• Storage

• Storage Access API

• Streams

• Touch Events

• URL API

• Vibration API

• Web Animations

• Web Audio API

• Web Authentication API

• Web Crypto API

• Web Notifications

• Web Storage API

• Web Workers API

• WebGL

• WebRTC

• WebVR API

• WebVTT

• WebXR Device API

• Websockets API

[kitsonk]

We will never implement all the web APIs. We have been implementing them on a case by case basis as there has been a compelling need. My fear would make people assume that all of these are needed or desired.

[hayd]

These should be grouped into Done vs Todo vs OutOfScope.

Though I'm not sure how that should be decided 😄

[crowlKats]

We will never implement all the web APIs. We have been implementing them on a case by case basis as there has been a compelling need. My fear would make people assume that all of these are needed or desired.

@kitsonk i am aware of that; i just listed them all out as i am not sure which ones wont ever be implemented. As @hayd said, there should be an OutOfScope section. Done & Todo can be seen by checkbox.
I assume all the CSS ones & DOM can be marked as OutOfScope, no? Touch & Vibration as well

[kitsonk]

They have been decided on a case by case basis backed by them making sense. To go through and evaluate them all, they may make not make sense right now, but they may in the future. They may seem like a good idea, and then it doesn't end up making sense.

I would say, if someone has a use case, they would raise an individual issue for that. They should be evaluated on a case by case basis. An issue like this will be horribly noisy and get out of date very quickly.

[crowlKats]

Hmm i see. but it is kinda a pain not to have a proper place where all implemented Web APIs, which are being worked on, and which ones are not gonna be ever implemented are listed...

[cknight]

Perhaps the manual would be a better place, where a straight list of implemented Web APIs could be listed? No need to list the unimplemented ones.

[Soremwar]

I also think that the manual is a better fit for something like this. However having it pinged somewhere in here would be of more use of the Deno developers (tracking progress, check stallation, etc).

I would tick anything related with DOM as browser specific and we can start discarding from there to "possible use case". This APIs can of course be implemented by a specific use-case (electron like app) but out of scope for Deno team.

Browser specific:

• IntersectionObserver
• HTML Drag and Drop
• DOM
• CSS Counter Styles
• CSSOM
• Canvas
• Fullscreen
• Gamepad
• History
• Image Capture
• Etc

[nayeemrmn]

it is kinda a pain not to have a proper place where all implemented Web APIs, which are being worked on, and which ones are not gonna be ever implemented are listed...

I agree about having a list for already implemented web APIs somewhere in the manual, maybe even including "definitely coming soon" ones. It's important to know what's available to use in a portable script. EDIT: This is given in the doc by simply ignoring the Deno namespace...

"It is kinda a pain not to have a proper place where all x-related features which are being worked on, and which ones are not gonna be ever implemented are listed..."

Why are web APIs special in this regard? This isn't one big problem that Deno is trying to tackle, it's just when a feature is considered we look for a web equivalent and maybe borrow it's spec. The "list of web APIs" isn't a significant topic that benefits from tracking.

This is also misleading as no one can know anything about what's ruled out in the long term. For example, some of those discarded by @Soremwar I've heard be explicitly left on the table depending on how GUI support came to look, but at the same time should definitely not be on any todo list.

[kitsonk]

Well, and to say "anything DOM related is out" is also misleading. EventTarget is implemented and it is a DOM thing. In fact because it is spec compliant, it already knows about things like Node and ShadowDOM, though those are implemented.

It really is a case by case basis, when there is the ability to deliver and a compelling use case, which is always changing, just like web APIs themselves.

[Soremwar]

I didn't say discard all at once XD

Just check use cases. If it fits in Backend then it's possible, if required then doable by Deno

[David-Else]

@kitsonk Where do I actually find a list of Web API's I can use? In VS Code for the Deno namespace I can use intellisense, but how do I even know other methods exist? I searched the manual, is this not a massive omission? Cheers.

[David-Else]

@nayeemrmn Cheers! I didn't know deno doc could do that.

[crowlKats]

What about having a list of implemented ones & wanted ones, instead of missing ones? that should make this more appropriate and easier to manage, and wont confuse people.

[mash-graz]

i would really appreciate bowser compatible webaudio and audioworklet API support in deno for sound app prototyping.

[crowlKats]

As this issue indeed can confuse people, i shall close it, so people dont come here with wrong ideas.

[HansUXdev]

Perhaps the manual would be a better place, where a straight list of implemented Web APIs could be listed?

I'd be happy to volunteer to document this on the manual.

Building off what has already been said above, if there was a new section in the manual for tracking the implementation of various web API's, I'd recommend dividing it into sections of:

• proposed (an individual use case of a given API and how deno would benefit)
• exploring (an API people have started working on implementing)
• done (shipped feature, with use case examples and change notes)
• abandoned (not align with goals or not compatible)

Perhaps even a subsection under proposed for API's that address the same category of issue, for example hardware / mobile app development (For serial, USB, I2C, etc see #6210 ).