Google developer discusses 2014's hot industry topics

Jake Archibald is a developer advocate at Google, working to develop and promote web standards and developer tools. Here, he discusses some of the industry's hot topics.

Why do developers arguing against progressive enhancement have such a broken definition of it?

JA: Progressive enhancement is a buzzword. All buzzwords have broken definitions. But at least progressive enhancement has a loose definition, which is the idea of layering different technologies to build up a user experience gradually. When the term was first used, it used to be about sites working without JavaScript. I don't think that's true any more. JavaScript isn't an optional part of the web platform.

Is it bad to show a button that doesn't work until JavaScript comes in? [The example isofarro used in the original, unedited tweet - Ed.] I don’t think so. If you can get to a first render of a page without JavaScript, including the potentially interactive parts, that's brilliant.

You need a little bit of JavaScript in there at the start to cater for what happens if a user presses that button, showing something like a spinner and avoiding any further interaction, then the JavaScript can come in and respond to that button. It's great that you can get such fast behaviour; that something looks like it has loaded before it actually has.

I think progressive enhancement is all about playing to the strengths of the browser. Just with HMTL and CSS, a browser can get to a render. It can start rendering the page before it has all of that HTML. And it's really tough to replicate that behaviour in JavaScript. But trying to do the more complicated stuff - like real-time updates - without JavaScript is difficult, and is going to look terrible. [We should] use all of the technologies to create the best user experience.

What's the best way to progressively enhance a basic HTML site into a JavaScript-driven single-page app?

JA: The first thing I'd say is: ask yourself what you'd gain by doing so. You should only start bringing in JavaScript if it makes the user experience better. There are very few cases where it's worth [taking] a basic HTML site and making it a single-page app.

Say I have a multi-page site like Wikipedia. [I could make it a single-page app] by having JavaScript jump in to show a spinner [when the user clicks a link] and use the History API to change the URL to the href of the link, then make an XHR request to get the content of the link, either as HTML or some kind of JSON format, then update the content using a templating system, or just by swapping in the HTML. But what would I actually gain by doing that? OK, if I click on a link, I get a spinner. But the browser will give me that for free. And doing it with JavaScript isn't really faster.

But say I had a stocks-and-shares app, the way I'd progressively enhance that is by doing the first render on the server - I'd have SVG markup for the stocks graph, then all the rest as HTML markup - and, as soon as the JavaScript had loaded, I'd open up a WebSocket connection or some kind of server-sent event so that I could manipulate that graph in real time. There you get the best of both worlds: you've got to the first render quickly, and now you're getting live updates in real time.

How do you think offline functionality will affect the future of apps in general?

JA: Offline is broken on the web. We don't really have any way to do it. We've got the Application Cache, but it was made with single-page apps in mind, and it's a pain in the arse to use. But I think offline is pretty broken in native apps, too. If you turn off connectivity on your phone, very few of them are going to do anything [more useful than] presenting you with a spinner and saying, 'Network connectivity failed'.

I think the web has the potential to beat native apps. We were talking about progressive enhancement earlier, and this is the next step. We need to treat the network as a piece of progressive enhancement. We need to start building apps offline first, get to the first render without the network, using cached data, [then] fetch new data to update the page.

Every time someone builds a native app, or a browser-specific app, the web has lost. Native is always going to be faster than the web, because you have lower-level access. But that's true of writing assembly code: it will always run faster than C++. We need to get to the point where the difference isn't worth the extra effort [of] building and maintaining separate versions for all those platforms. If we do that, the web wins. And if the web wins, we all win.

This article originally appeared in net magazine issue 247.

Liked this? Read these!

• Our favourite web fonts - and they don't cost a penny
• Brilliant Wordpress tutorial selection
• Create a perfect mood board with these pro tips