1. What is a web app?
A web app is a website that behaves like an app but inside your web browser… think software and no refreshing of pages.
A revolution in web development is happening right now.
The classic approach. Most websites today work by a visitor requesting a URL from a server, e.g. myholiday.com/deals/. If the server is running software, like WordPress, then it kicks in and does all it’s tasks to return an html page. Voila! The browser receives and loads the complete page from the server. The website visitor clicks on another link… another url is sent to the server and the same process happens again.
What’s the problem with this classic approach? It’s slow and there’s that refreshing thing. The whole page going blank and then loading again - yawn! We have to wait for the server to respond. It might be worse because of distance. For example, the website visitor might be in the UK, and requesting URLs from an American server. Or it might be worse because that server is overloaded with requests. It also requires a big stack of old technology that is expensive to scale.
The new approach… browsers have become powerful software in themselves. Google has demonstrated this power with Google Docs that mimics desktop software. So think of browsers as software that can run other software. Or to use more modern terminology… think of browsers as applications that can run other applications.
The classic approach gets the server to do all the processing… why not take the load off of the server and get each browser to do the thinking instead? Now we’re sharing the load among many computers instead of that one server.
Welcome the introduction of single page apps. Also known as SPAs. Single page apps are javascript applications that are running in the browser. They’re called single page apps because they only have one html page. To a website visitor they appear to have more than one page. How come? In the background, the application is loading all the different URLs requested. Let’s call these pages… views. When the application first loads, it comes with all its views. Well, mostly, but let’s discuss lazy loading another time…
Now all the thinking is in the browser. The server is having a long deserved break! But there is a job left to do for the server. It has a new role to play. Each view (or page) loaded in our SPA needs content. That content could be embedded in the app but that wouldn’t be very flexible. A better approach is for that content to come from the server and load dynamically. But here’s the big difference to the classic approach… it’s only a small data file (a JSON file usually). Remember the browser already has the views… they arrived when the application loaded. The server sends this file super-quick. And the app can remember this data and present it in different views.
Remember our URL above, myholiday.com/deals/. All the deals come down as one small data file. The app now has it. The website visitor might go to a view of a specific deal… No worries, we already have that data. The app loads that view and filters that data into it. The user might navigate back to the /deals/ view to look for another holiday deal. Or they might decide to filter the deals. No worries, the app is taking care of this within the browser. The server is having its well-deserved rest. And there’s no refreshing… that’s refreshing isn’t it?!
There’s one more bit to this revolution… wouldn’t it be great if this web app worked offline? And to be able to access it immediately, like a native app from a home screen? And for it to be full screen, i.e. with no browser menus at the top?
If a single page app can do this then it becomes a progressive web app. Enter centre stage - progressive web apps (PWAs). In fact, PWAs can offer more than this. The end goal is for them to have as much functionality as a native app. E.g. the ability to push notifications. But without the barrier of installing through iTunes or Google Play.
2. Progressive web apps - the core benefits...
Google has been a large player in advancing progressive web apps. Google has observed that people visit 100 plus websites per month (that’s a great reach). But spend most of their time in apps (in fact, on average only three apps - that’s poor reach). And that on average people install 0 apps per month. The latter point, makes it very hard to distribute your new app. Distribution of your app needs a lot of marketing effort to overcome this barrier.
But Google believe that any web experience should be:
- Fast - responding quickly to user interactions
- Integrated within their device. So that a user doesn’t have to access content through their web browser.
- Reliable - loading instantly and able to offer content. Even when network conditions are unreliable.
- Engaging - So that people want to come back to the app…
But to have this, historically, you would need a native app. Not any more. PWAs can do this.
You might visit a PWA via your browser. It looks like a website and behaves like an app. After a few visits your device will ask you if you’d like to save this web app to your home screen. If you say ‘yes’, then you’ll get an icon on your home screen. The next time you open it, it will load instantly. And full screen…
Explore Google’s documentation on it
Do you need a progressive web app? Well, if you want the benefits described above then ‘yes’ you do. Imagine the difference it would make to your e-commerce store? In fact, early adopters of PWAs have seen dramatic increases in conversion. Or imagine the different user-experience it would make for your learning portal.
3. Other benefits...
There are other practical benefits…
Easier to scale - Because you have moved all the processing to the user’s device. And now you’re only transferring small packages of data. Then you don’t need such a big backend infrastructure.
More secure - if you’re using a serverless computing method. I.e. your data is coming from a Cloud Platform, then your backend will maintained for you. You won’t have to worry about any pesky updates to deter hackers. Google’s cloud platform, firebase, is an example of this.
4. What are the challenges?
There are some challenges to overcome with developing a PWA. These include:
- Loading the app quickly on the first visit. When a website user visits the PWA for the first time then the application must load. This initial load is larger than a normal HTML page. A static site generator tool can help solve this by generating all the views in the app as html pages. Like a static html site. This means that the first view is very quick (it’s only an html page). Meanwhile in the background the app is loading.
- Working offline - the app needs to use a service worker to cache data.
- SEO - ironically, Google’s search bots struggle to index all the views of a PWA. Its search bots prefer plain ol’html pages. OK, solved, …use a static site generator to generate these html pages.
- Managing your content - Headless CMSs to the rescue. They provide a WordPress-like interface where you can create your content. The PWA connects to the headless CMS (via an API) to retrieve the content.
- Older tech... some older tech will not run PWAs. First and second generation iPads for example.
- iOS - PWAs will only install on iOS-12 and above. iOS12 came out in Sep 2018.
5. Managing your content in a PWA
Headless CMSs are on the rise. Another web revolution. They allow you to keep your content separate from your frontend / PWA.
Need a new frontend? No worries, replace the frontend without having to migrate your content.
If you’re considering investing in a PWA then you will be using a headless CMS. As explained in the previous section. They offer you a WordPress-like interface to add your content.
The other great thing about headless CMSs is that you can create content without a frontend. Once written, your developer can connect your frontend to it.
Here are some example headless CMSs for you to check out:
All the above would be suitable for managing the content for your PWA.
6. PWA examples
And finally, here are some links for you to check out. Do it from your mobile phone and see if the PWA asks to install itself.
