-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support chrome.serialport #739
Comments
TLDR Chrome packaged apps are deprecated and with them the only web serial api, The people powerful enough to push a draft for these drivers (arduino? ftdi? google?) aren't, so I wouldn't bother with spending engineering resources on web serial. Just back from Chrome Dev Summit. Some thoughts. Google have delivered webusb to chrome as part of their w3c draft https://wicg.github.io/webusb/ and seem deadset on that being the future here. Google deprecated chrome apps a year ago https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html and thats the vehicle we were getting serialport on the web via https://developer.chrome.com/apps/serial The only usual suspect Ive heard from or seen publicly fight these loss of apis is Parallax who invested heavily in them with their Chrome IDE for education markets (note I was co-contracted to build that) https://www.parallax.com/downloads/parallax-ide-chrome The people youd expect to be freaking out and fighting for serialport (arduino) or ftdi (gotta be a big part of their business) are not being vocal and I dont think Googles feeling ANY pressure over the loss of these apis. We (or better yet, FTDI) could build a serial 'driver' over webusb, but the problem here is most usb devices are claimed by the operating systems ftdi drivers (by default on mac/linux), which means well have no luck teaching our users to disable their operating system drivers... I think were already seeing a move away from 8bit devices as they are unsuited to network communication like bluetooth and wifi, and thus a move to arm devices which often are paired with usb (mbed and dap are king here already) or some sort of ble or wifi communication for programming and communicating. Id focus resources on electron packaging to help get people serial + web technologies that way. |
Thats kinda sad. I wonder what firefox thinks these days? We have pretty stellar electron support at the moment (prebuilding for all platforms) never mind it's still a complex ecosystem. |
Email from Chrome today, no link to share, heres contents. TLDR Chrome apps (including serial) supposed to die q1 2018, new stay of life through mid 2018 when PWA are installable but still no runway for serial "Hi Chrome App Owners, You're receiving this email because you have at least one Chrome app published in the Chrome Web Store. Chrome Apps are currently scheduled to stop working on Windows, Mac & Linux in Q1 2018, as Chrome continues to focus on moving the open web forward. The Chrome team is now working to enable Progressive Web Apps (PWAs) to be installed on the desktop. Once this functionality ships (roughly targeting mid-2018), users will be able to install web apps to the desktop and launch them via icons and shortcuts; similar to the way that Chrome Apps can be installed today. In order to enable a more seamless transition from Chrome Apps to the web, Chrome will not fully remove support for Chrome Apps on Windows, Mac or Linux until after Desktop PWA installability becomes available in 2018. Timelines are still rough, but this will be a number of months later than the originally planned deprecation timeline of "early 2018". We also recognize that Desktop PWAs will not replace all Chrome App capabilities. We have been investigating ways to simplify the transition for developers that depend on exclusive Chrome App APIs, and will continue to focus on this - in particular the Sockets, HID and Serial APIs. To be clear, the overall trajectory of the Chrome Apps platform is not changing. Support will still be fully removed on Windows, Mac & Linux in the relatively near term, therefore we don't see Chrome Apps as a viable long-term solution for new or existing projects. Additionally, Chrome Apps will still be de-listed from the Web Store before the end of 2017 as originally planned. At this time, all Chrome App listings will be hidden from Web Store search and browse functions on Windows, Mac, and Linux. Support for inline installation will also be removed.* At a later date, we'll provide another more specific update on new timelines for the full removal of Chrome Apps support on Windows, Mac & Linux. Best, *Chrome Apps will still be indexed in search engines, and it will still be possible to install apps via the deeplink to the store page. The primary change is that Chrome Apps will no longer be organically discoverable by browsing or searching in the Chrome Web Store. You've received this mandatory service announcement email to update you on important changes related to the Chrome Web Store and Apps Platform. Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043" |
=(
…On Tue, Dec 5, 2017, 9:43 PM Jacob Rosenthal ***@***.***> wrote:
Email from Chrome today, no link to share, heres contents. TLDR Chrome
apps (including serial) supposed to die q1 2018, new stay of life through
mid 2018 when PWA are installable but still no runway for serial
"Hi Chrome App Owners,
You're receiving this email because you have at least one Chrome app
published in the Chrome Web Store.
Chrome Apps are currently scheduled to stop working on Windows, Mac &
Linux in Q1 2018, as Chrome continues to focus on moving the open web
forward.
The Chrome team is now working to enable Progressive Web Apps (PWAs) to be
installed on the desktop. Once this functionality ships (roughly targeting
mid-2018), users will be able to install web apps to the desktop and launch
them via icons and shortcuts; similar to the way that Chrome Apps can be
installed today.
In order to enable a more seamless transition from Chrome Apps to the web,
Chrome will not fully remove support for Chrome Apps on Windows, Mac or
Linux until after Desktop PWA installability becomes available in 2018.
Timelines are still rough, but this will be a number of months later than
the originally planned deprecation timeline of "early 2018".
We also recognize that Desktop PWAs will not replace all Chrome App
capabilities. We have been investigating ways to simplify the transition
for developers that depend on exclusive Chrome App APIs, and will continue
to focus on this - in particular the Sockets, HID and Serial APIs.
To be clear, the overall trajectory of the Chrome Apps platform is not
changing. Support will still be fully removed on Windows, Mac & Linux in
the relatively near term, therefore we don't see Chrome Apps as a viable
long-term solution for new or existing projects.
Additionally, Chrome Apps will still be de-listed from the Web Store
before the end of 2017 as originally planned. At this time, all Chrome App
listings will be hidden from Web Store search and browse functions on
Windows, Mac, and Linux. Support for inline installation will also be
removed.*
At a later date, we'll provide another more specific update on new
timelines for the full removal of Chrome Apps support on Windows, Mac &
Linux.
Best,
The Chrome Apps & Web Store Team
*Chrome Apps will still be indexed in search engines, and it will still be
possible to install apps via the deeplink to the store page. The primary
change is that Chrome Apps will no longer be organically discoverable by
browsing or searching in the Chrome Web Store.
You've received this mandatory service announcement email to update you on
important changes related to the Chrome Web Store and Apps Platform.
Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043
<https://maps.google.com/?q=1600+Amphitheatre+Parkway,+Mountain+View,+CA+94043&entry=gmail&source=g>
"
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#739 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABlbsjZqlaVHkOSXffjr-af8HzUJEafks5s9f9lgaJpZM4ICW9d>
.
|
Guess we should close this. |
The wonderful browser-serialport project has lead the way for this. As we start changing our api and isolating our bindings to have a more consistent behavior, having these projects separate seem like a lot more work than supporting
chrome.serial
here. In essence I'd like to merge the two projects.This would make it easier for projects to support the browser environment too. For example Firmata who figured out how to do this themselves.
I see this as a few steps.
chrome.serialport
(browser-serialport
has done a lot of work for this) to be abinding
browser
field to swap out the bindings. https://github.com/substack/node-browserify#browser-fieldThe text was updated successfully, but these errors were encountered: