I read PPK’s “Web vs. native: let’s concede defeat” article with great interest.

I agree quite strongly that the web does not need to emulate native to provide a powerful, vibrant app ecosystem. If your goal is to build awesome experiences for the web, you will be very poorly served by attempting to just emulate native. The web has its own set of strengths – its ephemeral nature and lack of friction, for example, and its incremental security model.

However, I believe it’s fundamentally flawed to draw lines around the experiences you can build with the web, and “concede defeat” to native apps. PPK himself previously identified that “Web vs native [is] the wrong question”. The “web has to capitalise on its own strengths, primarily its reach”. To my mind, those strengths don’t end when the user wants a home screen icon to integrate that experience better in their experience.

The web has incredibly low friction

The average mobile user visits far more sites per month than individual apps – I’d postulate because installing an app has a somewhat high cost; you have to knowingly wait for the app to install, possibly agree to a EULA-like list of permissions that you may not understand (or more likely, haven’t bothered to read), and then you’ll be reminded of this relationship forever after by that icon in your home screen (if not notifications popping up).

PPK referred to a article by Scott Jenson to support that home screen location was the dividing line between web and native; but Scott DIDN’T make the point that home screen icons are the problem, he made the point that having to curate a set of apps was a problem. In fact, Scott’s point was largely around the importance of just-in-time interaction vs having to curate a set of apps. The necessity of this curation comes from space, device impact (aka “stuff running in the background that can drain my battery and/or annoy me with notifications), and permissions, more than home screen icon space IMO. This is certainly a pain point for users, though; I’ve changed mobile devices multiple times in the past year, and Android helpfully re-installs apps for me – reminding me just how much junk I’ve installed.

The web, by comparison to native platforms, is very low friction. Commerce is heavily web-based, even on mobile devices – watch the excellent talk just given by Alex Komoroske and Elisabeth Morant at Google IO for more.

Everyone wants to be on the home screen

PPK’s presumption is that engagement – RE-engagement, in particular – is just not done for web apps. That’s no longer true. We’ve had add to homescreen for quite a while – of course, it’s been somewhat hidden; but now, with re-engagement features like push notifications and add-to-homescreen apps that work offline thanks to Service Workers, putting web apps on the home screen is no longer putting lipstick on a pig; for example, I didn’t bother installing the Google I/O native app – I just added the Google I/O web app to my home screen, and it popped up notifications when it was time to go to a session and everything. With the addition of web app install banners, we’ve made this both much more natural and more effective.

I believe no content developer – say, a news site – would agree that they don’t want to be on the home screen. They DESPERATELY want that re-engagement with the user. The user, however, may not be completely ready to sign up to that just yet; they want to date for a while before living together. But adding an icon to the home screen is like putting someone in your speed dial; it doesn’t mean you’re handing them the keys to your house.

The web, by contrast, excels at just-in-time interaction, as it IS hassle-free. But it’s a natural progression to enable users to move that onto their home screen, and let them get notifications and other engagement features if they so desire. This is still the web, though – I don’t need to have the NYT app open just to read the article at a link I followed. There are also app-like behaviors you may want occasionally too, e.g. a “what’s near me?” app. There’s an assumption that app-like behaviors demand native, and that the web is for documents.

The cruft of the current Web

Of course, the web development model also has its own set of challenges. In particular, there is a huge over-indulgence in trackers today, and this can wildly impact responsiveness. If you run a plugin like Ghostery for a while, you’ll quickly learn just HOW prevalent add-ins like this are. In a quick tour around common news sites, for example, I found the AVERAGE number of external tracking libraries being loaded to be more than twenty.

Would I include more than twenty external code libraries into my native app, for dubious user benefit? Probably not. As Jeremy put it, that cruft was put there by us; and Marco Arment agrees: “The entire culture dominant among web developers today is bizarrely framework-heavy, with seemingly no thought given to minimizing dependencies and page weight.” I think it’s also true that web developers tend to rely heavily on frameworks, sometimes without understanding the cost/benefit tradeoffs in order to use them judiciously. Particularly in the case of stale frameworks, or ones that don’t adhere to a RAIL-like philosophy, this can dramatically impact your usability. I’m not saying “never use trackers”, but take a look in dev tools; maybe you don’t need a couple of dozen trackers on every page. Focus on providing an incredible user experience; the little things add up.

Rethink the web

Properly designed web apps in the modern world – particularly, utilizing Service Workers in order to manage your performance and offline experience – can be incredibly responsive, and with re-engagement features like push notifications being added daily, the web is now a viable platform for engaging user experiences.

There will always be reasons to build native applications. It’s quicker to innovate platform APIs when you don’t have to go through standardization and browser implementation. Exposing new “bedrock” APIs can be done more quickly. As Jeremy aptly summed up, “The price we pay for that incredible cross-platform reach is that features on the web will always be lagging behind.”

On the other hand, reach is incredibly beneficial. Low-friction initial engagement (and scalable re-engagement) are an amazing on-ramp for users.