The browser is now a full fledged platform for apps. The major benefits of using the browser as a platform includes ease of universal deployment and avoiding concepts such as having to install software. It’s also a very flexible and powerful environment.

Increasingly consumer electronics “devices” are software applications. In the April 2014 issue of CE Magazine, I wrote about HTML5 as a programming environment. Today’s PWAs (Progressive Web Apps) go further. They take advantage of HTML5 and also capabilities of the JavaScript environment.

This is happening with PWAs or Progressive Web App. The term progressive refers to the approach of taking advantage of capabilities that are available in the application environment rather than having rigid requirements. This includes running on a range of devices instead of focusing on narrow categories like “mobile first”. Moving across a disparate array of environments should include taking advantage of opportunities that are available such as a larger screen and adapting to the limits of a small screen. Perhaps in the future we’ll treat the screen as an optional interaction surface given the availability of voice, touch and other techniques.

Instead of lumping a set of disparate concepts under “mobile” we can think of them separately:

• The screen is an interaction surface. It may be a small wall-mounted device or a large screen on a pad we carry around.
• Mobility is not simply a characteristic of a device but should be thought of as the mobility of a person who can interact on any available surface rather than being limited to a device they are carrying. Applications too can be mobile and available where needed rather than on a particular device.
• We can introduce place as its own attribute. Touch a surface in the living room would turn on the light in that room. When we place a phone call we may be trying to reach a person. Or perhaps we are trying to reach anyone who happens to be home at the time.
• There are many interaction modes with touch being one. Cameras can enable rich gesturing or even the use of facial expressions. Voice is another. And so many more.

We’ve come a long way from the original iPhone with its then rigid specifications. PWAs now give us a chance to explore new possibilities.

While a PWA can be treated like a standard application on a device, the ability to “just run” from a URL makes it easy to use the application on any device with a browser. This allows one to travel light.

Today airlines are removing screens from the planes and expecting travelers to carry their own devices and some airlines handout tablets. Perhaps it will make sense to bring back the larger screens as connected devices with browsers.

Apps

Unlike desktop applications which have had full access to the capabilities of the hardware (even more so in the earlier days of personal computers), a PWA starts out with essentially no access beyond the content from its original site. This reflects the cautious safety-first model for the web.

These capabilities are becoming increasingly more available to browser applications. They can now get the users’ location (if permission is granted) and support Bluetooth devices (again, with permission). Soon they will be able to process payments. Increasingly we can think of PWAs as true applications and not just cached web pages.

Google and others are using PWAs as an opportunity to enforce hypertext transport protocol secure (https) encryption. Service workers require https.

Central to the structure of a PWA is the Service Worker [1]—typically a file in the top level (or other) directory of the application. A common name is “/sw.js”. It is distinct from the rest of the application and instead of a top level “window” object, it has a “self” object. It’s a kind of web worker [2] which communicated with the rest of the application by sending messages rather than directly referencing shared objects.

The service worker has limited access to files in or below its file directory. This is part of a larger approach of treating the URL path as a file system path, but sites can get creative in interpreting the string. This cautious approach also limits access to platform capabilities such as the native file system.

Notification is a key new capability which relies on service worker being available. Even when the browser is closed the JavaScript engine is still running. The notification mechanism allows data to be updated in the background to allow you to quickly see the current state of orders or reservations even if they aren’t connected at the moment.

The app can also use the platform notification mechanism to alert the user of changes. To prevent denial of service attacks the notifications are routed through the browser-supplier servers.

There is also a local data store, IndexedDB which is an advancement over the browser local storage. In addition to having larger capacity and transactions, IndexedDB is asynchronous. Asynchronicity is a key feature of HTML5 programming and the promise mechanism has improved the readability of asynchronous programs. This style can make apps very responsive while still having the simplicity of single threading.

I expect that more platform capabilities such as calendar providers will become available to PWAs. These concepts are being pioneered on mobile devices but also make sense on desktop devices allowing more integration with work flows.

Looking ahead

Because PWAs are constrained by the browser environment it’s hard to directly share among PWAs from different sources or across browsers. I would like to have the ability to share resources among browser apps and among local machines rather than relying on distant servers.

