In Part I of this series, dreaming of the Honeywell H316 Pedestal Kitchen Computer, I stuck a cheap Android tablet to my fridge with fridge magnets, a hot glue gun, and a passing reference to Stewart Brand’s idea of “shearing layers.” That’s the hardware architecture sorted. In Part II, I’m going to put some software on it.
Progressive Fridge Applications
In the olden days, like 1969, if you wanted to program the H316 in your kitchen, you had to learn FORTRAN IV and punch it into a teletype. The Model 33 teletype used ASCII so that several other machines could understand it, and some H316s were plugged into the early Arpanet, but the dream of true interoperability still had a way to go.
Even in the not-quite-as-olden days, if you wanted to write an app for your Android tablet, you had to learn a bunch of Android-specific jibber-jabber. But not now. These days, I can write C# and run it as a progressive web application, on a .NET runtime compiled for WebAssembly, running in a browser, on a tablet, on my fridge. Things have never been better!
“On the Internet, nobody knows you’re a dog,” says the New Yorker cartoon. With Blazor, Microsoft’s new web application framework, nobody knows you’re an old dog – they just see the new tricks. I’ve been programming in C# for twenty years. Now those skills can be transferred into building modern single-page web applications without learning Angular or React. Let’s go.
Visual Studio comes with a bunch of Blazor templates and so I’m going to start with a pre-built progressive web application. It’ll feel like an app but will run in any modern web browser on any device. Quite a step up from the 16 lamps and buttons on the console of the Honeywell.
What makes a web app progressive, apart from ditching the 1960s women-in-the-kitchen advertising?
Progressive web apps bridge the gap between web sites that run in a browser and native applications that can be run directly from the home screen. Unlike traditional web applications, they are able to run offline, even if what they do is limited. They also have access to phone sensors and use other mobile app technologies like push notifications.
Google has much more in its training materials.
A Closer Look
To see in more detail what make a progressive web application, I’ve created two projects. One is a standard Blazor Web Assembly project and the other is exactly the same but with the ‘Progressive Web Application’ option set when then project was created.
I’ve used KDiff to compare them side-by-side
The first difference is in the project files. The PWA app has details of the service worker
<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly"> <PropertyGroup> <TargetFramework>net5.0</TargetFramework> <ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="5.0.1" /> <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="5.0.1" PrivateAssets="all" /> <PackageReference Include="System.Net.Http.Json" Version="5.0.0" /> </ItemGroup> <ItemGroup> <ServiceWorker Include="wwwroot\service-worker.js" PublishedContent="wwwroot\service-worker.published.js" /> </ItemGroup> </Project>
Google has more detailed information on service workers in its Progressive Web Apps Training site.
<head> ... <link href="manifest.json" rel="manifest" /> <link rel="apple-touch-icon" sizes="512x512" href="icon-512.png" /> </head> <body> ... <script>navigator.serviceWorker.register('service-worker.js');</script> </body>
Those are the only code differences between a standard Blazor WebAssembly application and a progressive web application.
There are a few extra things to worry about when you build a progressive web application, mainly to do with how it behaves when it’s offline. There’s a Caveats for Offline PWAs section in the ASP.NET Core documentation.
In the next part, I’ll get rid of the demo weather app and replace it with a different weather app.