Wrinkles, Crinkles and lumpy bits.

Tired of typing in usernames and passwords? So are your users. Autofill helps, but the Credential Management API gives developers more control. It lets you securely store and retrieve user credentials, simplifying logins with just a couple of taps. This Chrome-only API allows access to a PasswordCredential object, rather than raw passwords. It works with other improvements like proper autofill fields (email, username, new-password, current-password) and offers a potential future where landing and login pages are obsolete. Imagine a web where users stay logged in seamlessly, only re-authenticating when necessary. This post covers how to implement the API, including a demo and sample code. Plus, explore how it might combine with the Web Payment Request API to streamline e-commerce.

TL;DR - Went well. Lots to learn.

This blog post discusses the implementation of a Service Worker for my blog, with a focus on the caching strategy. I've chosen a "Stale While Revalidate" approach, which prioritizes speed and resilience. The Service Worker intercepts network requests and serves cached content if available, while simultaneously fetching updated content in the background. This ensures the latest version is available after one refresh. The post also details the requirements considered when choosing this strategy, including development simplicity and compatibility with the existing hosting setup (Hugo and NGINX). The provided JavaScript code snippet demonstrates the Service Worker implementation.

This post explores using WebTorrent for serverless data synchronization in web apps, demonstrated by modifying the Voice Memos PWA. The goal was to enable data sharing between devices without a backend server. The solution involves generating magnet URLs that allow peer-to-peer data transfer via WebTorrent. The demo app allows recording audio, saving it locally, and generating a shareable magnet link for access on other devices. This approach offers an interesting alternative to traditional client-server models, especially for scenarios where scalability and serverless operation are desired.

This post revisits the UX issues that contributed to the demise of Web Intents. We never adequately addressed the wide array of potential actions and data types, leading to a generic and confusing user experience. Handling data return from a long-running operation in another app proved problematic, especially if the initiating app closed. The lack of an explicit API for expecting returned data, similar to Android's startActivityForResult, further hindered the development of intuitive UI affordances. The open nature of Web Intents resulted in a proliferation of schemas and protocols, making standardization difficult. Users were forced to choose an app for every action, and developers lacked control over how apps launched, leading to inconsistent experiences. Finally, the absence of reliable fallbacks for unsupported intents eroded developer confidence and potentially left users stranded. In short, a combination of UX shortcomings ultimately led to Web Intents' downfall.

This post explores how to use Android Intents to detect if a native app is installed. This technique is useful for web apps that also have a native app version, especially for managing push notifications. It allows developers to seamlessly redirect users to the app if it's installed or fall back to the web experience. The method involves creating a special intent URL that opens the app if present, or redirects to a specific URL with a hash fragment. By monitoring the hash change in the browser, the web app can detect if the app launch failed and proceed with web-based push notification registration. While helpful, this approach highlights the complexity of managing push notifications across web and native apps, reinforcing the argument for web-only solutions.