This post discusses the importance of using push notifications responsibly in Progressive Web Apps (PWAs). It highlights the negative impact of intrusive notification prompts and emphasizes the need for providing context and respecting user preferences. The post links to a helpful article and video by Thomas Steiner that provides further guidance on best practices for web push notifications, including avoiding immediate prompts and clearly communicating the value and frequency of notifications.
This blog post discusses the evolution of Progressive Web Apps (PWAs) since their inception in 2015. While PWAs offer numerous benefits like offline functionality, push notifications, and installability, the author observes that adoption hasn't been universal. Many developers and businesses misunderstand PWAs, sometimes treating them as separate products or focusing on single features like push notifications. The post argues that the focus should shift from "apps" to user experience. It proposes a set of principles for modern web experiences: discoverable, safe, fast, smooth, reliable, and meaningful. These principles aim to guide developers towards building better web experiences that naturally embody the core values of PWAs, benefiting both users and businesses.
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.
This blog post describes an experiment using Google Cloud Functions to handle web push notifications for services that don't natively support them. I needed a way to process incoming webhooks from various sources like Travis CI and GitHub, transform their payloads into a consistent format for web push, and ensure the system could scale and remain isolated. Google Cloud Functions provided a serverless solution, allowing me to create separate functions for each webhook source. The front-end receives the webhook, pushes the data to a designated Pub/Sub queue, and the corresponding cloud function processes the message and publishes the transformed data to another queue for sending the web push notification. This setup allows for flexibility, scalability, and isolation, fulfilling all my initial requirements.
This post details the creation of a generic web-push webhook endpoint. Motivated by the desire for a streamlined notification system for various web services, I built a system that allows me to receive push notifications without needing each service to individually support web push. The system consists of a front-end client, a service worker, a front-end server, a subscription service, and a send service. The front-end client manages subscriptions and provides a unique URL endpoint. The service worker displays notifications. The front-end server handles subscription data and message routing. The subscription service persists subscription information. The send service encrypts and delivers messages to the push service. While I anticipate needing to retire this as more services natively support web push, I hope this example serves as inspiration for others looking to implement similar functionality.
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.
I've spent this week in India doing more research about Web Development in India and how mobile is changing that. Publically at least it is not rosey, app development and app thinking is very high whislt building for the web with mobile in mind is very low.
