What does HackerNews think of chromedp?

A faster, simpler way to drive browsers supporting the Chrome DevTools Protocol.

Language: Go

#11 in Chrome
#56 in Go
#11 in Testing
Thanks. I've found Chromedp [0] to be a good Selenium replacement when programming in Go. Used in conjunction with headless-shell [1] you can deploy a Go app into a container and do the testing all within the same container with low overhead.

[0] https://github.com/chromedp/chromedp [1] https://github.com/chromedp/docker-headless-shell

After a bunch of searching I found a test URL. https://testsafebrowsing.appspot.com/s/malware.html via my Chrome script I get a 500. And when ignoring it in chrome manually it returns a 200 so the web url works.

This is totally an edge case I didn't even think of until I read that blog. Super happy that my monitoring approach picks up on it.

For others wanting to do the same I'm using chromedp. It does take up way more resources tho. I worked out I can do 90 per minute per 8-core 16gb server.

[1] https://github.com/chromedp/chromedp

I think that overemphasizes Pupeteer itself.

It's really just bindings for the dev tools protocol.

Half the GitHub issues result in "well the protocol requires X and we can't change that".

Pupeteer is popular because it's web automation protocol bindings for a web language, not because it a sophisticated layer or does very much.

There are literally dozens of language bindings for the protocol. [1] Some are quite good and widely used, for example chromedp (Go bindings). [2]

[1] https://github.com/ChromeDevTools/awesome-chrome-devtools#pr...

[2] https://github.com/chromedp/chromedp

The code for doing this isn't too difficult with https://github.com/chromedp/chromedp, is this just some helpers around that? I haven't used it or puppeteer on the node side that heavily, but what have you found difficult that deserves this kind of wrapper/abstraction instead of direct library use?