What Comes Next for the Web Platform?

The Web has come a long way from the document focussed hypertext network it began life as. Almost from its beginning, developers have been pushing its capabilities, often in ingenious if not entirely safe ways.

In recent times, standards bodies and browser developers have been upping the pace in the development of the underlying technologies of our platform, and there’s no one better to give us a sense of where we’re at, and more importantly where these technologies are going than Alex Russell, who is part of both the W3C’s Technical Architecture Group, and TC39, the committee standardizing JavaScript. Alex will set the scene for Code by asking “what comes next for the Web platform”.

When asked to talk about this topic Alex worried at first … Does the web have a future? Is the trajectory good? Truism “future has arrived but is not evenly distributed” is especially true in software.

There are great new feature for the web but many new ideas can’t be used universally. Web components was better in the sense that it used the existing platform to extend, rather than building everything from scratch. So what about other parts of the platform?

With TC39 they did a sort of archeology. So he went back and looked at the question what did we think the web was going to look like, back in 2006?

Slide: “WE WON ON DESKTOP” … we did really well with the web on desktop, but just in time for mobile to eat the world. The web is not doing as well on mobile as it did on desktop.

Web users spend 14% of their time on sites and 86% of their time in apps.

The return of ObjectiveC shows that it’s not the technology that drives these things. Nobody would have predicted ObjectiveC back in 2006.

We aren’t asking the right questions about why the web is not doing better on mobile. Case in point… the W3C’s own mobile tech resources aren’t responsive!

Google just had to put a graphic on their blog

“IT’S 2015! WE JUST DID THIS!”

It’s not about technology, it’s about our expectations.

In the dialup era, going online was an occasion. You explicitly decided to sit down at a computer, plug in a modem and get online. You knew it would be slow and just dealt with it.

These days we expect things to work. So when the web fails, when the core tenant that “everything is a click away” fails, we fail the user. From the user’s perspective we’re a flaky friend that you can’t rely on when you need them.

The web has no application model. You cannot tell what is a page, a URL or application. Apps with one single URL break the basic tenants of the web. But then if we make everything the old way with separate URLs will it still work offline?

Our platform currently cannot differentiate page from apps. It’s a question the platform simply doesn’t answer.

With all these problems… what explains all the e-commerce success? Most of the time and money on mobiles is spent on social and gaming apps. However all the e-commerce happens on sites – in browsers, not apps!

Meanwhile it’s expensive to get native app users. $1-2 per install; $9 per signed-in user. That’s what you have to spend on advertising/promotion to get people to install AND use your app.

There’s also the problem of zombie apps – unmaintained, apps with tiny user bases (a couple of dozen)… the majority of app developers don’t make enough money to pay for the tools they need to create apps. “Developer poverty”… where devs are below the poverty line of their ecosystem.

Alex thinks of app development like buying a lottery ticket – it’s a chance, a very small number of people get rich. The people who win do make a lot of money. The rest make nothing. “It’s sad!”

Because people are desperate to get users into apps, they do really bad things like put full-page blocking interstitials over their website – trying to get the user to install an app instead.

Users use 12-20 apps per month, but visit more than 100 distinct sites per month. (Data from opted-in chrome users)

Distribution is an extremely hard problem in software. It used to be much worse, when you had to sell floppy disks! We don’t do that now.

It’s the friction that really kills us now. There’s a 20% drop-off for apps for every action the user needs to take to get an app working. The web has nailed this – you go to a URL, the site works.

So what’s missing?

  1. homescreen access – less typing, more tapping. Chrome can now suggest a user adds a regularly visited site to their home screen. Then you can launch that website full screen. They’ve moved lots of stuff out in the manifest – <link rel=”manifest” href=”manifest.json” />. “Progressive apps” – you start using them as sites, they start working like apps as you use them.
  2. push notifications – equal access to system UI matters hugely to devs. Chrome can now let a site prompt the user to ask if they want notifications. The notifications work even when Chrome is closed. This doesn’t require an install step.
  3. offline support – it isn’t an app if doesn’t start when you tap. Google Gears and appcache were failures as they assumed far too much about what an app was going to look like. Now they’re doing something different, with service workers. Service workers load asynchronously after the first site load, then they can intercept new network requests and show the user a response even if the network isn’t available. You can still load the shell of the app. (works in chrome and firefox). Service workers are network progressive enhancement. The sites still work in browsers that don’t support service workers. They don’t intercept the first load experience, you still need that to work. After that, you can extend users’ patience for that initial load time – they can see a response quickly even if there’s latency going on.