Ooh, that sounds cool. I'd love to hear about that when it comes out.
That's great, I will announce it on this forum when it's ready
Hey @d4h0 do you have any links to documentation on the DevTools protocol?
Edit: NVM I found it:
Yes, that's the best resource page for the DevTools protocol.
Anyone have intuition why the best solutions do not involve Servo? (This is rather surprising to me, as I was expecting some cool servo related library.)
As far as I remember, Servo only can render basic HTML, CSS, and so on.
@d4h0 you don't happen to have anything at all that you could share for your WIP devtools library, even if it isn't completely ready, do you?
Sorry, but no, my crate isn't ready for anything yet. In the next few days, I will complete the low-level API (API types, protocol stuff, internal machinery). On top of this low-level API, I will then build the end-user API ("click", "wait_for_x", and so on).
The code still changes a lot, so that is the reason why I don't want to publish it yet.
Essentially I need all the CDT protocol handling to happen in one thread in an event loop, but the headless_chrome crate uses a separate thread for its event handling and that is incompatible with the !Sync + !Send event handlers I need to support for my use-case.
What I have so far is written in an executor agnostic and async way (so it can run on a single-threaded executor) – but out of curiosity, could you tell me why you have this limitation?
I was planning to create my crate threaded, instead of async, but it turned out that async has some benefits regarding the control flow I needed.
Btw., did you try to setup up a headless_chrome event handler that communicates with your !Sync + !Send
code via a channel?
(From your first post)
Preferably via Rust. (If some other language is better suited for this, I'm welcome to those suggestions too.)
As you probably know, Puppeteer.js is most likely currently the best option (hopefully, that will change for Rust, when my crate is ready... ;)).
If you, like me, don't like JavaScript at all, then bs-puppeteer might be an option.
Basically, it's a binding for OCaml/ReasonML and Puppeteer.js (OCaml/ReasonML can be compiled to JavaScript via the BuckleScript compiler).
If I had to build something production-ready right in this second, I most likely would go this route (OCaml and ReasonML are also nice).
But, I don't like JavaScript and its ecosystem at all, so I try to use it as little as humanly possible...
(I'm planning to explore the possibility to compile and inject WebAssemply into browser frames, which hopefully would make JavaScript completely unnecessary... :)).
I'm faced with just handling the protocol manually,
To hack together something that is as type-safe as Puppeteer.js should only take a few hours.
Basically, you would do the following:
-
get the WebSocket address of the server (printed to stdout, or available from http://localhost:9222/json/version via HTTP)
-
connect to the WebSocket via tungstenite, async_tungstenite or tokio_tungstenite
-
use serde_json to create commands and parse responses
But I guess it will be a real pain to use the DevTools protocol directly.
If you go this route, the following links should be useful:
'chrome-remote-interface' is a low-level API for the DevTools protocol and JavaScript (basically, what I have almost ready for Rust). The links above show how to do different things via the DevTools protocol.