Open rdw-software opened 1 year ago
So there are two main difficulties in integrating the library, and one annoyance:
run_once
API to allow interweaving the webview
loop with libuv's event loopOne more concern: What about the different browser backends? Do they have similar capabilities? EDGE is just Chromium and the Linux WebGTK looks alright, but I'm sure there's going to be at least some gotchas when it comes to adding more native APIs (point three), e.g. for opening native file dialogs etc. - all the stuff that Electron already provides.
As for the missing APIs, I guess there would need to be a libuv-like abstraction for the three main platforms, that is compatible with how webview
does things internally. The easiest would be for them to merge that in if it could be developed, but then I can't really do OSX development efficiently so it's unlikely to happen anytime soon anyway. The main features I would be using are:
I would also be interested to see how far into the browser's innards we can reach. Probably depends on the OS API (not very far)?
Exchanging data efficiently with the frontend would be annoying. The options are:
SharedArrayBuffer
and atomic locks (yikes). Doesn't work on WebkitGTK AFAIK?So I guess HTTP requests for data fetching combined with a localhost server might work. If more is needed, either a way to use shared buffers in non-Windows frontends would have to be found, or the C functions might need to be bound (again)...
Also worth keeping in mind what kind of tasks would actually have to be handed off to the backend:
In this design, the backend would be the Lua/C engine and it can do anything a regular backend server could do... plus interact with the frontend directly if needed. It seems a bit odd to separate the UI and runtime this way, but I guess that's web apps for you.
The good news is that this would keep the frontend largely portable so the code can always be run in a regular browser, unless closer integration is needed (then JSON RPC or shared buffers might be used).
Overall I like the HTTP-based frontend/backend flow best, even if it's not ideal. There are several fallback options to explore if need be, so hopefully this design would still be flexible enough and yet relatively simple. I guess you could even do most API calls via HTTP, i.e., frontend requests runtime APIs via REST, or WebSockets (with significant overhead...). That wouldn't be much better than JSON RPC, though likely more optimized by the browser engine?
OTOH, the things that you might request from the backend are almost always heavily CPU-bound tasks or I/O-bound things that won't significantly be impacted by the overhead of a single HTTP request/response on top. Smaller stuff can just be done in JS land, which I guess means that the overhead isn't a real concern. Or it would be fast enough anyway, even with HTTP.
The only "sad" part is you cannot use NodeJS packages that aren't compatible with browsers, but that's a given (and the most popular ones might support both environments) when working on the Lua/C level. The trade-off is not running electron, i.e. more control and significantly less bloat - no more 150MB hello world apps. Is that worth it? Maybe...
Oh, and bonus points for getting to avoid all UI/sync API issues. Everything is async/await and sync stuff handled by the backend.
I think I'll just build a quick prototype for a minimal integration, then move the rest to separate issues if needed.
Also, this is blocked by #90 and at least #137 since we want to be running a HTTP server in the backend, too.
So this is a weird idea (and probably stupid), but I recently stumbled upon webview while working on some unrelated frontend stuff. Now the big question is, what if we called into that from Lua? (or C, for that matter) It sounds so absurd that it might just work...
Goals:
Roadmap:
run_once
API to allow integratingwebview
with libuv's event loop from Cwebview
APIsSharedArayBuffer
(need to check platform support)Transferable
buffers withwindow.postMessage
(need to check how to get at the buffer from C/Lua)webview_bind
(need to check if it can exchange data)webview
(and the native SDK dynamically)What are the drawbacks? Well, there's a few...