Bruce Lawson's personal site

What does the web platform need next?

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.)

Games developers benefit from the huge performance increases in JIT JavaScript engines, WebGL and Mozilla’s asm.js project looks very interesting. Whether this is enough, I don’t know; I neither write games or even play them. (Disclosure: Opera has a game engine product called Sphinx that I’ll talk about soon.)

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.)

(Last Updated on )

Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)

17 Responses to “ What does the web platform need next? ”

Comment by Gerben

A lot of business still use paper. But somehow, printing from a web-app is still the same nightmare it was 10 years ago. Almost no print-specific css support.

And no way to remove those (in my opinion useless) headers and footers on every page.

Comment by Eric

Glad to see you mention payments, which seems like it could open up all kinds of new business models and attitudes towards content. Advertising is junky; much of the web feels ephemeral, junky, and indirect (pop unders?!). Curious to see what happens if/when people start treating web content as something with intrinsic value rather than as a means to other ends.

Comment by BrianMB

The correct answer is hardware I/O. If the Web can’t use USB, HDMI, etc, it will always be playing catch-up to advances in consumer electronics.

Comment by Jon Rimmer

The problem with adding APIs for things like USB and HDMI is that they move the web platform further away from the device agnosticism that has been a key to its success. APIs that provide access to very specific hardware aspects like USB and HDMI cannot be implemented on devices that do not support them. That means code that uses is them will never work on those devices, and the web becomes fragmented.

Eventually you will end up with a set of APIs that expose the hardware capabilities of Android devices, another set that expose the capabilities of iOS devices, and so on. At that point, it’s no longer the web, it’s just JavaScript bindings to the OS. And people will be essentially writing native apps that only run on their target device. The harder, but better path is to to abstract the low-level details of hardware and provide APIs that allow you to achieve the same thing in a cross-device, hardware-agnostic fashion.

A good example of this is touch events. The DOM’s event model was conceived in the pre-touch era, so it originally only supported mouse and keyboard. When Apple built the iPhone, they made touches simulate mouse clicks, but that wasn’t enough to express capabilities like gestures and multi-touch, so they also added a new API for touch events. Unfortunately, this makes it possible to write code that works for touch devices, but not for mouse-based ones.

Microsoft’s answer to this problem was the Pointer Events spec, which provides a way to combine touch and mouse input into a single, abstracted concept. That way apps, can be written against this API which will work well with touch, mouse, stylus, eye tracking, etc.

To some extent, you have to recognise differing device capabilities. You can’t write a camera API that works on devices without a camera, for example. But there is a balance to be struck between exposing low-level hardware capabilities and ensuring the web remains reasonably cross-platform compatible.

Comment by Andy O'Neill

What users want is something which behaves like an installed application. For business users that means they want a windows application really. It’s usually pretty much fashion that decides the application must be delivered in a browser while all the users are (in practice) sat at windows desktops.

The problem with HTML and browsers is everything is implemented a bit differently. Design by committee implementation by companies WANT to differentiate their product. That’s a recipe for mediocrity and complications.

I’ve worked with html5 and I’ve worked with Silverlight. Silverlight is a joy to work with by comparison. It’s designed and implemented by one company. Bit of a shame MS decided to shelve it.

Personally I think I’d rather see installed apps “win” over web.

Comment by Russell

Most of the apps I use on my phone could be web applications. Generally they just display info, like the weather, news, train times, dictionary, etc. There’s no real reason for them to be apps that I can see.

I expect at some point it will become too costly to develop apps for all the different platforms out there. As it stands, to target everyone you need to develop for iOS, Android, Windows Phone and BB. In the next year or so you’ll need to include FireFox OS, Tizen, Ubuntu and Sailfish. This is obviously going to get worse and app makers will gradually turn into web application makers as the companies commissioning them realise they need to target everyone and not just the top 2 or 3 platforms.

Hopefully Mozilla will get the new APIs used in FireFox OS standardised and other mobile OS makers will have to implement them as well to not miss out. That’s what we really need to escape from platform specific apps. Another plus side of this would be that the same web app would be able to run on your pc and your phone.

