Progressive Web Applications (PWAs) are an evolution of Web APIs that allow a whole new set of features to be built within client side applications -- from push notifications to offline access to immensely increased performance. Here at Condé Nast, we see a lot of advantages to starting to use these features in our brand websites.

When digging into these features, there’s quite a lot of information to get into your head. Like any other new technology, there are APIs to learn, SDKs to install, and documentation to read through. All in all, these new features aren’t orders of magnitude more complicated than anything else you’d use on a daily basis. There’s always something more to learn just like Node, React, Ember and plain ol’ JavaScript. Nothing will be incredibly difficult, but everything will be completely new.

In addition to the specifics of learning how to build Progressive Web Applications, there’s also the organizational, operational and strategic questions that we have to answer in order to actually get something shipped. For example, how can we balance the goals of our technology platform with building new features for our brands and adding in exciting PWA features? Also, once we do have a set of shared goals to prioritize against, how can we do this in a way that can transform 22 different brand sites on our new platform into PWAs as quickly as possible?

The Backdrop: Copilot

We've been building towards a pretty audacious goal for years now. We have been moving all of our brands to one single CMS and sunsetting sundry old, legacy systems. Replatforming everything has been attempted before and each time has failed until now . The loftiest goals rarely get accomplished, but we are big believers in shooting for the stars and, in the worst case, landing on the moon.

We have 22 editorial powerhouses, each of them finally moving in the same technical direction. After a four long years, Condé Nast has every single one of its brands on an internal CMS, custom built for Condé editorial, called Copilot.

While many of these years were spent actually building the tool, there were also years spent in migrations. It was not at all straightforward to come up with a system to get content into our ivory tower data structure. From each of the five different legacy CMSs, we had to build custom importers that took into account the nuance and depravity of each raggedy data model.

Finally though, through the blood sweat and tears of many, we are on a single, uniform system. Uniformity of platform has advantages galore. We no longer have to individually build features for brands in the CMSes of choice, but rather we can build once and roll out to each brand that wanted it. We don’t have to deal with snowflakey-ness and institutional knowledge of old rotted-over-time platforms. We can rollout updates like HTTPS across the network with a very clear checklist of learnings from previous brands that are completely applicable to every other system.

Undertaking this kind of long game does leave us, however with one preordained outcome: We cannot rebuild again . We can’t build this from scratch and this particular point is where the currently popular path to Progressive Web Applications -- that of reimagining and rebuilding your app as a single-page application -- starts to get in the way.

In our experience, the difficulty we found was not in the technologies themselves, but rather the tools and documentation around them. As to be expected with very new technologies, there aren’t many abstractions yet built around the low level primitives given to us. It’s like I was given a shovel and told to dig a gigantic hole and all I really want is an excavator.

Put another way, I cannot help but feel like we’ve been given the goal of “make the entire web” in one hand, and an open TCP socket in the other and told “GO!” Better and higher-level abstractions are needed for these powerful, foundational technologies to be of intuitive use in the average application. We are at the beginning of the road instead of a decade in, when it will be much easier.

Is a Progressive Web App necessarily a Single Page App?

There’s a lot of misinformation on the internet as to how to build a PWA and how “appy” and SPA-y one must be. Take a look at this for example:

This simply isn’t true. Disappointingly, It is what most of the documentation, blog posts and public discourse seem to imply. Because of the nascent and undeveloped state of the underlying technologies, not everyone has the opportunity to build a true SPA - but that doesn't mean they can't take advantages of PWA technologies.

Here at Condé Nast, we are all very excited about the fun browser features we now have access to. While we've lately been reinventing ourselves as a true technology company in our own right, at our heart we are still very much a publisher. Bringing a user back to our website to read relevant and useful content is the revenue generating prime directive for us. We are not “appy” and we are happily server side rendered without any direct intention of switching to an Single Page App (SPA) across the board.

As we’re starting to integrate these fancy new features, I like to think of our user-facing applications not as PWAs, but as AWAs: Alien Web Apps. Our AWAs are going to be using PWA features, such as offline access, installable to home screen and the increased performance that comes from Service Worker.

What we can definitely do

Now that we’re comfortable with this realization, there are some clear next steps for us:

Static Asset Caching with Service Worker - storing all static assets in a JS accessible client side cache

- storing all static assets in a JS accessible client side cache amp-install-serviceworker prefetch - starting to install a service worker when someone visits a google carousel page, even before the user ends up on your domain

- starting to install a service worker when someone visits a google carousel page, even before the user ends up on your domain Offline 404 Page - being able to seamlessly show someone a real page when offline to show that the content isn’t available

- being able to seamlessly show someone a real page when offline to show that the content isn’t available Add to Home Screen - giving the user a way to install the web app as if it were a native application without the chrome of a browser around it

- giving the user a way to install the web app as if it were a native application without the chrome of a browser around it Push Notifications - being able to reengage with the user and show them relevant and timely information and in our case, articles and trending topics

All of these things are easily googleable and doable, independently and iteratively, without rebuilding our sites from scratch. In future blog posts, we'll let you know how we're progressing with Progressive Web Apps.

Send feedback and comments to the author: @johnkpaul . For more about Condé Nast Technology follow @CondeNastTech .

If you'd like to see the talk that inspired this blog post take a look here: