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 fea­tures that I see as being vital­ly impor­tant to the long-term health of the web. These include exten­si­ble web projects such as web com­po­nents and CSS Hou­di­ni, as well as the script­ing capa­bil­i­ties in ES7 and beyond. These fea­tures give devel­op­ers bet­ter tools, and more fine con­trol and power.

But I feel that what’s more impor­tant to the imme­di­ate suc­cess of the web are fea­tures that pro­vide par­i­ty with native mobile apps. I’ve writ­ten pre­vi­ous­ly about the impor­tance of ser­vice work­ers in pro­vid­ing this par­i­ty, but there are also a few new fea­tures break­ing through that I’m equal­ly excit­ed about, as they pro­vide access to pre­vi­ous­ly unavail­able hardware.

The first is the Web Blue­tooth API, which has exper­i­men­tal imple­men­ta­tion in Chrome OS devices (run­ning the Dev chan­nel, behind a flag). This Promise-based API allows the brows­er to scan for local Blue­tooth Low Ener­gy (BLE) devices, such as speak­ers or fit­ness track­ing wear­ables, then inter­act with them.

Scan­ning is as easy as request­ing a list of local devices, fil­tered by a list of ser­vices — for exam­ple, to find a BLE device which trans­mits bat­tery data:

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

Inter­act­ing with the device requires a lit­tle more knowl­edge of the Blue­tooth pro­to­col — this great intro­duc­tion by François Beau­fort cov­ers the basics.

Fur­ther from imple­men­ta­tion is the Web NFC API, which gives access to Near Field Com­mu­ni­ca­tion devices — such as tap-to-pay sys­tems. Cur­rent­ly only at the spec stage, it’s also Promise-based so seems easy to get start­ed with.

For exam­ple, this is how it’s pro­posed 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 guar­an­tee that oth­er browsers will imple­ment these APIs (I have par­tic­u­lar doubts about Safari), but I’m excit­ed by the pos­si­bil­i­ty that they may be. Because par­i­ty with native mobile apps gives the brows­er the pow­er to be a key com­po­nent of the thingnet, com­mu­ni­cat­ing with the mul­ti­tude of devices in the smart homes, offices and pub­lic spaces of the future.

I know that from the requests we at +rehab­stu­dio get from our clients, con­nect­ed devices are only becom­ing more and more pop­u­lar in cre­ative con­cepts. And I’m so hap­py with the notion that in the future I can be build­ing brows­er-based appli­ca­tions that let me build those concepts.

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

1 comment on
“Hardware APIs coming to browsers”

  1. […] should soon be fur­ther extend­ed to allow user inter­ac­tion. And, slight­ly fur­ther in the future, new hard­ware APIs like Blue­tooth and NFC will per­mit inter­ac­tion with the physical […]