Deno: Implement WebSocket client

[axetroy]

ref:

1254

https://github.com/denoland/deno_std/pull/84

// global WebSocket client
console.log(WebSocket)
console.log(window.WebSocket)

[clemens-tolboom]

Guess this can be closed as we have https://deno.land/std/ws/

[JohanWinther]

Deno is careful to not deviate from standardized browser JavaScript APIs. Of course, not every browser API is relevant for Deno, but where they are, Deno does not deviate from the standard.

Users will expect a global WebSocket client constructor (just like Date). But, is it possible to include the std/ws WebSocket implementation in the global namespace without writing it natively?
Would you even want to?

Correct me if I'm wrong, https://github.com/denoland/deno/issues/1254#issuecomment-451145810 implies that anything that is implemented in TypeScript needs to be put in deno_std, but I can't figure out if this is due to a technical limitation or convention.

Right now it looks like the WebSocket client is the only exported class in deno_std which also has a corresponding global constructor in browsers, so perhaps this kind of "issue" will affect future classes too.

[gbrlsnchs]

The defacto client should be the one from the WebSocket API, if browser compatibility is the goal.

https://deno.land/std/ws/ should still exist for WebSocket servers and non-compatible clients, if desired. It could even use the native WebSocket client implementation later somehow (be a wrapper around it, maybe?).

[edenprojectde]

Is there any way to hack browser compatibility as of rn?
I get a handshake error if that is currently expected i won't open an issue.

main.js:1 WebSocket connection to 'ws://localhost:8090/' failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received

Or is it an issue? I don't know. This sound's kinda like it is the current state of affairs. :')