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.
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 plans 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.
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  — 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  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.
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.
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.
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.
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.
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.
Written by Bob Frankston, Independent Internet Professional
Follow CircleID on Twitter
Read more here:: feeds.circleid.com/cid_sections/blogs?format=xmlPosted on: July 13, 2018