[Use-case] WoT in the Browser

[danielpeintner]

This is a feature proposal, need a user story (and MAYBE a new use case) to define what it is for. Should discuss with node-wot and the Scripting API TF (who would probably be the ones submitting use cases and user stories).
@danielpeintner @zolkis @relu91

Originally posted by @mmccool in #3

[zolkis]

The main problem with "WoT in the browser" is getting the native dependencies linked in the browsers. That will very likely not happen. Also, we cannot assume the existence of local services/protocols and workers.

The only viable "WoT in the browser" option is using HTTPS.

That has no effect on the Scripting API shape.

But it does affect implementations, therefore the specification.

[relu91]

The only viable "WoT in the browser" option is using HTTPS.

*and websockets (and mqtt/coap over websockes ).

That has no effect on the Scripting API shape.

I agree it does not change that much from our point of view.

[relu91]

Scripting API 19/02/2025:

• Scripting API task force acknowledges the fact that in the past there weren't any concrete requirements to ask for native support in the browser for a WoT runtime.
• Still using the Web of Things in the browsers is a valid use case but it can be done through libraries that "polyfils" Scripting API functions. -> We still have to report back and write a feature request to the use cases taskforce.
• Discussing concrete next steps in the main call.

[benfrancis]

The ConsumedThing interface could be (and possibly is?) implemented as a re-useable client-side JavaScript library which web applications can use to consume Things which can be interacted with using existing native browser APIs such as fetch (HTTP), WebSocket (WebSockets) and EventSource (Server-Sent Events)*. Protocols like CoAP and MQTT can technically be used as WebSocket sub-protocols, but that would require both the Thing and Consumer to implement the WebSocket protocol first, these protocols can not be consumed directly using existing browser APIs. Consuming any other protocol in client-side JavaScript would would require natively implementing that protocol stack (and a finite set of sub-protocols in the case of WebSockets) in web browsers, which I think is a big ask and I'm yet to come across compelling use cases to justify that.

The ExposedThing interface is not really possible to implement using existing browser APIs for any practical purpose and it wouldn't make much sense as a client-side JavaScript API.

Since no browser vendor has expressed an interest in natively implementing the Scripting API, I continue to hold the view that it could just be a JavaScript library (for both client-side JavaScript in browsers, and Node.js where more protocols can be supported), as opposed to a web standard.

If that library became wildly popular with web developers then it's possible browser vendors would eventually consider some kind of native WoT features (that's how we got features like query selectors and web components in browsers), but until then I think "WoT in the Browser" is at best a re-useable JavaScript library.

---

* We consume all of these protocols using client-side JavaScript in the web front end of WebThings Gateway, though not using the Scripting API.

[benfrancis]

BTW, there is a slightly different use case for WoT in the browser that I'm interested in, which is using WoT as a mechanism for client-side JavaScript in web pages to access local hardware capabilities, but I don't think that's what is being talked about here and is really orthogonal to whether the Scripting API is natively implemented in a web browser.

[relu91]

Scripting API call 05/03/2025:

• To clarify, we are aligned with @benfrancis's comment above. We just want to keep the use case because having Web of Things in the browser is not just about the Scripting API, but it influences all the other documents (TD, Discovery etc.)

If that library became wildly popular with web developers then it's possible browser vendors would eventually consider some kind of native WoT features (that's how we got features like query selectors and web components in browsers), but until then I think "WoT in the Browser" is at best a re-useable JavaScript library.

In particular, we are aligned with this statement.