Live data from Hacker News

The new browser-based puppeteer REPL, and how we built it

docs.browserless.io

11–20 of 32 posts

Re: The new browser-based puppeteer REPL, and how we built it

#11

Could you elaborate a little on ‘puppeteer in the browser’? Is puppeteer running on a webserver then the repl connecting to it? Or is puppeteer completely contained within each users browser?

Sure! Puppeteer is a node-based library, and pretty much all the web-apps out there that let you run puppeteer code do it in an elaborate node sandbox. This tool gets around that by running puppeteer in your own browser, making it a lot faster and more secure

Re: The new browser-based puppeteer REPL, and how we built it

#13
post #2

Hey, Joel here, mostly responsible for this tool. Happy to answer questions — one thing not well covered is getting puppeteer to run in the browser, especially a webworker. Can talk more about it if there’s interest!

This is magical and cool. As a web dev generalist, I can usually understand how most things work under the hood. But playing with chrome.browserless.io breaks that. You're streaming the web page in a element, but how can I highlight text? When I load a youtube video page are you literally proxying the video through your infra, through pixels to my browser? Who dictates what IP the headless chrome is assigned to? Do y…

Yup, There’s a lot going on here. Currently the tool uses a fixed IP for the running browser. That’s why you’re seeing that Cloudflare issue.

As far as the hovering goes, the canvas element is “mirroring” interactions back through to the underlying page. When Devtools are active, this triggers chromium to render hover effects in its GUI. This then gets sent back to the canvas element in the debugging page.

It’s a lot of network traffic and Synchronization... but once everything is setup it works fairly seamlessly

Re: The new browser-based puppeteer REPL, and how we built it

#14
post #3

I've used Puppeteer extensively and its the most unstable tool that I've come across in recent years. Its full of race conditions and the waitForSomething functions will sometimes work, sometimes not. It's usable, but it's very aggravating and uncomfortable to use.

In what sorts of ways would they fail?

Was it definitely not that there were inconsistencies in the pages that you were interacting with?

Curious as someone who has done some browser automation, but not in a while and never with Puppeteer.

Re: The new browser-based puppeteer REPL, and how we built it

#16

Earlier quoted context omitted.

This is magical and cool. As a web dev generalist, I can usually understand how most things work under the hood. But playing with chrome.browserless.io breaks that. You're streaming the web page in a element, but how can I highlight text? When I load a youtube video page are you literally proxying the video through your infra, through pixels to my browser? Who dictates what IP the headless chrome is assigned to? Do y…

Yup, There’s a lot going on here. Currently the tool uses a fixed IP for the running browser. That’s why you’re seeing that Cloudflare issue. As far as the hovering goes, the canvas element is “mirroring” interactions back through to the underlying page. When Devtools are active, this triggers chromium to render hover effects in its GUI. This then gets sent back to the canvas element in the debugging page. It’s a lot…

can you explain how this is architected? you are running a browser on a server and its streaming the video to the canvas? where does the cloudflare bit come in?

very interesting project!

Re: The new browser-based puppeteer REPL, and how we built it

#17
post #3

I've used Puppeteer extensively and its the most unstable tool that I've come across in recent years. Its full of race conditions and the waitForSomething functions will sometimes work, sometimes not. It's usable, but it's very aggravating and uncomfortable to use.

Have you tried Playwright? It is a fork of Puppeteer that adds auto-waiting

Re: The new browser-based puppeteer REPL, and how we built it

#18
post #15

Hey, I have a question. On your home page it says that the usage-based plan doesn't offer the Live Debug, how does one debug scripts on that plan?

You can use our demo debugger (the address is in this blogpost). It might not match your version of puppeteer exactly, but it’s a close enough proximate that it’s still valuable

Re: The new browser-based puppeteer REPL, and how we built it

#19
post #16

Earlier quoted context omitted.

Yup, There’s a lot going on here. Currently the tool uses a fixed IP for the running browser. That’s why you’re seeing that Cloudflare issue. As far as the hovering goes, the canvas element is “mirroring” interactions back through to the underlying page. When Devtools are active, this triggers chromium to render hover effects in its GUI. This then gets sent back to the canvas element in the debugging page. It’s a lot…

can you explain how this is architected? you are running a browser on a server and its streaming the video to the canvas? where does the cloudflare bit come in? very interesting project!

You’ve got it: the core service listens for inbound Upgrade http requests, starts a browser, then funnels the connection into the browser.

This debugger simply sits on top of all that, and puts the code/execution context in the browser versus the server. Cloud flare is simply detecting that our server IP is a known headless chrome instance, and is serving their bot detection check

Re: The new browser-based puppeteer REPL, and how we built it

#20
Nice! We built something like this 3 years ago while I was still at Intoli. Instead of Puppeteer we used our own Web Extensions API based framework called Remote Browser [1], the core of which was written by my cofounder.

The tour is still up at [2]. The servers that actually run the Remote Browser have since gone down, but interestingly you can still run the tour. That's because if you don't change the code in the REPL window, you get cached results (except step 7/7 which scrapes Hacker News and won't work). To get those results, we built a little tour "recorder" that would be run on every release. If I remember correctly, we allowed some dynamic ES6 imports through a custom Babel compiler for the code that's input, which also allows first level async stuff, which still works :)

[1]: https://github.com/intoli/remote-browser [2]: https://intoli.com/tour/

Post reply on HN