With each of the following, I encourage you to think about how you will solve these problems within the context of a web application. Hopefully, this will give you a better insight into what we try to achieve with PWAs, and the difficulties we face.
With Progressive Web Apps, we aim to provide an experience that is closer to a native app (one downloaded from the Apple App Store, Google Play Store, or another app store) than your typical web application. One of the advantages native apps have, of course, is that all relevant files are predownloaded and installed, while each time a user visits a web application, they may have to download all the assets again.
The solution? When the user first visits the page, download those assets and then save them for later (also known as caching). Then, when the user reopens the application, instead of downloading the files again over the internet (slow), we simply retrieve them from the user's device (fast).
However, this only works for when the user revisits the application. For the initial visit, we still have to download everything. This situation is particularly precarious, because when the user first visits Chatastrophe, they're not yet sold on its value, and so, are likely to leave (for good) if loading takes too long.
We need to ensure that our assets are as optimized as possible, and we download as little as possible on that first visit, so that the user stays around.
In short, fast loading for the first visit, near-instant loading for every subsequent visit.
There's no point in a chat application without notifications! Again, we're trying to emulate what has traditionally been a native app feature--push notifications directly to the user's device.
This problem is trickier than it might seem. Push notifications are only received when the app isn't open (that's the whole point, after all). So, if our web application isn't open and running, how can we possibly run the code to display a notification?
The answer is to use a third-party service that is engineered to send notifications to registered devices. So, rather than the device receiving the message alerting its user, the device sending the message alerts our notification service, which then notifies all relevant devices.
We also need a piece of code that is constantly "on"--always running and waiting to receive notifications from the third-party service and display them. This challenge only recently became solvable with web technology, and is one of the reasons PWAs are so exciting.
For now, don’t worry if this distinction doesn't "click" yet. We'll go into it in greater detail later. For now, the point is that push notifications will be an interesting challenge for our web application.
Even when our user isn't connected to the internet, they should be able to check past messages and navigate around our application.
The answer turns out to go hand-in-hand with the earlier discussion on instant loading. We simply need to cache everything our app needs to function, and then load that on demand; simply, of course, being the operative word.
For years, the big buzzword of web design has been responsive--websites that look just as good when scaled from desktop to mobile size.
PWAs are, in essence, responsive design on steroids, expanding design for mobile to every aspect of the app, from appearance to functionality.
However, at the end of the day, we need to ensure that our app looks great on every screen size. It also needs to look good under the restrictions we've already discussed. We can't rely too much on big background images or intense graphics. We need a simple and good-looking UI, engineered for both looks and performance.
The bottleneck of performance with any React application is downloading and running the JavaScript. Our entire application code will be contained in JavaScript files--and our app won't work until those are executed. That means our users may be stuck staring at a white screen (with zero functionality) until that JavaScript is ready to go.
Progressive enhancement is a technique that aims to fix that problem. In essence, it means that a user's experience should get progressively better as the application downloads, depending on the user's browser. In other words, the application experience improves as time goes on (and more of the application downloads), and as a user's software improves.
A user with the most modern browser, the fastest internet connection, and the application fully downloaded will have the best experience, but a user with an outdated browser, a shaky connection, and who just landed on the page will also have a quality experience.
This means our React.js application needs to have some functionality without any JavaScript. This is a fun challenge.
Think of our UX as a series of layers, from good to fantastic, that we build up as time goes on.