STRV Team3 min

3 Limitations of Progressive Web Apps

EngineeringFrontendAug 1, 2018

EngineeringFrontend

/

Aug 1, 2018


Share this article

Last week, we dived into the world of Progressive Web Apps. Lightweight and feature-heavy, PWAs have the look of native apps, but work offline and have the potential to grow your user base exponentially.

They are considered “progressive,” because anyone can use them regardless of their browser choice. They are responsive. They don’t need to be downloaded from an app store. And they are free to install.

We can already see how PWAs have rapidly changed the landscape of web development. Over the course of the last two years, more and more companies have jumped on the progressive web bandwagon.

But despite all the hype, PWAs are not without their limitations. The technology is still evolving. But we strongly feel that the benefits far outweigh the negatives.

Danny Kijkov, our frontend platform lead and in-house PWA expert, outlines a few challenges facing PWAs and lays out his predictions for the future:

1) ADDING PROGRESSIVE WEB FEATURES TO WEB APP REQUIRES EXTRA TIME

This is not so much of a limitation, as much as an effect. Since these are extra features, you will need to budget more time for development. Not all of these features are standardized yet. This is not even a huge problem, but sometimes it might present a small issue, especially if you are trying to build an MVP in a really short amount of time. It’s the same for iOS and Android — the more features you want for your app, the more time you’ll need for development. But on both mobile platforms these features are used quite often, and it’s much easier to implement them, and it’s much easier to debug them.

A good example of a progressive web feature is a push notification, which is a common feature on mobile phones. But on the web, push notifications are not that common and not all devs are aware of how to implement them properly. It will also take some time before users start thinking that these are natural for web. I feel like this will become standard practice pretty soon, because push notifications are a good way of getting in touch with users.

2) WEB STILL DOESN’T HAVE ACCESS TO FULL HARDWARE OF DEVICE, UNLIKE NATIVE APPS

With a mobile phone, you can usually access the full potential of the hardware, which is not always possible on a browser. But the fault of this lies mainly with JavaScript itself, rather than the hardware. JavaScript is a single-threaded process, which means that whenever you are doing one operation, another one needs to be postponed. In those instances, we can actually use some work-arounds, which allow you to run native code written in C or other languages. This will provide you will the power of the hardware itself. To be honest, browsers are evolving really fast. So is JavaScript.

3) SUPPORT IS GOOD IN MODERN WEB BROWSERS BUT NOT IN LEGACY ONES

Legacy browsers are still kind of supported, and they work. But they are old and won’t be evolving anymore. A lot of companies still have legacy software, and upgrading isn’t just about buying new software, but it’s also about buying new hardware. For larger corporations, upgrading could cost a huge amount of money, and for many older users, they see no reason to upgrade.

It’s important to know your target audience. If only 1 percent of your users are using older browsers, does it make sense to develop a program just for them? It depends. Landing pages, should be accessible to everyone, regardless of their browser choice. Legacy browsers won’t have all the nice progress web features like offline capabilities and push notifications, but that probably won’t matter to older users who are used to their browsers operating in a certain way. However, with legacy browsers on their way out, I would say that in a couple of years this won’t be an issue anymore. The market will force people to upgrade their hardware.

We're hiring

Share this article