PWA - Applications in the Browser

Before I start I am wondering, how much of you are Graphical User Interface Coders – regardless if you are using Web as a visualization, some hybrid, cross-platform or native tool kits?

Well, I know your feelings bros.

The GUI Frameworks, Techniques and Libraries has never stopped to evolve. For the Web – from simple pages with every time – custom design/code, to jQuery Based Frameworks and Components – Responsive Frameworks, Material Frameworks, Flat Designs, Fixed and Fluid Layouts, Component Based Frameworks etc.
On the Android Platform the recommended UI concepts changed at least 3 or 4 times.

I am wondering, Are you even experimenting with Voice Technologies or some other non-traditional interaction between the user and the software and the hardware, that given enough time to evolve, to educate the user, to improve the software and hardware could potentially make the traditional GUI obsolete? Well, will see.

Until then we will still have work to be able to provide for our families, without a need to drastically update our mindsets and skills.

Before I get into what is a Progressive Web Application, I’ll introduce a little bit of history.

Internet has evolved a lot the last two decades. 20-25 years ago the Web was looking very differently. Most of the Internet Sites/Web Pages were working synchronously – needing full page reload for every small change that needed back-end interaction.

• First workaround for full page reload was using the iframe tag – placing different URL to the “src” attribute;
• Around that time the idea behind Asynchronous HTTP Request was first planted by Microsoft via the ActiveX object. The ActiveX Object failed and is discontinued currently as a technology but the idea of the partial page reloading (AJAX) was implemented by all browsers and is now an accepted standard.

There were very few option for storing something on the client, without persisting it on the server was – the HTTP Cookie. This persistence option had/has its side effects, like making requests slower – as it is send with each request and the Internet speed was in the infancy and still evolving (still is but to much higher levels).
Another way was with request parameters, but – this was visible to the user and not so user friendly.

Around 10 years ago HTML5 made its first release. HTML5 is a never ending evolution of the Web Standards, APIs and possibilities that made possible transforming web sites feature rich platform. A decisive point was when Apple ditched flash for HTML5 on the “I” devices, forcing the whole industry to follow up faster and more radically – Facebook, Twitter, YouTube, LinkedIn and many more didn’t need a lot of time to move to it and started giving back their own contributions in terms of tools, frameworks, recommendations, source code and implementations of improved APIs for the Web. Google – Created Chromium, bought WebM video format/codecs and open sourced them, for chrome – the used V8 JavaScript Engine that migrated to the server, Twitter – Bootstrap, Apple – WebKit that was the initial core of Chromium etc.

Getting back to today – the most universal platform accessible almost everywhere is the Web. On some small special type of devices it may be not with a browser, but with some custom Socket or HTTP Protocol, but they are mostly specific and custom. The bigger majority of devices are having a browser – Smart Watches, Feature Phones, Smart Phones, Tablets, Laptops and Desktops with whatever OS. Google is even investing in making their Browser as a OS shell – making a Internet First laptops. The Internet is accessed all over the world even in third world countries where the power supply and the Internet connection speed is not so good. Partially because of this, there are some initiatives to package the popular western services in lite version that use less storage and data.

From developer point of view – we have HTML5 – that is more than just several tags that integrate audio and video or bring some more semantics to the page structure. HTML5 includes in itself the evolution of the JavaScript (ECMAScript) and many APIs accessible through special classes accepted by the Web Community that bring a lot of the features, previously accessible only through native API and applications – to the Browser.

Progressive Web Application or PWA said shortly that is HTML5 (the APIs in the normal scope of the web page) + Service Worker features (APIs – accessible in code running outside of the normal web page workflow).

You will probably find on the Web that the ServiceWorker features are thing that bring the “Progressive”, but I thing it will not be so feature rich without the HTML5 APIs. The APIs bring the sense for “Application” in the abbreviation.

PWA is about security – that is why most of the more advanced features work only over HTTPS.

PWA is about Speed. There are million ways to tune up the speed, or even the visual sense of speed. I’ll point out some of them.

PWA is about Application Reliability – it will work offline and will fail gracefully when happens – giving meaningful messages.

PWA is about Engagement. What brings back are very often more psychical factors, but whatever technical ways there are to get the user back – are somehow included – Notifications, work offline, speed, and many more.

Together – they are a package of APIs, Tools plus the Best Practices that take into account the currently accepted Web Standards and a little bit beyond plus taking into account how the HTTP works – to try to make the Best User Experience as possible in several terms like – App Size, Speed, Usability, Responsiveness, Software and User Interface Quality and so on.

