Re: [web-bluetooth] Service Worker support for WebBluetooth (#422)

<details>
<summary>offtop</offtop>

@foxt I think the most of the problems with browsers is that

1. they expose too dangerous APIs to be exposed at all. Examples are WASM, WebGL, WebGPU, WebUSB, WebBluetooth, Service Workers, and so on
2. they often without proper user-vetting. An example is `getBoundingClientRect` and API to get and measure time.
3. they try to expose generic APIs that can be easily and efficiently repurposed for malicious purposes instead of presenting narrow domain-specific APIs efficient and easy-to-use for solving a certain task without using any 3rd party libs at all and maybe even without JS, but unusable for anything else. For example instead of generic WebGPU there should be 4 distinct APIs: a) 3D rendering API (including raytracing, but without any custom shaders) b) physics engine API c) machine learning model inference API d) Proof-of-Work API. This way it is possible to cover almost all the needs of users of GPU, but without allowing low-level attacks like GLitch. Of course it means that browser vendors would have to design a set of APIs for them the way allowing to plug any existing 3rd party lib (game engine, physics engine, machine learning inference framework like onnxruntime, impls of PoW) under such API, but the benefits outweight. Not needing to force devs to bring themselves a lot of inefficient JS and WASM code, having a single engine with single API, built-in into browser, compiled into optimized native code reusing existihg shared libs in system (this way lowering memory consumption), are not bugs, but important features. If a new important use case emerges, there will be native libs for it that could be wrapped into new sets of APIs.

So I think that it may be optimal for WebBluetooth not to provide a generic API but concentrate on certain widespread use cases that cannot be abused, and leave everything else to native apps.


@PavelCibulka

>websites are replacing most of the classical EXE applications

It is impossible to do it fully and it is inefficient to do it in the most of cases. In fact the trend is AOT-compilation of code that used to be JIT-compiled (.Net, JVM, WASM, ONNX, QML). I expect eventually people will choose the more efficient solution, and HTML + JS is damn inefficient for the purposes of GUI, for example syntax highlighting using HTML eats damn a lot of memory and it is unfixable in principle, the only alternative to it is to bring an own text rendering. There is no reason to reinvent a wheel, other than the desire to bring that into browser. IMHO it'd make more sense to make an HTML element adding a native source code editor area (maybe with some control on syntax highlighting via loadable specifications of syntax and some IDE-like features with LSP (with same-origin policy) ) into browsers and not to try repurpose HTML for that. And some thjngs shouldn't be done in browser at all, like rendering rich text documents like doc, docx and odf. PDF - it has already become a part of a browser, but the main feature of `pdf.js` is that it is written in a memory-safe language. Impls in Java, .Net or Rust should do the job of rendering pdf better.

</details>

-- 
GitHub Notification of comment by KOLANICH
Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/422#issuecomment-1628726630 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 10 July 2023 11:07:46 UTC