Last Updated on
The web platform has advanced out of all recognition, and continues to evolve at a frankly bewildering pace (I’m paid to keep track of all this stuff, and if I take a fortnight’s holiday I scramble to get back on top of it).
Four years ago, if you wanted to access your device’s GPS information, you pretty much had to use a native app; now, the W3C Geolocation API is available in all browsers, on most classes of devices.
The advancement of what marketing and the press like to call “HTML5” (but mostly isn’t just HTML5) is closing the gap between the capabilities of native and web. But it isn’t there yet.
In 2011, Joe Hewitt (original Firebug developer and Facebook person) wrote a great blog post called Web Technologies Need an Owner, which I quote here but is worth reading in its entirety:
The arrogance of Web evangelists is staggering. They take for granted that the Web will always be popular regardless of whether it is technologically competitive with other platforms. They place ideology above relevance. Haven’t they noticed that the world of software is ablaze with new ideas and a growing number of those ideas are flat out impossible to build on the Web? I can easily see a world in which Web usage falls to insignificant levels compared to Android, iOS, and Windows, and becomes a footnote in history. That thing we used to use in the early days of the Internet.
My prediction is that, unless the leadership vacuum is filled, the Web is going to retreat back to its origins as a network of hyperlinked documents. The Web will be just another app that you use when you want to find some information, like Wikipedia, but it will no longer be your primary window. The Web will no longer be the place for social networks, games, forums, photo sharing, music players, video players, word processors, calendaring, or anything interactive. Newspapers and blogs will be replaced by Facebook and Twitter and you will access them only through native apps. HTTP will live on as the data backbone used by native applications, but it will no longer serve those applications through HTML. Freedom of information may be restricted to whatever our information overlords see fit to feature on their App Market Stores.
I disagree with Hewitt’s suggested remedy – that there should be one rendering engine with “competent, sympathetic, benevolent leaders” and therefore no standardisation forum – but I share his worry. I want web to win.
I’ve been musing on what’s still missing from the web platform to make it more attractive to developers, and asked for people’s reasons why they chose native app development which I recorded in a gist.
Many of their “missing pieces” are actively being worked on in W3C and other standards bodies. DRM is controversially being worked on, specified by Google, Micrsoft and Netflix. I argue that “DRM” a necessary evil to prevent the web platform becoming irrelevant to a company like Netflix (which by itself constitutes a third of American peak-time internet traffic), but I mistrust its plugin architecture (without having the wit to suggest something better).
Hardware access is being looked at by the W3C sysapps group, which is working on things like Bluetooth API, Calendar API, Device Capabilities API, Network Interface API, System Settings API.
Camera access (and microphone) is handled by WebRTC, implemented in Chrome and Firefox. Presto-based Opera allows access to the camera with the getUserMedia API (a subset of WebRTC).
A Notifications API exists, but it’s not implemented anywhere as it’s incomplete I’m a liar; Web Notifications is supported by Chrome. (Correction courtesy of @simevidas) However, the spec only allows native-style notifications to show while the user has the relevant page open.
Offline working is very important – we see that in developing countries, web sites offering Java apps are very popular because of games that can be played offline. Although the current Application Cache is good enough for simple offlinerification, it isn’t powerful enough for industrial use. Jonas Sicking of Mozilla has a proposal to improve appcache.
One spec that also needs a mention here is the badly-named Indie UI spec. I assumed it was about User Interface and was therefore bound to fail (who would take seriously an attempt to standardise UI?) but it’s actually about User Interface Independence, abstracting away the “how” a user attempts to scroll (scrollwheel? swipe? pen? joystick? keyboard down-arrow?) from their intention. It’s like W3C Pointer Events taken further:
Independent User Interface (IndieUI) is a way for user actions to be communicated to web applications… IndieUI will allow web application developers to get these events from different devices without having to recognize how the user performed the action. With IndieUI, AT will have a simple set of events to control web applications, and web application developers will have a uniform way to design applications that work for multiple devices and contexts.
The adequacy of the Web platform depends on what kind of apps you’re making. The UK Government Digital Service recently cheered my cold, cynical heart by saying
Our position is that native apps are rarely justified … Stand-alone mobile apps will only be considered once the core web service works well on mobile devices, and if specifically agreed with the Cabinet Office … For government services, we believe the benefits of developing and maintaining apps will very rarely justify their costs.
When it comes to mobile, we’re backing open web standards (HTML5). We’re confident that for government services, the mobile web is a winner, both from a user and a cost perspective.
Apps may be transforming gaming and social media, but for utility public services, the ‘making your website adapt really effectively to a range of devices’ approach is currently the better strategy. It allows you to iterate your services much more quickly, minimises any market impact and is far cheaper to support.
This is about informational or transactional apps, rather than super high-performance games or heavily media-centric apps. But the latter aren’t the majority, even if they are higher-profile – according to yesterday’s HTML5 vs. Native vs. Hybrid. Global developer survey 2013. (Beware reading too much into this survey, as it’s commissioned by a Microsoft-centric company, so the respondants may have different perspectives than other app developers.)
Monetisation feels like a big deal to me. The Mozilla guys have an API called navigator.mozPay() but as far as I can tell this is only for Firefox OS and not the open web, so not relevant to this discussion at the moment. Hopefully, it will feed into the W3C Headlights project, which has identified Web Payments, HTML5 Performance and “Closing the Gap with Native” as areas for urgent study.
It seems to me that if reach is your goal, the Web Platform is your better choice – it works in lots of places. If getting paid for your app is your goal then currently native or hybrid development is your better strategy. We need to stop looking queasy when people want to get paid, too; free stuff isn’t an inalienable human right.
What can you do if you want the web to win? Use it, and nurture it. If you’re prepared to spend hours debating whether rebase or squash is considered harmful (and you should, because using tools well is the mark of a professional), then be prepared to spend 41 minutes considering whether your markup makes sense – the code that the browser runs is your product. As Confucius would undoubtedly have said, “Don’t just be on the web, be of the web”.
Hassle me, and other representatives of browser companies to get new standards agreed, and implemented. Vendor co-operation, clueful devs, Device APIs, open Operating Systems that don’t lock users into one browser, and (crucially) auto-updating browsers are the cornerstones of an open web.
(Added Friday 12 April: .net magazine interviewed me after reading this, where I reiterate and elaborate some of my points.)