Hello.

I built a web app using Deno, Fresh, and TensorFlowJS to classify images as links or buttons. The app uses a pre-trained ML model and allows users to drag and drop multiple images for classification. I encountered challenges with server-side rendering and islands, specifically with integrating a file-drop web component. I also documented the process of integrating the TensorFlowJS model, including model loading and prediction handling. The code is available on GitHub.

While searching for a markdown editor on webcomponents.org to simplify blog posting, I discovered a useful collection of web components by Github. I was already familiar with their but was pleasantly surprised to find such a comprehensive and easy-to-use set of elements.

I've just added the pinch-zoom-element web component to my photography blog. It's a tiny (~3kb), dependency-free custom element that allows for easy pinch-zooming on any HTML element. Check out the implementation on my blog (touch-enabled device/trackpad needed for testing) and see how simple it is to integrate! This element was crucial for the Squoosh app and perfectly exemplifies the power of web components for clean, reusable UI. I hope to see wider adoption of elements like these, especially for common use-cases like image zooming on e-commerce sites.

I couldn't find an easier way, so I built it myself

Possibly the world's best airhorn now as a custom element

Custom Elements need clear and parsable API documentation.

This little doozey hit me, so I'm documenting incase anyone else has the same issue

My adventures in creating resuable web components around sharing.

I'm exploring the best way to load web components, focusing on how to include styles and templates without creating uncontrolled blocking requests. I've experimented with using a single JavaScript file that encapsulates everything, including styles and a dynamically created template element. This approach avoids external requests but raises questions about extensibility and best practices. Should we revive HTML imports, embrace ES modules, or find a common model for handling templates and styles? Is inlining templates a reasonable solution? I'm looking for community input on how to balance performance and developer experience when deploying web components.

There are lots of things happening on the web, and this is just a small list of what excites me.

Web Components, specifically Custom Elements, offer exciting possibilities for web development. However, the current ecosystem is still evolving and has potential downsides. The practice of namespacing custom elements (e.g., <amp-*>, <iron-*>) creates "walled gardens" that can lock developers into specific frameworks. While understandable in the early stages, this approach hinders interoperability and leads to duplicated functionality. Ideally, we should move towards a shared vocabulary of elements (like <aspect-image>) where developers choose the implementation, not the vendor-specific element name. This requires a standardized process for defining element names, interfaces, and functionality. Imagine a world where component creators define the contract (e.g., class ShareButton extends HTMLElement { ... }) and users choose their preferred implementation. This model puts developers in control and fosters a more open and interoperable web. Furthermore, meta platforms (like Facebook or WeChat) could play a role by intercepting customElements.define calls and replacing JavaScript elements with native implementations when possible. This approach requires careful consideration, but it could lead to a more streamlined and integrated user experience.

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.

A weekly run-down of some interesting things that I have found