In this post, I share how I used Comlink to simplify the worker logic in my QRSnapper project, which aims to achieve 60fps UI and near-instant QR code detection using getUserMedia. The code now utilizes the Barcode Detection API within a Web Worker for efficient QR code scanning. If the native API is available, the code uses it; otherwise, it falls back to a polyfill. This approach keeps the UI responsive while offloading the processing to a separate thread, significantly improving performance.
I combined FFMPEG.js, a tool compiled with asm.js for video editing in web apps, with Comlink, a library that simplifies web worker interactions. This integration, along with my experiment of exporting FFMPEG to Web Assembly, allows for cleaner video encoding off the main thread. The provided code snippets demonstrate the simplicity of using Comlink to expose the ffmpeg interface within a web worker and then access it from the main thread as a proxy, offering a neat solution for asynchronous video processing.
I explored the power of hyperlinks beyond traditional web pages, emphasizing their potential to connect apps and websites more seamlessly. Current linking methods, while fundamental to the web's interconnected nature, fall short of the ideal. I advocate for expanding the capabilities of registerProtocolHandler to access native schemes system-wide, enabling websites to handle various content types and register as system file handlers. Furthermore, I propose a richer vocabulary of link actions beyond 'VIEW', such as 'PICK', 'SAVE', and 'EDIT', to better define website and app capabilities, similar to Android Intents and Siri's functionality. Tools like Comlink inspire this vision by simplifying cross-app communication, paving the way for link-driven function discovery and a more integrated online experience.
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!
