Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A remote browser product, open-sourced

github.com

Post reply on HN
Print view View original

51–60 of 159 posts

Re: Show HN: A remote browser product, open-sourced

#51

Post by oefrha »

o-__-o wrote: post #45
oefrha wrote: post #32

Earlier quoted context omitted.

Genuinely curious: who’s your customer base? I mean, in theory the web is a cesspool of malware, but with reasonably good content blocking (I’m not even in the completely-disable-JS crowd) and conscious avoidance of shady sites, I managed to pretty easily stay clear of all attacks so far, at least over the past decade. Those way more paranoid than me still have the option of using local VMs/containers without too muc…

I'll tell you the value of this software. I can build software for non prod environments and allow my developers/testers access. for instance, with wordpress, domains are hardcoded into the database leaving you with risky sed commands against mysqldumps. With this I can launch wordpress into its own environment where www.foobar.com resolves but I can run all dev code there. I currently use a proxy and have instructio…

Have you tried using this? When I said

> sacrifice the ability to interact with text, resolution, color accuracy, frame rate, etc.

it’s very much an understatement... Pretty sure your devs/testers won’t appreciate the experience. Frontend devs in particular can’t possibly work with this.

I fail to see why it’s hard for you to spin up (possibly gated) dev/staging instances; certainly much easier and much less resource intensive than something like this.

Anyway, your use case only makes sense when the code can be self-hosted, but apparently this product / product category has customers before the source is opened up, and that’s what I’m curious about.

Re: Show HN: A remote browser product, open-sourced

#52

Post by dijit »

AndrewThrowaway wrote: post #50

Bleak future flashed in front of my eyes - Google Chrome v100 - browser runs on google's cloud, you are just being streamed view to your Chrome Client™. So secure and you are so out of control.

Which would definitely be in-line with what they're doing presently with Stadia.

Re: Show HN: A remote browser product, open-sourced

#53

Post by rvense »

thih9 wrote: post #43
Nextgrid wrote: post #39

Earlier quoted context omitted.

That is a "feature" of ReCAPTCHA, and I believe there might even be a patent on it. The idea is that if you are sure it's a bot and want to deny them access you still waste their resources by making them solve impossible captchas.

> if you are sure it’s a bot Looks like it happens not only in that case.

Being sure and being wrong are not mutually exclusive, unfortunately.

Re: Show HN: A remote browser product, open-sourced

#55

Post by slowenough »

dijit wrote: post #52
AndrewThrowaway wrote: post #50

Bleak future flashed in front of my eyes - Google Chrome v100 - browser runs on google's cloud, you are just being streamed view to your Chrome Client™. So secure and you are so out of control.

Which would definitely be in-line with what they're doing presently with Stadia.

For better or worse, I think the economics of it mean this is what will happen in future.

As it gets possible to build very large and powerful computers more cheaply, they'll still be expensive and only the biggest corps will deploy them. And the experience deliverable from virtualized apps in those clouds will be vastly better than anything that can be run on a device. Considering the impact and requirements of AI only makes this more likely.

So after briefly becoming all about "edge computing" and "fat clients" in the recent past, I think the future is going to see a swing back toward massive centralization. This will also only be compounded by the next advances in wafer process and quantum, and the increases in bandwidth to allow richer experiences over 5G.

Our pocket devices might be "supercomputers" but the real supercomputers are still going to be in the cloud and capable, I think, of running everything.

TL;DR - the next big advance in computing tech will disproportionately allocate towards the cloud rather than the device, is my bet. And we'll all have "dumb" terminals streaming us VR/AR + AI experiences all the time.

Disclaimer: that future is not why I made this, I still think it is some time off and it just seems obvious this will happen. Rather than becoming all about "more powerful devices, less powerful servers", I think the future will be the other way round. :)

Re: Show HN: A remote browser product, open-sourced

#56

Post by slowenough »

cryptozeus wrote: post #54

On ios safari, browergap is unusable. Screen is totally pixelated after hitting the search button.

Thanks a lot for your time on this report, and I'm really sorry about that! It sounds like the screen is pixelated and unusable. That must be very annoying!

I don't have an iPhone next to me right now, and I have not tested in Safari for about a week. Would you mind sharing a screenshot?

I know that because iOS Safari does not support WebP, I'm just using JPEGs which means the quality is worse there.

As a short term workaround, I'll now turn up the JPEG quality. This will take some time to propagate to browsers.

Again, I'm very sorry you had this experience today! I will test on iOS and improve the usability. I've had other reports that scrolling is terrible in iOS.

I'm just adding the iOS issues to the GitHub repo now. It could be great to contribute your screenshot to there! :)

Edit: Also, I'm sorry but would you be able to tell me are you using https://free.cloudbrowser.xyz or https://hk.cloudbrowser.xyz?

Because I am testing serving HK with imports rolledup for speed (less requests), and wonder if this caused a further issue.

Re: Show HN: A remote browser product, open-sourced

#58

Post by slowenough »

Abishek_Muthian wrote: post #27
slowenough wrote: post #7

Earlier quoted context omitted.

Hey! Thanks for the message. I like browserless! I don't use puppeteer. I use Chrome DevTools Protocol heavily tho. I started using chrome-remote-interface but hit limits in what it can do with Targets (specifically, flat session mode) and the latest versions of the API. Now I just use the WebSocket directly. I'd like to partner. Email me cris@dosycorp.com

Will there be any architectural hurdle in integrating puppeteer with BrowserGap to provide a remote automated workflow?

There's no reason this couldn't happen.

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

Re: Show HN: A remote browser product, open-sourced

#59

Post by superasn »

computator wrote: post #33

Someone else already mentioned being hit by Google captchas and the developer of this service said that he switched to DDG as the default search provider. Nevertheless I tried Google and kept working through 15 (yes, fifteen) captchas in a row and Google still wouldn't let me through, and then I gave up. What the hell? Surely even after 1 captcha, Google should be amply convinced that I'm not a robot and let me did a…

Not just for remote browsers, but even any browser other than Google Chrome it triggers a lot of captchas and even renders a lot of sites hosted behind Cloudflare unusable - which is a lot.

Just try doing a reverse phone number search on truecaller.com. It will work flawlessly on Chrome but use FF or any other browser and recaptcha will fail you saying you're a bot (at least happens to me evey time I've tried). Same for many other sites where you see that "Checking your browser" page.

So even though I want to use FF I can't since most of the web is unusable because of this stupid Recaptcha unlesw you're using Google Chrome :(

Post reply on HN