I've always been fascinated by the potential of the web as an API, an idea I first encountered through Michael Mahemoff's work with microformats and CORS. While technologies like Web Intents explored similar concepts, they proved more complex. The core idea remains powerful: enabling direct client-side interaction between websites to bypass the complexities of server-side integrations. Although CORS is widely supported, its complexity hinders adoption. With the rise of client-side generated sites, the need for decentralized integration is stronger than ever. Tools like Comlink, by abstracting the complexities of postMessage and MessageChannel, make it easier to expose and consume client-side APIs. I demonstrated this with a simple example integrating a pubsubhubbub endpoint with a push notification service. This approach offers several advantages, including simplified data transfer, offline capabilities, and secure, controlled exposure of functionality. Looking ahead, I envision a future where every website exposes a consistent, discoverable API, enabling a more interconnected and modular web experience.
I've been exploring solutions to connect web apps and overcome the limitations of isolated experiences. Web Intents was a good start, but ultimately fell short. The Share API helps, but we need a more general solution for IPC and service discovery. My latest experiment builds on the Tasklets API and Comlink, allowing seamless communication between windows and web workers. It simplifies the complex postMessage API and makes it easy to expose and consume APIs across different contexts. I've created a service discovery mechanism where a 'middleman' site keeps track of available services. Clients can request services based on criteria, and the middleman facilitates the connection. Once connected, the client and service communicate directly, bypassing the middleman. This approach simplifies the developer experience and makes it much easier to build interconnected web experiences. Check out the demos and let me know your thoughts!
WebMessaging (postMessage) seems simple but has quirks. Different browsers handle data differently (structured clones vs. strings). The biggest problem is sending messages to a newly opened window/iframe. You can't just send a message immediately; you have to wait for the window to load and signal back. This adds complexity, requiring the new window to postMessage back to the opener, which then sends the actual data. A workaround involves passing data via window.name, but this has security implications as the data's origin is uncertain and the name persists, potentially exposing data.
