Serial API - moving from Web of Sensors CG to Web Incubator CG

Native application platforms offer developers the opportunity to integrate hardware and software in a single offering. For example, an educational product aimed at laboratory sciences might offer a data logging device and a software package for visualization and analysis of the data collected. The web platform has historically only been able to support these applications through the use of native plugins that provide access to the platform APIs necessary to integrate with peripherals. With the introduction of the Web Bluetooth and WebUSB APIs this is no longer the case. We see devices such as the PocketLab kits and NumWorks calculator taking advantage of these new capabilities to build web-first applications.

USB and Bluetooth, however, do not cover the full range of hardware interfaces commonly used by computer peripherals. Due to its simplicity and low cost to implement many devices still communicate over some type of simple serial bus. This may be an actual RS-232 cable or a virtual serial port emulated over more modern transports. It is common to find that a device that presents itself as having Bluetooth or USB is actually made of two components, a generic Bluetooth or USB interface chip connected via TTL serial to a microcontroller that implements the “brains” of the device.

We therefore propose to resume the work begun by Mozilla on the Serial API by moving the specification into the WICG. The API will be extended with a chooser-based permission model similar to what is specified for Web Bluetooth and WebUSB.

Edited to update links now that this migration has occurred.

Pursuing hardware support is currently not a focus for Mozilla, so it’s probably not something we would consider implementing. However, I think it would be valuable to separate the Serial interface (as a JS primitive) from the actual underlying hardware serial implementation itself.

Wanted to add my support for moving to the Web Incubator CG for further development, with some case studies below.

For companies who distribute IoT microcontroller boards, it’s fast becoming a common scenario to provide users with a web interface / web IDE vs. a custom application because of ease of development and distribution. WebUSB can be used with a small collection of them, but the majority require a serial interface instead.

Currently as you’d be aware, the Serial API is only available in Chrome apps on Chrome OS. This is where we’ve seen some great uses of the Serial API, some of which involve my own software which is why I add my support here.

