Hardware APIs coming to browsers

Warning This article was written over six months ago, and may contain outdated information.

There are many future web stack features that I see as being vitally important to the long-term health of the web. These include extensible web projects such as web components and CSS Houdini, as well as the scripting capabilities in ES7 and beyond. These features give developers better tools, and more fine control and power.

But I feel that what’s more important to the immediate success of the web are features that provide parity with native mobile apps. I’ve written previously about the importance of service workers in providing this parity, but there are also a few new features breaking through that I’m equally excited about, as they provide access to previously unavailable hardware.

The first is the Web Bluetooth API, which has experimental implementation in Chrome OS devices (running the Dev channel, behind a flag). This Promise-based API allows the browser to scan for local Bluetooth Low Energy (BLE) devices, such as speakers or fitness tracking wearables, then interact with them.

Scanning is as easy as requesting a list of local devices, filtered by a list of services – for example, to find a BLE device which transmits battery data:

navigator.bluetooth.requestDevice({
  filters: [{ services: ['battery_service'] }]
}).then(function (device) {
  console.log(device.name);
});

Interacting with the device requires a little more knowledge of the Bluetooth protocol – this great introduction by François Beaufort covers the basics.

Further from implementation is the Web NFC API, which gives access to Near Field Communication devices – such as tap-to-pay systems. Currently only at the spec stage, it’s also Promise-based so seems easy to get started with.

For example, this is how it’s proposed to read data from an NFC device:

navigator.nfc.requestAdapter().then(function (adapter) {
  adapter.onmessage = function (event) {
    console.log(event.message.data);
  }
});

Of course there’s no guarantee that other browsers will implement these APIs (I have particular doubts about Safari), but I’m excited by the possibility that they may be. Because parity with native mobile apps gives the browser the power to be a key component of the thingnet, communicating with the multitude of devices in the smart homes, offices and public spaces of the future.

I know that from the requests we at +rehabstudio get from our clients, connected devices are only becoming more and more popular in creative concepts. And I’m so happy with the notion that in the future I can be building browser-based applications that let me build those concepts.

‘Thingnet’, by the way, is the word I keep using in place of ‘internet of things’, but it doesn’t seem to be catching on so I may stop.

Comments are closed.