Why isn't this just an enum?

Using an AtomicU8 instead allows us to load/store on &self, making it suitable for static variable use.

I see, lets document this please.

Please move utility functions below the public API of the module.

I think this would be cleaner if you'd match on the tuple:

match (self, handle) {
	(Self::Window(window), IntervalHandle(HandleValue::Numeric(i))) => { ... },
	// ...
}

not necessarily, we don't know what the handle is and the JsValue returned might also be an i32, in that case it is totally valid to give it to the window or worker as well.

Really? Isn't this error case somewhat impossible? The JS environment shouldn't suddenly change and return numbers instead of objects.

If we'd have dependent types then this would be type-safe, right?

Yes via dependent types this would be type-safe, but just to be a bit more on the edge of caution. I could imagine an (unlikely) case where someone changes the globals, e.g., from the nodejs ones to the browser or vice versa; in that case, we wouldn't recover. While the possibility for this is not high, I thought if we can, we can build in some additional resiliency.

Okay fair! I think it would still be cleaner to do something like the following then:

match (self, handle.into_i32()) {
	(Self::Window(window), Some(handle)) => {
		window.clear_interval_with_handle(handle);
	},
	// ...
}

Everything is pub(crate) here so I don't think we need to be this vigilant :)

Plus missing PR link.

We can't panic here, this is bad library behaviour! I'd suggest that instead of interacting with WebSocket directly here, we create an API on WebContext that makes a new connection, something like:

impl WebContext {
	fn dial(&self, url: String) -> Result<Connection, ...> { }
}

Note the &self. This forces the transport module to go through WebContext::new which already checks that websockets are supported in this environment. If it returns None you can return an Error here that fails the DialFuture with a message that websockets are not supported.