Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for January, 2022.

Archive for January, 2022

Podcast recording: Development tools in the expert’s eye with Chris Heilmann

Tuesday, January 18th, 2022

JS Master Podcast cover photo with Dariusz and me

Yesterday I was a guest on the JavaScript Master Podcast by Dariusz Kalbarczyk and we talked a bit more than an hour about my job as a Developer Tools PM, what annoys me the most about the toolintg situation and how the community can help. You can listen to the podcast on or Spotify .

The questions we covered were:

  • Please introduce yourself and tell us what you do?
  • The robots are coming and we need to make a great example for them. What do you mean by this text? How can we set a good example for them?
  • What computer did you start programming on?
  • What was your first computer program, were you proud of?
  • What has changed since you started programming in your perception of the world of technology?
  • Does software rule the world?
  • How many books have you written? What is the most exciting and what is the most difficult about writing a new book?
  • You work as anPrincipal Program Manager for Browser Tools at Microsoft. What is your working day like?
  • Why did you choose to take on developer tools as a new experience after being in DevRel for so long? By the way, what does being a DevRel mean to you?
  • What are the main problems you see with Developer Tools at the moment?
  • What are problems you face as a Developer Tools creator?
  • What can the community do to help you?
  • What are some things you are proud of having achieved in this role and how did you do it?
  • How big is your team? How is it structured?
  • What is going on in the development stack for the web that puzzle you?
  • You’ve been doing JavaScript for ages. Do you see patterns that keep coming up in the JavaScript community?
  • What is a term that people keep using that annoys you when it comes to coding and technology?
  • What is a finding you had in Developer Tools that might surprise people?
  • How do you measure the success of Developer Tools?
  • What is a feature you are really excited about that people should play with?
  • What do you think is needed to get us to become more effective as a community?
  • How can people learn more about what you do?
  • What do you think about TypeScript? Is there a chance that TS will completely replace JS in the coming years?
  • Do you remember the first edition of the JS Poland conference five years ago?
  • You will be performing at JS Poland soon, what have you prepared for the participants this time?

Non technical part:

  • What kind of person is Chris? How do you see yourself?
  • Do you have some hints for us regarding self-organization?
  • Do you have any favorite hobbies?
  • What about your work/live balance? Do you have some hints for us?
  • Thank you for providing a lot of valuable information during this recording. Finally, can you recommend any interesting podcast or book to our audience?

Turning a GitHub page into a Progressive Web App

Thursday, January 13th, 2022

I just released my dice simulator app and in doing so learned about a few things about turning a GitHub Page into a PWA. To make this easier for subsequent projects, I put together a bare-bones template to turn any GitHub page into a PWA. Nothing in there is sophisticated and all it does is provide installability and caching of files offline.

As a reminder, you can host HTML, CSS and JavaScript files on GitHub as pages. For example, I have bare bones To Do app at with an `index.html` document.

In the settings of this repository `simple-to-do`, I chose to publish the `main` branch as a GitHub page as shown in the following screenshot.

Settings of the repository to publish it as a page on GitHub

This means that this app is now available at Every time I publish to the `main` branch, it triggers an action and the page is generated.

In order to turn this into a PWA, a few things were needed.

Adding to the index.html

The first thing I needed to do change is the `index.html` document. I needed to add a link to the manifest, a canonical link and instantiate a service worker.

In the following example, each `codepo8` is my GitHub user name and `github-page-pwa` the name of the repository. The most crucial things to get right are the `/` surrounding the repo name.