In theory some capabilities can be provided by third parties with local https servers and, perhaps, we’ll see offerings such as document stores. There is still a need for a more traditional file system which just stores collections of bytes without knowing what they mean. This is similar to access to a file system on today’s SD cards allowing multiple programs to store images files so that multiple camera applications and photo processing programs can share access to the same files and create new formats. How should access to such objects be managed? How do I selectively share access and limit others’ ability to view a picture even when they have physical access to the device?

Today we do have browser machines such as the Chromebooks, but their capabilities are limited by the available apps. The same hardware can be used as a Windows Netbook which is far more capable. Over time it may make more sense to have such browser-based machines without worrying about the underlying operating systems.

PWA Engines

PWAs offer the ability to write once and run everywhere. Smart TVs are an example of a market that is currently fragmented as various venders build their own smart TVs along with boxes from Amazon, Roku, Apple and others.

Having a browser box could provide a standard platform which brings the benefits of the huge investment in web technology to this market. Concepts like URLs would be used to bookmark content (formerly known as TV shows) so they can be shared. Capabilities such as windowing (Picture in Picture) can be implemented locally and flexibly.

Device like home lighting and climate controllers can be implemented as applications using generic hardware and become available anywhere in the house. Voice services like Alexa and Google Home can take advantage of place and monitor conditions such as temperature. (Alas, yes, they can also listen in ... proceed cautiously).

PWA and IoT

The cost of a browser-capable computer keeps dropping. But for many applications there is need for running a browser engine on the device itself.

Such devices still benefit from being able to expertise developed for browser-based applications. NodeJS supports running JavaScript on a wide variety of machines. Onion.IO sells a complete system including WiFi for $7.50 retail (as of November 2017).

We need to think about an Internet of Things built of fully capable devices. There will be sensors and other devices that may be resource constrained but those devices can be considered as peripherals to those fully capable devices. Similarly, the programming environment of JavaScript is far more resilient than a low-level language such as C.

Rather than mobile first, we can take a local-first approach to development. Thus, a door “bell” (it’s no longer a bell, but a two-way communicating device) might take advantage of a face recognition service but can still function if the recognition services is not available.

A PWA application should communicate directly with the door device rather than relying on a distant server merely to authorize the door to open.

The Internet protocols are not quite there. The DNS (Domain Name System) depends on distant services and the IP address is issued by a “provider”. We need to shift to thinking of the Internet in terms of peer connectivity rather than as something that one accesses.

About JavaScript

JavaScript started at as a low performance scripting language designed in one week. But it built upon a long heritage of important design principles. The focus was on safety and resilience. Objects are defined dynamically rather than having static class definitions.

The surprise is that today JavaScript has become a high-performance programming environment thanks to clever ideas like dynamic compilation. Tools like TypeScript assist programmers by allowing them to provide hints to the IDE. In addition, there are whole set of tools to facilitate sharing of packages. An event-driven single-threading approach removes much of the complexity of high performance applications.

With platforms like NodeJS JavaScript isn’t just for the web. Progressive Web Apps are just one class of applications written using the language and associated tools.

A PWA World?

Not quite. While I am excited about PWAs and see many venues, such as TV-V2 where they are vital, there is still need for a variety of approaches to programming and software development. There will continue to be a need to program applications ahead of what is available to the PWA environment and the need for developers to create their own extensions.

Google, Microsoft, and others are embracing PWAs. For Microsoft there is a recognition that they can make a lot of money providing service using their Azure services (and, for Amazon, AWS).

For me PWAs are exciting because they bring back some of the excitement of writing and sharing applications without all the complexities of applications meant for wide market sales.

Today’s PWAs are built on the current web which is optimized for content distribution and commerce. As we explore new use cases an application for this engine I expect to see much innovation including the development of more peer technologies rather than a focus on delivering services. That said, the current technologies and protocols are already a strong basis for delivering capabilities.

Consumer electronics devices will increasingly use PWAs either internally or as an interface. More than that, PWAs empower prosumers to wield software like they did soldering irons in the past.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
[2] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API