3 ms·

This topic fascinates me because I've successfully built an app and business around an Electron app (no Linux, yet) that connects to USB devices on Mac and Wind

This topic fascinates me because I've successfully built an app and business around an Electron app (no Linux, yet) that connects to USB devices on Mac and Windows. The app uses native node modules for USB (not chrome). I've been successful using these npm modules: "@nodert-win10-rs3/windows.devices.custom" and "enumerated" on Windows and "usb" on Mac. Interestingly, "usb" relies on libusb which isn't really an option for the common Windows user. A naive developer will read about WebUSB and think, "oh, Electron is Chrome, so this must be a good solution!" but remember that Electron apps consist of one node process (main) and multiple chrome processes (renderers, aka, BrowserWindow objects). In my experience, it is poor design to exclusively connect to USB hardware using a BrowserWindow. Instead, it's much better to use the main node process to handle all exclusive USB access, and then push state to renderers using IPC. So, once you go down this road you realize that WebUSB on Electron isn't viable. The idea seems good, but was dead on arrival for me. Your mileage may vary. Ten years ago I would never have identified as a hardware-focused software developer. Now it's become part of my professional identity. My speciality is Electron/USB. You can check out my USB-heavy Windows/Mac app at https://www.label.live https://www.label.live. I'm available for consulting if you have a need for custom desktop software that talks to hardware. I've solved dozens of incredibly difficult problems over the last few years. Super fun.

anaisbetts 7y ago
> Instead, it's much better to use the main node process to handle all exclusive USB access, and then push state to renderers using IPC. You should absolutely not do this - don't do anything in the main process at all; blocking it even a little bit makes your entire app janky and hang'y. If you want to connect to USB hardware in an isolated context, create a hidden renderer process (aka a BrowserWindow that you don't call `show` on), though tbh I would just use your existing BrowserWindow, I'm not sure why you immediately dismiss it as "poor design".
- semireg 7y ago
  You’re assuming the USB read and writes block, but they are in fact async and work quite well for this purpose. My app is document-based so the user may have multiple label designs open. Because of this, USB is handled from a central location. That could be another renderer, but then you have to shuttle data from renderer to renderer (via main) which in and of itself becomes laborious.
teruakohatu 7y ago
Very good looking app, but please adding pricing to your website.It took far to many clicks on my mobile device to figure out the in-app purchase costs around $48, and even then I don't know if that is a subscription or not. The price is reasonable no reason to hide it.

anaisbetts 7y ago

> Instead, it's much better to use the main node process to handle all exclusive USB access, and then push state to renderers using IPC. You should absolutely not do this - don't do anything in the main process at all; blocking it even a little bit makes your entire app janky and hang'y. If you want to connect to USB hardware in an isolated context, create a hidden renderer process (aka a BrowserWindow that you don't call `show` on), though tbh I would just use your existing BrowserWindow, I'm not sure why you immediately dismiss it as "poor design".

semireg 7y ago
You’re assuming the USB read and writes block, but they are in fact async and work quite well for this purpose. My app is document-based so the user may have multiple label designs open. Because of this, USB is handled from a central location. That could be another renderer, but then you have to shuttle data from renderer to renderer (via main) which in and of itself becomes laborious.

teruakohatu 7y ago

Very good looking app, but please adding pricing to your website.It took far to many clicks on my mobile device to figure out the in-app purchase costs around $48, and even then I don't know if that is a subscription or not. The price is reasonable no reason to hide it.