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.
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.
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:
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…
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.
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.
There are some challenges to overcome with developing a PWA. These include:
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.
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.