The idea of PWA is to try to satisfy the user and bring the Best User Experience as a web page could – work even offline, engage the user into using the application, and, in most cases, it is above concrete proprietary technologies, above concrete software packages, libraries, frameworks, languages and browsers (when they have implemented the standards).

It doesn’t matter if you use plain JavaScript or Dart, TypeScript, or any XtoJS technology, is your GUI front-end code generated by some tool or some framework or what is your backend – PHP, Java, .Net, Go, is the back-end and front-end strictly separated in your code while programming etc, as long as the whole thing, the result in the end is following the current best practices.

The are trade-offs as not everything is suited for web and there are many small things to tune up to work-around the limitations of the Web in terms of speed, performance, user experience, native features created every year. But it gives you true possibility to have one code base (or at least one type of) for all users and potentially all types of devices – instead of – code bases – for the Browser, Android, iOS, Windows, Desktop, etc. The cost of having all variations of native apps will surely be a lot more than just the Web, designed to adapt to the different screen sizes and devices.

One key thing for speed is – Make every single thing non-blocking (asynchronous) as possible as long as it doesn’t hurt the User Experience. There are scripts on the Internet about loading JavaScript and CSS after the page is loaded so, for good User Experience – the sense that the page is loading – the very basic styles, images and scripts could be included at the very beginning and everything else could be loaded after that. This drives functionality modularization, besides the start up speed.

Minimize Images size – use SVG, (CSS features – repeat for stripes, colors, transformations, animations), joined images “grabbed” with CSS background, use thumbnail versions (images with exact size as it is displayed and request the larger one when necessary), use better compression (Progressive JPEG), use Server HTTP feature to download multiple images in one connection (HTTP Pipe-lining)

Another thing that brings speed is minimizing the number of objects created by JavaScript that increase the memory need. One approach for doing this on Android is ListView/RecycleView Pattern. It is – having just enough widgets in the memory that may be displayed inside the view. I read that the concept is implemented in Angular 7 as Virtual Scroll. There are probably other implementations of this pattern on other places.

Another visual thing that Google learned from past experience (or maybe not) is delegating the UI creation to the layer that will do it best. It is separation of the UI from the logic. The idea is implemented in several Google children – Google Web Toolkit, Angular, Android, probably many others (not sure why not – at least not yet – in Flutter).

Load what may be appropriate according to the needs of the application – with high priority offline:
From the File System / App Cache with Web Worker.
With no request or with cache HTTP header – making very minimal request – about any need for update.
No cache items – for example an end point for check for update.

Offline functionality – Do you know well the target client, the needs of the users etc, to know what approach to use. There are cases (business applications) where offline functionality is not necessary and even bad – like business-to-business software. But in most cases it is good. The percent of mobile browsing is around 50%. From the Desktop Devices there are also a lot of laptops that very realistically are used in non on top of a desk Environments with high speed connection to the Internet.

So in practical technical terms there are several APIs available:

• navigator.online so the developer could choose what to do in concrete places.
• listener of Internet connectivity
• Service Worker could do something in case there is no Internet. This is – using the Interceptor/Filter/Controller Pattern to separate the choice of operations when the user is offline/online in one place instead of in every place where a back-end call is executed.

Storage Information Options

• Cookies – Shared between client and server Key-Value Storage
• File (File System) (Still W3C draft)
• Local/Session Storage – Offline Key-Value Storage
• Web SQL(discontinued by W3C)
• IndexedDB – Transaction Based, Indexed, Sql-like NoSQL – accessible from Service Worker Even Offline. The values of the indexes could be strings, objects, blobs etc.

Drawing APIs

• Canvas for 2D – draw simple 2D stuff – lines, squares, circles, etc.
• WebGL for 2D and 3D – is for more complex shapes that use the provided by the Browser implementation of OpenGL that could give potential boost to speed using hardware acceleration and so on.

Push Notifications – Web Push Notifications take the experience from native mobile push notifications and bring them to the Browser. The workflow is identical – get User permission to receive notifications -> save the registration – when something new arises the server sends a trimmed info though a message gateway with the registration token and the message gateway transports it to the device – using only the browser as the application receiver.

