Hello.

akachan.app is a Single Page Application (SPA) built for instant loading without using JavaScript on the client-side. Instead, all JavaScript resides in a Service Worker and is also executable on the server. This approach offers significant performance benefits but introduces challenges regarding third-party sign-in integration and data synchronization.

I built a simple tool, shortcut.cool, to create custom launchers for Android using the web. It leverages the power of PWAs, service workers, and the web app manifest, specifically the shortcuts feature. The tool allows you to define a set of .new domain shortcuts, which then get encoded into the URL. This URL points to a dynamically generated manifest file that Chrome uses to install the PWA with the specified shortcuts on your home screen. The project is a bit of an experiment and has some limitations, like the inability to update existing PWAs and potential security concerns from URL-encoded data. However, it’s a fun example of how the web can be used to create quick, personalized tools.

I needed a streaming template engine for a web app I'm building that works in Node.js, the browser, and service workers. Existing solutions like flora-tmpl were great for Node.js, but I needed something smaller and compatible with all environments. So, I created whatwg-flora-tmpl (name pending), a lightweight library based on the WhatWG Streams API. It uses template literals, handles dynamic content, and even supports nested streams. The example code demonstrates how it can be used to render HTML responses piece by piece instead of waiting for all data, significantly improving perceived performance. It's particularly useful for responses generated in service worker fetch events. Big thanks to Matthew Phillips, the creator of flora-tmpl, which served as the inspiration for this project.

While building a simple CRUD PWA using only service worker JavaScript and relying on Form submissions for data handling, I encountered an issue with Safari not supporting request.formData(). I created a small shim to work around this by parsing the x-www-form-urlencoded request data as a query string and using URLSearchParams to process data similarly to a FormData object. This approach isn't suitable for multipart forms and requires a different solution.

This post introduces a simple yet effective approach to improve offline user experience on the web using Service Workers. Instead of a browser's default offline page, this method displays a custom offline page when the network is unavailable. The provided JavaScript code caches essential offline assets and intercepts navigation requests. If a request fails due to network issues, it serves a pre-cached 'offline.html' page, ensuring a smoother experience for users. This strategy enhances user perception of web applications, especially in areas with unreliable internet connectivity. A key improvement mentioned is the use of Navigation Preload, which optimizes the loading process by not waiting for the Service Worker to boot up for all requests.

Topicdeck is the module that aggregates a selection of RSS feeds into a tweetdeck style view

CSP nonce values can help you securely run inline content on you site. But it can be hard to get it working with Service Workers... until now.

Building Progressive Web Apps progressively is possible. This is how I did it.

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.

In this post, I discuss a new routing framework I've added to my service worker. It's based on my older LeviRoutes project and allows me to handle different URL patterns separately. This is much cleaner than a complex onfetch handler, and lets me easily manage things like requests to analytics services and my caching strategy. While sw-toolbox is a great alternative, I enjoyed the flexibility and learning experience of building my own. I encourage you to check out the code and consider routing in your own service workers.

In this follow-up post, I've revised my blog's Service Worker and caching strategy to address previous issues, particularly the Firefox incompatibility due to the use of waitUntil and a misunderstanding of cache.put. The updated strategy now correctly fetches from the network, caches the result, and serves content from the cache, falling back to the network request if not found. The code has also been improved for readability and reliability.

Do we need a browser in the future?

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.

On the web determining and adapting to network type the user is on is incredibly hard. Until now.

What are the properties that make the web the web? How can we keep differentiating from native to stay relevant in a mobile world?

Some quick thoughts about not using CSP when you have a Service Worker.

Is it possible to build a 2 factor authentication system on the web? I think it is.

It might be a hard sell, but there are number of advantages to using the web.

Possibly the world's best airhorn.

A simple Express like

This blog