I maintain avrgirl-arduino (https://github.com/noopkat/avrgirl-arduino), which helps developers use JavaScript to flash programs onto a selection of AVR chip based Arduino boards. It is primarily used by Arduino LLC within their Arduino Create Chrome App - https://create.arduino.cc and it is only within this Chrome app scenario that it works, severely limiting the use cases for easy to access IDEs for programming hardware / learning to code with them.

My library avrgirl-arduino needs support for serial connections as most microcontroller breakout boards on the market for makers use this interface to program the chip and for bicommunication when running the program. This means that Arduino requires a secondary background application to run on the users’ computers in order for them to use Arduino Create on any other platform than a Chromebook.

There are a myriad of other examples of web based microcontroller IDEs, including Microsoft Make Code, a collaboration with Adafruit - https://learn.adafruit.com/makecode and Chirpers - https://chirpers.com/

Thanks for reaching the bottom! I appreciate your time to read this muchly.

Considering the huge amount of devices already out there using an off the shelf FTDI or similar chip with a standard USB serial solution, having a Serial API would make it possible to move existing solutions to pure web. Many enterprises have worldwide solutions relying on this and are currently stuck maintaining very old legacy native code to support the hardware. Some will be able to update the firmware with WebUSB support, but many will not (either lack of skills in the company or no possibility to update the USB driver chip with the chosen HW design).

I think the use cases might be overlapping but still slightly different from WebUSB:

WebUSB is great for both enterprise/business and consumer use as it gives very specific low level access to hardware. However, in most cases, it will require WebUSB support to be built into the firmware as - in practice - most USB interfaces will potentially already be accessed/claimed by drivers or apps on the connected system.

A Serial API will initially be great for makers and educators (e.g. Arduino users) but also for enterprises as I mention above.
For mass market consumer use, I think WebUSB will be the winner as it gives better control and usage/connectivity is more similar across OSes (low level USB) as opposed to Serial (COMx vs /dev/ttyX, ModemManager on Linux, odd behavior on Windows regarding enumeration, etc.). Also, devices that can run a modern browser AND have an actual RS-232 port are most probably going to be for industrial use - not consumer.

TL;DR: I fully support this proposal - especially valuable for huge legacy enterprises!

I think this would be quite useful. There is even a lot of hardware with USB out there where it is very hard to add support for Web USB because they use proprietary chips and don’t have access to reflash the chip. Many of these support serial communication, so this would definitely be helpful in supporting more devices and use-cases.

Are you thinking about creating some integration for Web USB, in the cases that people want to use serial over USB, but potentially expand it to do more, without having to move everything to a whole new API?

I’m unreasonably excited about the prospect of this. So just want to add my +1 to others’

Hello,

I am speaking as Arduino CIO. We indeed use Serial communication quite a lot and this is why we built https://github.com/arduino/arduino-create-agent and https://github.com/arduino/arduino-create-agent/blob/devel/seriallist.go#L14 < to me this feels like an hack because we would dramatically prefer a web native API instead of dealing with a lot of security issues and not-uniform OS APIs. Just to mentions some issues we encountered: https://bugs.webkit.org/show_bug.cgi?id=171934 More in general we now have more than 500000 users and the great majority of the users’ devices do not have USB capabilities (we are speking about millions devices) and this is not jsut about Arduino itself. We do know most of the Industrial grade CNC machines or small legacy devices are using serial communication only and most of the industry can take 10 to 20 years before chaning their hardware in the field.

So I honestly thing having a Serial API is going to change the IoT world so I am really in favor of moving Serial API to Web Incubator CG. I think some devs in our team can also help you in defining the APIs and help in the testing phase if you ask for. We already have a huge database and a public api to expose information about the device given the VID/PID. Ask us any kind of help, we deal with Serial devices everyday and we faced a lot of challenges and solved most of them already.

I think there are some interesting possibilities for integrations between WebUSB and the Serial API. For example, a USBDevice object could have a serialPorts attribute listing SerialPort objects for all of the USB interfaces on the device that implement a serial-over-USB protocol. My instinct is to leave this out of the initial design and focus on getting the SerialPort interface correct first because integrations with other APIs adds additional complexity we won’t initially need.

The maker movement by single board computers will enhance the interest of such interfaces. In that sense, I think GPIO and I2C interface are also interesting subjects as well. The CHIRIMEN community develops a training kit that makes these interfaces available from SBC’s web browser. https://chirimen.org/

I see valuable use cases, people interested in carrying on this work, and adequate implementer support. So +1 to moving the specification back into active development in the WICG.

(Btw. the subject of this topic is a bit confusing since there’s no “Web of Sensors WG”. AFAICT, the spec is a CC0-licensed unofficial draft that lives under the WHATWG’s GH org.)

My mistake, it should be “Web of Sensors CG”: https://www.w3.org/community/sensorweb/

+1 for this.

There will still be new serial devices made, and probably millions out in the field for the foreseeable future. We currently don’t have a true cross platform way to communicate with these devices without a Serial API.

Another great use case is a chrome app that we helped build for Parallax Inc. https://github.com/parallaxinc/Parallax-IDE

It’s an educational IDE for people to compile and upload firmware to Parallax’s Basic Stamp hardware. The compiler itself was converted to JavaScript via emscripten allowing the application runs completely offline. With a Web Serial API and web assembly, these type of applications could become Progressive Web Apps without dependencies on things like the now chromeOS-only chrome.serial API.

+1 for this.

I can’t wait to get started with it - especially as the intent to implement includes Android support.

I’m the main developer of the Espruino JavaScript interpreter. The IDE for this currently uses chrome.serial and Web Bluetooth for communications. While I can use NW.js to get chrome.serial in native apps, the looming closure of the Chrome Web Store would have caused a massive upset to my users - especially in schools where installing new software can be painful.

There are over 50,000 devices running Espruino out there now (most of them USB). 20k+ have FTDI/etc chips and the rest need a serial connection in order to update firmware so Web USB hasn’t really been a valid option. The ease with which devices can be connected with Web Bluetooth has been a massive eye opener, and I can’t wait for that to also be available to owners of non-bluetooth Espruino devices.

I’m happy to help with this however I can.

As a lightweight communication channel to existing devices, WebSerial would be a really nice and simple method for tethered control and device debug.

+1 From me

We’re a +1 at micro:bit (microbit.org) too, one of the really common ‘next steps’ that people want to take with the micro:bit is using it to log data, or to use it as an input device for code running in the browser (for example as the Scratch team has done over Bluetooth - https://llk.github.io/microbit-extension/iste18/). As we use USB Mass Storage for flashing (aside from an exciting but still small scale webUSB test programme: https://microbit.org/testing/#web-usb) we don’t have any two-way comms betwen the browser and the micro:bit without people first installing native applications.

Doing serial over webUSB is possible, but is cumbersome for a range of reasons, and there are >1.7M micro:bits already out there that don’t have webUSB firmware already, but do have CDC!

Thank you everyone for your strong support. Now for an update on our progress on this API. As of Chrome 77.0.3849.0 the first useful version of the Serial API is available behind a flag. There are many known issues but it should work well enough for you to try it out. A full Origin Trial is still planned but the message I got from developers was that being able to experiment with it behind a flag to see if it met their needs was the highest priority. Now that we have gained some implementation experience with this API in the Blink engine I will be incorporating that into the draft specification.

Follow along with implementation progress in Chromium here: https://bugs.chromium.org/p/chromium/issues/detail?id=884928

The Chrome Status page for Serial API notes Firefox as opposed under Consensus & Standardization. Is there a discussion where Mozilla’s concerns are expressed or was this documenting that Mozilla is just not focusing on this effort (instead of opposed to it)? I could not find an entry on the Firefox platform status page for Serial API or an issue related to this new iteration of a Serial API in bugzilla.

I’ve updated the Chrome Status page to list Mozilla’s position as “public skepticism” with a more detailed note reflecting Mozilla’s historical position on this class of APIs and @marcosc’s comment at the start of the thread. This note apparently does not show up in the dashboard so I’m including it here,

Mozilla has established that their position on low-level hardware APIs such as WebMIDI, Web Bluetooth and WebUSB is that they are likely harmful due to fundamental security concerns and has not prioritized further investigation. There has been no official comment on this particular proposal.

An issue was filed in the Firefox bug tracker with a prototype implementation contemporary with the original Serial API specification work. It has no seen recent progress.

you may want to look for their standards positions dashboard instead.

The MakeCode editor for EV3, https://makecode.mindstorms.com/, currently uses UF2 drag and drop to flash the EV3 brick over the USB cable. With Web Serial we are able to flash LEGO EV3 bricks over Bluetooth.

pull request https://github.com/microsoft/pxt-ev3/pull/920