Chrome-remote-interface: [QUESTION] How does this compare to Puppeteer?

Created on 17 Aug 2017 · 7Comments · Source: cyrus-and/chrome-remote-interface

Pardon me for not using the issue template, but this is a more general question.

How does this compare to puppeteer? It looks quite similar to this project.

The README includes this in the end -

We've reached out to a number of these projects to see if there are opportunities for collaboration, and we're happy to do what we can to help.

Has the Chrome team gotten in touch with you? Can we use this issue to track progress and/or updates on the collaboration (if there's going to be any)?

question

Source

paambaati

Most helpful comment

(i'm on the chrome devtools team and not a maintainer of chrome-remote-interface but i know the project fairly well. ive been contributing to puppeteer for a few months.)

the two projects operate at different layers of abstraction. cri is a very direct API for the devtools protocol. this protocol is exactly what puppeteer uses under the hood. Dealing with the protocol itself can be verbose at times, but allows ultimate control. Puppeteer was created because we know that writing simple automation scripts against the protocol can a little tedious sometimes.

(fun fact: cri was a runtime dependency of puppeteer for a long while. an effort to slim down dependencies ended up changing that, no slight against cri).

if the feature set of puppeteer isn't good enough for users, then they can always go straight to the protocol. cri is and has always been the recommended library for working with the protocol in javascirpt, as we recommend on https://chromedevtools.github.io/devtools-protocol/ and https://developers.google.com/web/updates/2017/04/headless-chrome#useprotocol

i've said it before but i again want to point out that @cyrus-and has done a phenomenal job with the cri project. :)

paulirish on 17 Aug 2017

👍9 ❤4

All 7 comments

(i'm on the chrome devtools team and not a maintainer of chrome-remote-interface but i know the project fairly well. ive been contributing to puppeteer for a few months.)

(fun fact: cri was a runtime dependency of puppeteer for a long while. an effort to slim down dependencies ended up changing that, no slight against cri).

i've said it before but i again want to point out that @cyrus-and has done a phenomenal job with the cri project. :)

paulirish on 17 Aug 2017

👍9 ❤4

I totally agree. I've built a fairly complex crawler using this module, and it wouldn't have been possible if not for @cyrus-and's super-helpful responses on the issue tracker.

@paulirish BTW, I love puppeteer too! I had spent a ton of time writing logic for waiting until page load and idle-detection, and it is cool to see that it is pretty close to what you guys have implemented.

paambaati on 17 Aug 2017

❤4

Thank you @paulirish and @paambaati! :)

@paulirish's comment pretty much sums it up, it's really low vs high level abstraction. The main goal of this project is just to avoid the tedious task of managing the WebSocket frames directly, nothing here is tightly coupled with a specific DevTools Protocol feature, in fact you can use CRI to inspect Node.js programs and even instrument Microsoft Edge as they expose a limited version of the protocol.

Conversely, puppeteer not only takes care of launching Chrome it also downloads and bundles a Chromium version at install time:

By default, Puppeteer downloads and uses a specific version of Chromium so its API is guaranteed to work out of the box.

Which is pretty cool and should provide an awesome out-of-the-box experience for users.

Can we use this issue to track progress and/or updates on the collaboration (if there's going to be any)?

So just to be clear puppeteer and chrome-remote-interface will continue on two separate paths and I'll be more than happy to keep on maintaining this project (and issue tracker) for those who need to work with the raw DevTools Protocol.

Thanks again @paambaati for this question as it surely will be helpful to others.