One of your friends calls you on the phone, bursting with excitement about his latest start-up idea (you know the one). You patiently listen to his description, but respectfully decline to be a part of it. He's disappointed, but understands and promises to keep you updated on the project details. You murmur your assent.

A few months later, he meets you at your work and announces that he has found a group of serious investors, and he needs you to help him build the software he promised them. You again decline, but when discussing compensation, he mentions a number that you can't refuse. A week later, you're on a plane to San Francisco.

In front of the investors (who are, to your surprise, a rapt audience), your friend guides you through the basics of the application. In between the buzzwords ("mass interconnection" and "global community"), you gather just enough to summarize the application in a sentence.

"So, it's a chat room… for everyone in the world… all at once…"

Your friend smiles. "Yes."

You're bewildered by the image of a million strangers all talking at once on the same application, in the same room, but the investors break into applause. As you head for the door, your friend again announces how they'd like to compensate you… citing an even higher number than before. You sit down.

"The problem," your friend explains, "is that this chat room has to be for everyone."

"Global community," you say with a knowing nod.

"Exactly. Everyone. Even if they have terrible internet in some hut in the desert. They should be included."

"Mass interconnection," you add.

"Exactly! So it needs to be fast. And lightweight. And beautiful. And dynamic."

"So everyone will be talking at once? Won’t that be-"

"A worldwide collective, yes."

"The other problem," your friend declares, "is that our users will mostly be on their phones. On the go."

"So you want to do an iOS and Android app?"

Your friend waves his hand. "No, no. No one downloads apps anymore. Especially in developing countries; that takes too much bandwidth. Remember, worldwide collective."

"So a web app."

"Yes. A web collective."

Despite your best instincts, the project intrigues you. How do you craft a web application to be as fast as possible? How do you make it work under all network conditions? How do you make a chat application with all the conveniences of a native app, but for the web?

You sigh and shake his hand. "Let's get to work."

Welcome to the world of Progressive Web Applications.

In the preceding scenario, the problems your friend was describing are exactly the problems PWAs (Progressive Web Applications) are crafted to solve.

The first problem is that many users will be visiting your web page under poor network conditions. They may be a Silicon Valley technocrat on their iPhone in a coffee shop with bad WiFi, or they may be a Bangladeshi villager in a remote location. Either way, they will not stick around if your site isn't optimized for them, for everyone.

How fast your application loads--its performance--thus becomes an accessibility concern. PWAs solve this by loading quickly the first time, and even more quickly every time after that. We'll talk more about how they do so as the book progresses.

Second, the installation process for mobile apps is an obstacle for users. It means that your users need to be extra committed to engaging with your application--enough to give up storage space and time, and expose themselves to the possibility of malicious and intrusive code, and that's before they even get the chance to try the app!

What if we can provide the native app experience without the initial investment? PWAs are an attempt to bridge that gap. Again, we'll talk in subsequent chapters about how they do so, and how successful they actually are. However, these are both worthy challenges, and solving both will be a huge user experience win for our application.

Many static web pages do a fantastic job of performance. However, when all you need to do is render some HTML, CSS, and a smattering of JavaScript, it's less of a struggle to work well under all network conditions.

When we start talking about web applications--large, complex, JavaScript-based workhorses--performance becomes a significant challenge. Our frontend will have a lot of code. Our user needs to download all that code if they want to use our app to its fullest potential. How do we ensure that they're not staring at a blank loading screen for ten seconds, as 500 KB of JavaScript initializes?

Therefore, most of our performance enhancements will center around managing the JavaScript problem. This is especially true with React.

React is quickly becoming the go-to solution for frontend web applications. Why? This is because it's fast, elegant, and makes managing large applications easy.

In other words, it makes complexity simple. There's no reason a PWA has to use React, though. PWAs can be any web app or site.

React does have one major benefit--its component pattern, where UIs are split into distinct pieces. As we'll see, the component pattern lets us break our interface into small chunks of code to alleviate the preceding JavaScript downloading issue. However, other than that, any frontend framework will work just as well for a PWA.

The advantage of React is that it is a beautiful and fun way to build frontend applications. It's also an in-demand skill. If you pair knowledge of React with experience with PWAs, you'll be about as future-ready as one can be in the fast-moving web development world.

You tell your friend about your learnings on PWAs and React, but before you finish, he waves his hand and interrupts.

"Yeah, yeah. Hey, what do you think the name should be?"

Once again, you're struck with the unnerving feeling that all of this was a mistake, that you never should have jumped on board this questionable venture, this potential catastrophe.

"Chatastrophe," you blurt out.

Your friend smiles and claps you on the back. "Brilliant. Okay, get Reacting or whatever!"