[idealmedtech]

Native code allows for performance gains that a script (even a performant one) may not be able to match. After all, this is fundamentally an image processing problem, one of the more computationally expensive things a browser has to do.

[Gigachad]

Isn't that the point of webassembly? Just seems like we are still moving in the wrong direction on trying to move the whole of NPM in to the browser web apis, rather than building a solid base you can build anything on.

[michaelt]

High performance barcode decoding (e.g. scandit) uses the GPU.

After all, a modern cell phone could be producing 4k 30fps video, and high performance barcode decoders will detect linear barcodes with lines a single pixel wide, even in the presence of moderate noise/blur/overexposure (e.g. the barcode on a shiny can of coke)

Of course, I've got no idea if browsers will provide high performance barcode reading, or something simpler like zxing.

And I've got to say, it's not obvious to me why browsers would implement a barcode scanning API in preference to a more general accelerated image processing API. Plenty of other applications want to do real time video processing in the browser - such as video call background removal.

[nwsm]

Do you have any examples of what a more general image processing API would feature? Everything between reading pixels and reading barcodes is a mystery to me.

[idealmedtech]

I'm not a browser developer, but to wager a guess, it probably has something to do with the inertia of existing solutions being native, rather than in WebAssembly, which is still quite new as standards go.