search

WICG / webhid

Web API for accessing Human Interface Devices (HID)
Other
142 stars 35 forks source link

What is the longer term goal? #53

Open idontusenumbers opened 3 years ago

idontusenumbers commented 3 years ago

The stated impetus for this API as documented on https://web.dev/hid/:

There is a long tail of human interface devices (HIDs), such as alternative keyboards or exotic gamepads, that are too new, too old, or too uncommon to be accessible by systems' device drivers. The WebHID API solves this by providing a way to implement device-specific logic in JavaScript.

This will certainly improve the accessibility for writing code against HID devices, forgoing the need to learn, develop, build, and distribute native device drivers.

However, I suspect countless web developers implementing HID 'drivers' in javascript is just going to cause a new problem: inconsistent, buggy, and out-of-date behavior with very limited device support and sparse QA/Testing.

Is the expectation that individual devices drivers will be built and packaged as npm packages? Or driver libraries emerge with embedded collections of drivers that are community supported? Certainly Chrome devs don't expect independent developers to build drivers themselves for countless, (as indicated) inconsistently built devices.

I see a bleak future with a hodgepodge of inconsistently implemented and unpredictably supported hardware much worse than the stated problem. Am I missing something?

nondebug commented 3 years ago

I expect there will be a mix of device drivers published by the manufacturer, third-party drivers developed by the community, libraries that collect related device drivers, and generic drivers intended to support a class of devices. I don't have any opinions on how they should be packaged or distributed.

Certainly Chrome devs don't expect independent developers to build drivers themselves for countless, (as indicated) inconsistently built devices.

I think it's reasonable to push this work onto the community. Projects like the Linux kernel and SDL2 already support large numbers of HID devices as a community effort. Before WebHID, independent developers were already writing device drivers in javascript using node-hid.

Allowing the community to add support for the devices they use is better, in my opinion, than forcing them to wait until a browser developer gets around to adding explicit support in a high-level API (which might not happen at all).