Background Fetch or Background Sync (still a W3C Draft) – It registers some work to be executed outside of the normal page/window scope. It may be useful for downloading a movie, post-pone sending some information when the user is online and so on. It follows the same restrictions introduced in the Mobile Platforms – iOS and Android – to not run forever on the background and drain battery, but wake up when some events occur.

Media Devices APIs:

• Access to Camera – used for Image/Photo manipulation, or even Bar Code reading (quaggaJS) etc.
• Access to Microphone – used for Example for in-browser speech recognition

Access to GPS Location – A user may give access to a web application the values of their GPS Sensor. Useful when running from a Mobile Device.

Native Performance with Web Assembly – Web Assembly is stripped down stack based Virtual Machine that translates the provided byte-code (WASM) to more closer to the hardware machine code. Useful for games, heavy mathematical computations and so on. Application Developers (like me), using some higher level programming languages, abstracting all hardware and software complexity – sometimes forget that in the end all is stripped down to mathematical operations.

Web Assembly is just a VM designed to be not too complex from the start so it may be more easily secured and with some basic ideas to be adapted for the Internet Age. It is not a new language, but a compilation/trans-compilation target already targeted from high level languages like C++, C#, Go, Java and other frameworks to get the boost from the native like performance on the client, instead of the interpreted JavaScript.

Currently It is more for toolkit, frameworks developers and some very specific developers of some very specific apps that could get the boost from using it directly (with the hands dirty). As I heard from the
https://www.nerds2nerds.com podcast – Web Assembly is also being ported for outside of the browser and that may boost the back-end use of JavaScript (or some other usages).

When opened normally – the navigation bar of the browser visible and accessible to the user at his wish. One PWA feature is to create a Desktop Shortcut to your site and it will launch your site in a Browser Session, but it will remove the address bar making it feel more like an Application.

One thing to point out is – it is good idea to introduce PWA features to sites that are designed to have the look and feel of an app. Otherwise they will look like a chimpanzee with a lipstick.

Permissions – Something available in Android 6.0 and beyond, and iOS (not sure from when). Every access to some more intimate sensor or functionality requires Permission from the User. Use of more Storage/Memory, Camera, Microphone, Push Notifications, GPS Location etc. This is how it should be.

On the Web requesting permissions has the same User Experience – Best Practices as on the Native Applications – ask for them when they are needed, not on first page load! Today there are a ton of stuff that is poked to the eyes of the users – Cookie Privacy Policies, Ads, Login, “Pay Now” features. The permissions, push notification and add to home screen are just few more things to the already overwhelmed users. There should be some romance, some dating before you propose something serious.

So, if someone tells you he programs Business Applications in HTML(5)/PWA, don’t laugh at him, because you probably have not updated your information about what is available to developers in the Browser. It is not just the simple markup. And yes – you’ll probably not hack NASA and not everything is perfect, not everything is supported everywhere, sand-boxing and making software secure is not an easy and is even endless task. But time is not going backwards and we will probably not need to support Internet Explorer 6 for example.

It’s for example – Apple lagging to implement all the PWA features from one part – they are not all – approved W3C Standard and from other – they will hurt their income (the App Store), while the Openness of the Web allows Google that monetizes from content scrapping will have a little bit less technological walls to access the content and the applications.

You could check what is available on https://caniuse.com/ in general, but as a defensive developer you could see if some feature is provided by your current browser with ifs like:
if (‘serviceWorker’ in navigator) {
…
if (navigator.geolocation) {
…
and do some workaround or add some message accordingly.

I am not able currently to show you a fully working PWA as my personal projects using it are still a little bit in Work In Progress – not ready for the wide public. I have implemented some of the best practices and used some of the Application like features in the browser.

• In my blog : https://tomavelev.com/blog/ I have implemented the asynchronous loading of CSS and JavaScript.
• I’ve experimented with 2D Drawing library to visualize the relationships between different stuff related to food and health http://kakvoiadesh.com/app/graph/index.jsp?bodyPart=4&l=en_US
• I’ve used Google Voice Text Recognition for entering the ingredients of food items https://tomavelev.com/app/index.jsp?addbarcode= . The functionality is currently not working from the app’s domain but will be after I finish the PWA transformation.

So basically that’s why the browser use and will use even more memory, storage and resources and will continue in that direction. I hope the Browser Session for sites made to Applications to become separate in the future so it may be easier in the future to clean some data for some specific site, instead of having them all the resources in one place.

Video of my presentation is available on YouTube: https://www.youtube.com/watch?v=N9Ti2Taa8iQ