What is the difference between this and the headless_chrome [0] crate?
Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
11–20 of 20 posts
Re: Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
#12What is the difference between this and the headless_chrome [0] crate? [0]: https://github.com/atroche/rust-headless-chrome
Looks like that isn't async.
Re: Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
#13What are pdl files? Aren't protocol definition files in JSON?
(shameless plug) I guess I'll have to update my cdp java library. https://github.com/kklisura/chrome-devtools-java-client
Re: Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
#14What are pdl files? Aren't protocol definition files in JSON? (shameless plug) I guess I'll have to update my cdp java library. https://github.com/kklisura/chrome-devtools-java-client
> The pdl files are the canonical protocol definitions and are maintained manually by the devtools team [0].
The JSON protocol definition files are then in fact being generated from those pdl files. You find them mirrored in the devtools-protocol-repo [1]
[0] https://chromedevtools.github.io/devtools-protocol/ [1] https://github.com/ChromeDevTools/devtools-protocol/
Re: Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
#15What is the difference between this and the headless_chrome [0] crate? [0]: https://github.com/atroche/rust-headless-chrome
Unfortunately this crate has been abandoned by its author for quite some time now. The main differences are that are that chromiumoxide uses async rust by design and that all the devtools protocol types are generated.
rust-headless-chrome was very helpful for some parts and bootstrapped some parts of chromiumoxide, such as the key and mouse clicking. However I looked at chromedp and puppeteer itself for the most part.
Re: Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
#16All of the examples await each and everything. Where does being async become most useful? I can’t think of anything I might want to do really that won’t have me wanting to wait for the previous thing I was saying to Chrome to first complete.
Re: Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
#17All of the examples await each and everything. Where does being async become most useful? I can’t think of anything I might want to do really that won’t have me wanting to wait for the previous thing I was saying to Chrome to first complete.
You can use this for integration testing. If you have enough memory, you can then run several tests in parallel.
Or, of course, if you need to do something with headless chrome while serving a request.
Re: Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
#18All of the examples await each and everything. Where does being async become most useful? I can’t think of anything I might want to do really that won’t have me wanting to wait for the previous thing I was saying to Chrome to first complete.
Lol someone is still having an async syntax debate? How passé.
Essentially programmers want the ability to write concurrent code, without specifying the actual constructs (like threading), and the ouija board of programming community have spoken that explicit syntax is ideal. Promises were cool for a hot second, but then everyone coalesced on async/await. I thought other approaches like Python's gevent were really clever way of handling semantics, but I guess the majority didn't agree, people like explicit. But I will say, this syntax in this Rust library does look odd to me, but I agree 100% that the library made the right choice making it explicitly async. I really wish Selenium in Python used asyncio.
You're literally bike shedding on someone's amazing effort.
Re: Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
#19All of the examples await each and everything. Where does being async become most useful? I can’t think of anything I might want to do really that won’t have me wanting to wait for the previous thing I was saying to Chrome to first complete.
> I can’t think of anything I might want to do really that won’t have me wanting to wait for the previous thing I was saying to Chrome to first complete.
That's precisely the point. By using async/await you can describe each of the things you want to do as a sequence of steps depending/waiting on previous results, but at the places you'd have to pause anyway (waiting on chromium, a database, etc) you can clearly signal that the machine is free to do other things till it has your results. If you have other tasks you'd _also_ like to be doing then those can be similarly coded with async/await, and they can run during times when the first task would otherwise have been idle (or however they're being scheduled).
As an aside, async/await is just a tool to try to make your life easier. It's moderately easy to reason about (each task is sequential after all, and shared structures can only be modified at explicit pause points), the syntax is only mildly more cumbersome than writing the sequential task you were going to write anyway, and it's remarkably easy to write a scheduler to execute an async program with some degree of efficiency. You can absolutely use any other parallel execution model you'd like or none at all as the situation demands.
Re: Show HN: Chromiumoxid – An Async Headless Chrome API in Rust
#20Can I run it with Tokio?
tokio support just landed https://github.com/mattsse/chromiumoxide