Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QUESTION] How does this compare to Puppeteer? #240

Closed
paambaati opened this issue Aug 17, 2017 · 7 comments
Closed

[QUESTION] How does this compare to Puppeteer? #240

paambaati opened this issue Aug 17, 2017 · 7 comments
Labels

Comments

@paambaati
Copy link
Contributor

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)?

@paulirish
Copy link
Contributor

(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. :)

@paambaati
Copy link
Contributor Author

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.

@cyrus-and
Copy link
Owner

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.

@positlabs
Copy link

This would be a good addition to the readme!

@paulirish
Copy link
Contributor

@positlabs sg. can you try to kick it off with a pull request?

@positlabs
Copy link

For sure. I'm in prototype-scramble-mode right now but I will submit a PR soon.

@cyrus-and
Copy link
Owner

Added in 6e752a0, feel free to improve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants