Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

It’s actually infinitely more scalable because now the device manufacturers or any developer can create a library to support any device. Before we relied on a single browser vendor or vendors to write the drivers... while google has an impressive engineering team as do all the browser vendors .. it’s not really reasonable or even as fun to have to only rely on them... imagine an IOT project adding support for HID device to control a robot or console style game... lot of neat possibilities


view as:

> It’s actually infinitely more scalable because now the device manufacturers or any developer can create a library to support any device.

Sure, but that means you as a device manufacturer have to convince all these websites to include your library and support your device. Why not have e.g. generic gamepad support in Chrome and let developers write a driver for their devices as an extension ?

Now all you get is horrible fragmentation, your device may work on website A but not on website B, and maybe kinda work but very buggy on website C.

It’s a recipe for a shitty user experience. In practice you’ll see that only a handful of popular devices will be universally supported.


> Why not have e.g. generic gamepad support in Chrome

All the browsers have generic gamepad support at this point: https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API Unfortunately, it is a bit lowest common denominator.

WebHID is good for long tail devices, or handling more unusual features of specific devices: https://web.dev/hid-examples/


> WebHID is good for long tail devices, or handling more unusual features of specific device

And that’s exactly why it will never be widely used. I’m not saying that there isn’t a use-case for it, I’m saying that the article overstates the usefulness of this API.


More likely it means there will be a few libraries that people who are into this stuff will maintain that cover most cases and they don't have to wait for the browser teams to bless their implementations. And even better if the project doesn't want to support your device you can just fork it and add it

Sure, for the use case of a device manufacturer who wants to make a niche gamepad and have it supported by many web games, it's not very helpful. But there's other use-cases here.

If you've made a specialized controller that needed something other than generic gamepad support, and a webapp, and you wanted them to talk to each other, your previous option was to lobby browser vendors to add support. Now you can build that integration yourself. I don't see how that's something to complain about


Is it possible to have a driver store? So the website would just load a library for Gamepad X from a global driver website, dynamically when you plugged it in

Legal | privacy