pptr and BG both use Chrome DevTools to communicate with the browser, so there's that commonality.
I haven't looked extensively at the pptr source but I imagine both pptr and BG do some bookkeeping of state related to the sequence of commands (BG certainly does), rather than a purely "stateless" command queue.
For instance, for some things you need to keep track of which session is associated with which target. For other command sequences (such as Runtime.evaluate) you need to know which execution context to evaluate in. And you can keep track of open execution contexts by tracking various Runtime domain events (such as executionContextCreated, executionContextDestroyed, etc).
So to provide a sophisticated level of interaction with the page, some amount of chattiness and state is required for the protocol on top of the DevTools wire protocol.
What I'm getting at is, if there are hurdles, they will likely emerge from the different ways in which pptr and BG handle state and that chattiness to achieve particular user intents.
Also, BG does not require pptr to do automation. It's possible to simply record and replay (again with a further layer of book-keeping that's too involved to get into here), the BG command sequence (which itself is a superset of the DevTools protocol).
All the same, I've often thought about providing a functionality to "export to puppeteer" (or to nightmare, or to phantomjs, etc) in terms of getting a transcript in a widely used format that people can take and run anywhere. That's one thing that excites me about pptr X BG.
In any case, automation is not something that is currently provided in the CE, but it's in the paid version at https://browsergap.xyz
pptr and BG both use Chrome DevTools to communicate with the browser, so there's that commonality.
I haven't looked extensively at the pptr source but I imagine both pptr and BG do some bookkeeping of state related to the sequence of commands (BG certainly does), rather than a purely "stateless" command queue.
For instance, for some things you need to keep track of which session is associated with which target. For other command sequences (such as Runtime.evaluate) you need to know which execution context to evaluate in. And you can keep track of open execution contexts by tracking various Runtime domain events (such as executionContextCreated, executionContextDestroyed, etc).
So to provide a sophisticated level of interaction with the page, some amount of chattiness and state is required for the protocol on top of the DevTools wire protocol.
What I'm getting at is, if there are hurdles, they will likely emerge from the different ways in which pptr and BG handle state and that chattiness to achieve particular user intents.
Also, BG does not require pptr to do automation. It's possible to simply record and replay (again with a further layer of book-keeping that's too involved to get into here), the BG command sequence (which itself is a superset of the DevTools protocol).
All the same, I've often thought about providing a functionality to "export to puppeteer" (or to nightmare, or to phantomjs, etc) in terms of getting a transcript in a widely used format that people can take and run anywhere. That's one thing that excites me about pptr X BG.
In any case, automation is not something that is currently provided in the CE, but it's in the paid version at https://browsergap.xyz