Web vs. native: let’s concede defeat

I feel it’s time to revisit the web vs. native debate, and concede defeat — or, at least, concede that the web cannot, and should not, compete with native when it comes to complex, app-like structures.

I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue.

I feel that our desire to take on native heads-on has given rise to unnecessarily complex toolchains that slow down what could be simple websites. I’m especially thinking of struggling news sites here, and will argue below that they should go native all the way and forget about the web.

Tooling redux

My recent tools article generated a lot of feedback and interesting ideas. I didn’t have the time to properly follow up, but fortunately Jeremy wrote the article I should have written last week. Read it, and you’ll be up to speed with the current debate.

The best pushback came from Sebastian Markbåge, who wrote a lucid, well thought-out call for more, and better, tooling. However, his article rests on the assumption that the web should emulate native UX and native apps.

I would like to question that assumption. Is it the web’s purpose to emulate native by inserting yet more features? I doubt it.

Native defeats web

Technically, it’s simple. The web cannot emulate native perfectly, and it never will. Native apps talk directly to the operating system, while web apps talk to the browser, which talks to the OS. Thus there’s an extra layer web apps have to pass, and that makes them slightly slower and coarser than native apps. This problem is unsolvable.

Still, we web developers have spent the last six years in denial. Our working assumption has been that all web sites should be app-like, and therefore tooled up to the hilt. The web’s universal, right? Then it’s also the perfect medium for users performing complex tasks, right?

Wrong. I think.

Emulating native leads to bad UX (or, at least, a UX that’s clearly a sub-optimal copy of native UX), and to underperforming websites because of all the libraries and frameworks we think we need. Baldur Bjarnason puts it best:

You destroy basic usability by hijacking the scrollbar. You take native functionality (scrolling, selection, links, loading) that is fast and efficient and you rewrite it with ‘cutting edge’ javascript toolkits and frameworks so that it is slow and buggy and broken. You balloon your websites with megabytes of cruft. You ignore best practices. You take something that works and is complementary to your business and turn it into a liability.

It’s time to recognise that this is the wrong approach. We shouldn’t try to compete with native apps in terms set by the native apps. Instead, we should concentrate on the unique web selling points: its reach, which, more or less by definition, encompasses all native platforms, URLs, which are fantastically useful and don’t work in a native environment, and its hassle-free quality.

Hassle-free web

Hassle-free? What does that mean? Actually, it’s pretty interesting.

Recently Benedict Evans summarised the business case for native over web to just one question:

Do people want to put your icon on their home screen?

If the answer is Yes, go native. If No, go web. But, I add, not web disguised as native.

This reminds me of a four-year old article by Scott Jenson, where he made more or less the same argument. Most business entities that require an Internet presence (think small shops, plumbers, hip food carts, or the like) will not end up on your homescreen. Instead, they require one just-in-time interaction — when you need their opening hours, phone number, or menu. Users will expect this information on the web because they’re not going through the hassle of installing their app.

Actually, this is very good news for the web. If the user doesn’t want your icon on his home screen, if the user wants a just-in-time interaction, it’s the web they want — not because of any inherent technological superiority, but because it’s hassle-free. Go there, read, forget. No junk left on your phone.

Most businesses don’t stand a chance of ending up on the users’ home screens. So they need the web — but not a web that emulates native to no particular purpose.

News sites

Arguably news sites are the ones most addicted to useless cruft. Not that news site owners desire cruft, but they have pressing business reasons to insert lots of ads and calls to action in their sites, and they want pointless interfaces in order to … well, nobody knows, really. In order to look native? Let’s keep it at that.

Let’s ask Benedict Evans’ question. Do users want their news sites’ icon on their home screens? For old-fashioned newspapers, yes, I actually think they do — and even modern news sites like the Next Web or the Verge might qualify. So that’s one compelling reason for them to go native.

Then there’s the budget question. Tim Kadlec rightly points out that

if a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.

What do you spend your site budget on? Performance or features? News sites go for features because business.

So news sites could end up on a lot of users’ home screens, and they need what native has to offer them in terms of UX. Also, if they’d use native apps the users would download the framework only once, and it would take care of displaying ads, calls to action, and nifty features (and content). After that users only have to download the actual ads (and content). Arguably, native gives better performance when your Internet presence is overgrown with cruft.

It’s for that reason that I think we web developers should advise news sites, and in fact any site that prioritises features over performance, to go native, since they stand to gain from it. In fact, we could argue that because the features that are necessary to them are such a drain on performance, the web is no longer the best medium to publish their sites.

Update: An excellent counter-argument just came in: news sites need URLs. Very valid point. Requires more thought.

Of course, creating two native apps is more expensive than creating one website. But hey, that’s the result of spending your budget on features, right? Opt for the web, and your experience will be universal, hassle-free, cruftless, fast, and somewhat cheaper. (OK, this argument needs more polishing, but I hope you see what I’m getting at.)

Rethink the web

This is an example of the sort of reasoning I’d like to see applied more. Think about your current client, and whether people will want their icon on their homescreen — and if not, why they insist on wasting budget on useless features.

How could you persuade them to either choose native or go for the web’s strengths instead of its weaknesses? Which arguments would they be susceptible to?

I’m sure there’s a lot more to discover here, and that we can rethink the web and its relation to natives based on the actual strengths and weaknesses of native and web instead of an idealised version of the web that isn’t really in touch with reality.

In order to do so, however, we need to concede defeat against native. It’ll free our thinking. I’m SO looking forward to reclaiming the web!