<!DOCTYPE html>
<html lang="en">
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>GitHub page as PWA template</title>
  <link rel="canonical" href="" />
  <link rel="manifest" href="/github-page-pwa/manifest.webmanifest">
  <h1>GitHub page as PWA template</h1><script>
      if (navigator.serviceWorker) {
        navigator.serviceWorker.register (
          {scope: '/github-page-pwa/'}

Changing the service worker to make your site available offline

The `sw.js` file is the ServiceWorker that defines which of the files in the application should become available offline.

// Change this to your repository name
var GHPATH = '/github-page-pwa';
// Choose a different app prefix name
var APP_PREFIX = 'gppwa_';
// The version of the cache. Every time you change any of the files
// you need to change this version (version_01, version_02…). 
// If you don't change the version, the service worker will give your
// users the old files!
var VERSION = 'version_00';
// The files to make available for offline use. make sure to add 
// others to this list
var URLS = [    

To make this page installable as an app I needed to define the manifest.

Changing the manifest to make the app installable

The `manifest.webmanifest` file defines the name and look of the GitHub Page as an installable application. You can change the names, description, URLs and link to the icon of the application to your needs. I added comments here as to what is what.

  // Name of the app and short name in case there isn't enough space
  "name": "Github Page PWA",
  "short_name": "GPPWA",
  // Description what your app is
  "description": "Github Page as a Progressive Web App",
  // Scope and start URL - these need to change to yours
  "scope": "/github-page-pwa/",
  "start_url": "/github-page-pwa/",
  // colours of the app as displayed in the installer
  "background_color": "#ffffff",
  "theme_color": "#ffffff",
  // Display of the app. 
  //This could be "standalone", "fullscreen", "minimal-ui" or "browser"
  "display": "standalone", 
  // The possible icons to display. Make sure to change the src URL,
  // the type and the size to your needs. If the size isn't correct, 
  // you may not be able to install the app. 
  "icons": [
        "src": "/github-page-pwa/img/icon.png",
        "type": "image/png",
        "sizes": "700x700"

And that’s it. You can start by forking the repository and changing it to your needs. It comes with an extensive README.

Offline? No dice!

Tuesday, January 11th, 2022

Dice in the cloud

A few days ago I was on vacation in a place that had terrible mobile connectivity and whilst it provided WiFi, nothing worked. I even brought my own cables and travel router, but to no avail. This was not only a good opportunity for some “digital detox”, but it also showed me once again that the web isn’t as resilient as we want it to be.

Here’s what happened: one evening we went to the hotel lounge to play some games. They had a library with some, but the one thing that was missing was a dice.

Not to worry, I thought, and went to look on my mobile phone to get a quick dice solution on the web. There are a lot out there, but here’s the kicker: I couldn’t find any that loaded quickly and subsequently worked offline. None. At. All. Any web search for “offline dice” resulted in tons of apps advertised to me. Other online solutions are riddled with ads and have a first load of several megabytes. Interestingly enough, searching on Desktop has better solutions – the place were you are less likely to need a simple solution that works offline. There is also a huge difference between search engines.

Even those that are excellent in their randomness like the one on do a reload of the whole page on every “throw” of the dice. Others implemented the sides of the dice as images and didn’t preload them.

“Simulating a dice throw” is an example of every programming language tutorial I’ve ever seen. I remember learning BASIC and Pascal and these were parts of it. I’ve also seen this come up in job interviews back in the day. Offline functionality is also not that hard to do. A simple single-purpose web product like a dice simulator should be not hard to release. It seems the lure of selling it on an app store or making money with it by surrounding it with ads is a bigger incentive though.

The solution was to go back to the hotel room, get my laptop and write a JavaScript solution in a local file whilst my partner went out for a cigarette break. I am not proud of the code, but I also had a few drinks before – and it did the job.

It made me think though. Despite dozens of tutorials, books, presentations and videos, considering offline and bad connectivity is still not ingrained into our thinking as developers.

When HTML5 became a thing and the web went mobile first, offline availability was a main need to match native apps. Earlier approaches like AppCache had a lot of issues which is why we came up with ServiceWorker. ServiceWorker went through a lot of iterations, and as it was designed to cater to a myriad of use cases, it became complex. Many people use abstraction libraries like Workbox instead.

And, I am to blame, too. Last year I released a dice emulator for fun and the thing I didn’t do is to make it work offline. Although it was a single HTML document. Now I added that functionality. So if you go to it now, it loads quickly even on a horrible connection and will subsequently work offline. You can also install it as an app.

A dice throw simulator in the browser.

I will write up in detail how to do that, but the source code should give most of the clues. The biggest obstacle was to make it work with GitHub pages rather than a bespoke domain (which I may add later).

To me, this taught me to be more concerned about edge cases of our users. I want the web to be there for people when they need it. And if the functionality they need is a random number between 1 and 6 they shouldn’t have to download an app for that. So let’s embrace a flaky web in everything we do.