> If you are making a web app (like my company does) that needs to print to a label printer how should we do that besides switching to a native app that all of our clients need to install and maintain?
So rather than just doing what works and shipping a native app, you instead rely on a feature that's currently in draft status, and works in one browser.. unless Google disable it again, like they did last year?
Sounds like a winning strategy my man.
Edit: to answer your original question
> So you're against the standards entirely?
Yes. Literally the only reason either exists, is because without them Google's theory of "everything can be in a browser" falls flat on it's face, and when things are in a browser Google has a good chance of controlling the conversation (the same way Microsoft controlled the conversation in the 90s and early 2000's with Windows).
Both specs have glaring security issues that they themselves point out, but then provide no actual solution or work around for. They may as well start each one with "this could lead to compromise of your device.. life's a lottery, be lucky!"
We already have a native app but we are transitioning the majority of our core app to the web. Printing labels is one of the tricky parts that will be hard to transition. We are currently using an electron shell which makes maintenance easier but it still requires that end users install something which they might not have administrative rights to do. With WebUSB we expect that our entire app will be on the web and fully usable both on and offline without much maintenance fuss for the thousands of clients we have.
We are not a label printing business. I know I haven't really told you what we do but it's just a tiny, minor thing that goes along with the huge suite of software we make. Building on the web platform has huge advantages over native apps and we do know what we are doing.
WebUSB is just one piece of tech that helps wrap up some of the edge cases.
So rather than just doing what works and shipping a native app, you instead rely on a feature that's currently in draft status, and works in one browser.. unless Google disable it again, like they did last year?
Sounds like a winning strategy my man.
Edit: to answer your original question > So you're against the standards entirely?
Yes. Literally the only reason either exists, is because without them Google's theory of "everything can be in a browser" falls flat on it's face, and when things are in a browser Google has a good chance of controlling the conversation (the same way Microsoft controlled the conversation in the 90s and early 2000's with Windows).
Both specs have glaring security issues that they themselves point out, but then provide no actual solution or work around for. They may as well start each one with "this could lead to compromise of your device.. life's a lottery, be lucky!"