Frontline Web developers help to keep browser vendors honest and serving the greater good.
Excitement has abounded for the concept of Progressive Web Apps built with Service Workers and App Shell Architecture. The mobile Web, people say, has finally caught up with native apps.
Several items are wrong with this ethos. And now that Progressive Web Apps are firmly in the programming lexicon, some of the world’s most astute Web developers are starting to pick apart the notion of what a Progressive Web App is and how its architecture and best practices can and should be implemented.
For some context, Google is in the midst of blurring the distinction between apps and the Web on smartphones. And Google is doing this from both ends: Progressive Web Apps try to make websites more app-like while Android Instant Apps attempt to add URLs to modularized bits of native apps so they load without having to be downloaded.
The primary bone of contention with Progressive Web Apps is that the notion of progressively turning websites into apps continues the damaging bifurcation of the Web between mobile and desktop browser. Instead of eclipsing the era of WAP mobile websites (m.site.com style of webpages), Progressive Web Apps and AMP are just evolving the mobile Web into a distinct realm—with its own practices and principles—from the regular Web.
The Issues With Progressive Web Apps
Web developer Jeremy Keith, writing on his website Adactio, outlines the general issues with the current crop of Progressive Web Apps:
Alas many of the current examples of so-called Progressive Web Apps are anything but. Flipkart and The Washington Post have made Progressive Web Apps that are getting lots of good press from Google, but are mobile-only.
Links from Adactio.
The end result may feel very “app-like” if you’re using an approved browser, but throwing the users of other web browsers under the bus is the very antithesis of what makes the web great. What does it profit a website to gain app-like features if it loses its soul?
I’m getting very concerned that the success criterion for Progressive Web Apps is changing from “best practices on the web” to “feels like native.” That certainly seems to be how many of the current crop of Progressive Web Apps are approaching the architecture of their sites. I think that’s why the app-shell model is the one that so many people are settling on.
Because of all of these faults, Keith called PWAs “Regressive Web Apps” … a fairly damaging moniker for any movement that calls itself progressive.
The Issue With URLs in Progressive Web Apps
URLs are the lifeblood of the Web. Google built its business on the notion of crawling URLs and the information located inside of them and then surfacing that information through its search engine. The creation, maintenance, optimization, sharing and monetization of URLs have been the dominant Web paradigm for 25 years.
And Progressive Web Apps do not show URLs by definition.
Developer Stuart Langridge defines the issue on his blog in response to Keith’s original post. Read Langridge’s background in the blog for the full context, but it goes something like this:
- Progressive Web Apps are defined by a set of criteria from Google Web developer Alex Russell. The criteria includes responsiveness, security, sharability, connectivity independence, the ability to install to the homescreen, push notifications and several more.
- Google’s Chrome browser will look for the properties of a Progressive Web App to qualify it as a Progressive Web App and thus give it certain abilities in the browser (like the ability to add it to a smartphone homescreen). The function is done through Lighthouse, a new tool from Google to audit metrics and performance for Progressive Web Apps.
- Progressive Web Apps must provide a manifest of the site. The manifest must specify the display status of the PWA as “standalone,” “fullscreen” or “browser.” Only in “browser” will the site look like a normal website with a URL at the top. But Chrome won’t register site as a Progressive Web App if it uses the “browser” display option.
“Jeremy’s got a point, though. Hiding away URLs, pretending that this thing you’re looking at is a “native” app, does indeed sacrifice one of the key strengths of the web — that everything’s individually addressable,” Langridge wrote.
Web Development Is Messy … And That’s A Good Thing
The issue over URLs in Progressive Web Apps highlights an important fact and difference between Web development and native app development:
Web development is an iterative and messy process done out in the open (for the most part) and that is one of its key strengths.
When Google and Apple build new versions of Android and iOS, much of the work is done behind closed doors. Now, that is a bit different for Google and Android as people can track projects and contributors in the Android Open Source Project (that’s how we know that the NSA contributed to SELinux, one of the most important aspects of security in Android). But, for the most part, new Android and iOS versions are cooked up and released to developers in one swoop with beta periods for them to react and contribute to the final product.
The Web does not work on such concrete and defined timelines.
In the Web arena, frontline developers are often the ones that keep the platform vendors—Google, Microsoft, Opera, Mozilla and (sort of) Apple—honest and serving the greater community. The Web development community almost plays the role of journalists (who rarely have a voice in this arena and not listened to if they do) by speaking truth to power and creating dialog that often helps address the best needs of the Web and the people that make it and use it.
Google’s Russell attempted to address the concerns of Keith in a post on his site titled, “Not The Post I Wanted To Be Writing …”.
Which brings us to a final point that seems to have been lost: browsers can fix the real issue — sharing of PWAs and access to URLs — without anyone changing anything about their apps, and can do it out-of-band. Obviously, this is only true for browsers that support PWAs and have fast update cycles which, today, is all PWA-supporting browsers; namely Chrome, Opera, and Samsung Internet. The folks who work on these browsers — including myself — care as much as Jeremy does about the health and future of the web. I’m grateful to him for highlighting this issue and hope we can work together in the future to figure out ways to keep the best bits of the web healthy as PWAs become a common way to get back to sites users love.
The tone of Russell’s post amounts to: we get it and we understand and we have good reasons to do what we have done and we vaguely promise to address the issue.
For his part, Keith felt bad about upsetting Russell, a highly respected member of the Web development community who has been working on high-level browser functions for Chrome at Google for the better part of a decade.
But while Keith felt some remorse, in a followup post he let his original point stand and called for a certain amount of accountability from the browser vendors:
Of course the Chrome team are working on ways of exposing URLs within progressive web apps that are launched in from the home screen. Opera are working on it too. But it’s a really tricky problem to solve. It’s not enough to say “we’ll figure it out”. It’s not enough to say “trust us.”
I do trust the people I know working on Chrome. I also trust the people I know at Mozilla, Opera and Microsoft. That doesn’t mean I’m going to let their actions go unquestioned. Good intentions are not enough.
The result of this interplay is that Google’s Web masters and architects behind Progressive Web Apps are now well aware of some of the very basic issues that developers are encountering. The open and chaotic and somewhat contentious process of developing new best practices and features for the Web may seem unruly, but in the end the community … and everybody that uses the Web … should be stronger for it.