Creating a share button web component
My adventures in creating resuable web components around sharing.
I love the web. The web should allow anyone to access any experience that they need without the need for native install or content walled garden.
My adventures in creating resuable web components around sharing.
This blog post explores the potential of WebAssembly (Wasm) for full-stack development, allowing code sharing between client and server. I discuss how Wasm could enable progressive enhancement for web APIs like the Shape Detection API. Using this API as an example, I illustrate how a C-binding library like OpenCV, compiled to Wasm, could be used on both client and server to provide consistent functionality regardless of native browser support. This approach involves creating a wrapper around OpenCV and the target web API to bridge the gap between them. I express my excitement about Wasm's potential to simplify deployment and maintenance by enabling the use of a single binary across different environments.
There are lots of things happening on the web, and this is just a small list of what excites me.
I'm excited about the new experimental Shape Detection API in Chrome Canary! It provides a simple JavaScript API for face and barcode detection, leveraging underlying hardware for performance. This opens up new possibilities for web apps, from faster face detection and profile picture cropping to real-time tagging and optimized facial recognition. While currently only available in Chrome for Android (desktop support coming soon), I've shared a demo on JSBin. I also discuss strategies for progressive enhancement to ensure broader compatibility, including server-side detection, client-side JavaScript libraries, and the potential of Web Assembly. This API has the potential to revolutionize object detection performance on the web, and I'm particularly keen to see its impact on barcode scanning apps like my own QR Snapper.
I explored building a progressively enhanced sharing web component using Shadow DOM. My focus was on URL visibility and manipulation within web apps, even when they behave like native applications. The component is designed to be customizable and work across browsers, with or without JavaScript, by leveraging existing elements like anchor tags. It uses a Twitter intent as a fallback sharing mechanism when Web Components aren't supported. I'm excited about the potential of web components, even without widespread custom element support.
This post explores the concept of "reverse polyfilling" – creating polyfills for features removed from web browsers. I argue that as the web platform matures, pruning less-used features is necessary for performance and maintainability. While this might seem disruptive to developers, reverse polyfills, combined with the principles of the Extensible Web, offer a solution. By focusing on core primitives and building higher-level features with JavaScript (potentially leveraging technologies like WebAssembly), we can create a more adaptable and efficient web platform. Reverse polyfills will become essential for both removing legacy features and implementing new ones, contributing to a progressively enhanced web experience.
This is the web platform