Comment by Stephen Shankland

This is tangential, but don’t just blame “HTML5” on the press (of whom I am a member). I hear HTML5 from PR and marketing and analyst types over and over. We’re complicit, but it’s a much broader segment of the industry than just the nattering nabobs.

Comment by Mike Anderson

Since the beginning the web has been helped and hindered by it’s strong documented based foundation. A transition from a document-centric model to an app-centric model must be facilitated with the languages of the web.

We need an imperative language that’s more expressive than JavaScript. Probably something more classically OO, but the important thing is that it be good at abstraction. And ideally the same language on the client and the server.

The language should be able to replace all the other (HTML, CSS, JavaScript, etc.) languages so you could, if desired, build a web page completely with a single imperative language. The separation content, style and action in the traditional manner with 3 different languages makes component based approaches much more difficult and a way around this would open things up to a more fecund ecosystem.

Comment by Mike

The web? It needs to NOT be HTML-based and javascript needs to be replaced with a real language … to include real binary support, true native code, modules/packages and the link. And that does not include the turd that is Java.

We’re still piling shit on top of shit the was spewed out back in the early 90s. We’re building castles on top of 20 year old sand. We need to step back, say “let’s look at this, figure it out and start over.”

I never thought I’d want to see ActiveX make a comeback, but something like it with Obj-C/C#/C++11 could be interesting.

Compilers are already available for every OS. We can ship a stripped down lib that does not include the dangerous things like memcpy(). Already there are proposals to take C code and change it to JS. On-the-fly compiles and run it native. Skip JS.

At what point do we say “why are we limiting ourselves to inferior and outdated technologies?”

It’s time to move on. Go/Dart was amusing. You want something that runs in a VM, but it still compiled? Has functional aspects like closures and first order anonymous functions? Fast to code?

I would love to see Erlang replace V8. Much faster, real packages and scopes, excellent binary support, runs in a VM, fast to code can be scripted or compiled.

Probably never happen, but so long as JS/HTML/HTTP dies and we get a real language in the browser with a real protocol … that will rock.

Comment by YABE Yuji

From a game developer’s view:

– WebGL/Web Audio everywhere (by default, of course)
– Compatibility
– Stabilty (iOS JavaScriptCore can’t execute large scripts correctly. Often hangs without any messages)
– More stability (many WebView apps such as Twitter for iOS often crash on complex web apps)
– Performance (Android Canvas is ridiculously slow)
– Consistent and predictable performance (if a function runs 10x slower on one browser/device, it becomes useless for real-time applications. e.g. globalCompositeOperations of Canvas)
– Reliable requestAnimationFrame which can always get a smooth 60 fps animation on all supported browsers. Current implementations have many glitches.
– Way to render crisp pixel arts (see http://phoboslab.org/log/2012/09/drawing-pixels-is-hard)
– Reduce input lags (see http://phoboslab.org/log/2012/06/measuring-input-lag-in-browsers)
– Gimme a bug free Android browser!
– Archived progressive downloading to reduce web requests and gain download speed (like SWF file)
– JavaScript is a problem. Freedom to use program languages other than JavaScript
– Alternatively, at least adding operator overloading to JavaScript. This feature is required for readable geometry operations such as “v1 + v2 * 3” not “Vector3.add(v1, Vector3.mul(v2, 3))”. This is one killer reason why 3D game programmers prefer to use C++/C# and almost never care other languages.
– Current SVG implementations are very limited and buggy. And needs GPU rasterization for high dpi devices.
– Copy protection & method to prevent cheating (but because this must be opporsed to the open-web philosophy, I think there’s no solution)
– Login is a problem (http://www.lukew.com/ff/entry.asp?1716)
– How can I do MODs on web apps? 🙁
– SIMD, multi-threading with shared memory…
– And so on…

With these many troubles, I’m sad to say the fact that the web is not for games. Probably we’ll stick to native apps for coming 10 years.

I also can forecast music production tools can NEVER become web apps because of an audio latency issue and the JavaScript GC pause problem. Overall, the web platform has fundamental defects for real-time applications and can’t replace all native use cases.

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.