Show HN: Cloud browser – headless Chrome and image maps
21–30 of 34 posts
Re: Show HN: Cloud browser – headless Chrome and image maps
#22Re: Show HN: Cloud browser – headless Chrome and image maps
#23What if it sent a DOM string instead of a picture?
The client would need some js, but mostly just click and input handlers. All the heavy JS runs server-side.
One could use v-dom diffing and only send updates to the client to reduce bandwidth.
But that is getting complicated. I really appreciate the simplicity and elegance of using image maps.
Re: Show HN: Cloud browser – headless Chrome and image maps
#24Hello Hacker News, I made this as a quick weekend project after getting inspired by Ian Bicking's _The Firefox Experiments I Would Have Liked To Try_ submission last week, discussed at https://news.ycombinator.com/item?id=19304802 . Specifically, the "cloud browser" concept. Also partly inspired by https://html.brow.sh/ , but as a text-based browser browsh is much more limited than Cloud Browser. https://cloudbrowser…
Wow! When I saw "image map" on the title I thought this can't actually be talking about the HTML image map. Image map reminds me of HTML from the late 90s, and give me a good nostalgia of making personal homepages from that time. With invisible clickable divs, absolute positioning css and what not, it seems like image map has become a thing of the past. I'm guessing the requirement of making it work with no JS took y…
An absolutely positioned CSS div is an interesting idea, if I recall correctly I actually tried this first, but ran into various problems (with scaling as the page is zoomed in/out, I think) and the image map worked perfectly. area shape="rect" works well as it translates directly from puppeteer's await page $$('a') boundingBox().
Re: Show HN: Cloud browser – headless Chrome and image maps
#25Hello Hacker News, I made this as a quick weekend project after getting inspired by Ian Bicking's _The Firefox Experiments I Would Have Liked To Try_ submission last week, discussed at https://news.ycombinator.com/item?id=19304802 . Specifically, the "cloud browser" concept. Also partly inspired by https://html.brow.sh/ , but as a text-based browser browsh is much more limited than Cloud Browser. https://cloudbrowser…
Firstly: nifty idea, and neat prototype of said idea. :thumbs up: Second: If my cloud browser has all of my credentials, do I care that my cloud browser is the process that’s pwned instead of my local browser? I think I don’t, so the main benefit would seem to be something like “view a certain static-ish subset of JS-required websites on a device that can’t/won’t run JS”.
That was essentially my envisioned use case, as well. Not only for devices that won't run JS but those where you might not want to. For example, a lot of news websites are surprisingly JavaScript heavy, slow and buggy, not something I necessarily want to run if I merely want to read what the news is talking about. Public read-only sites. Granted, arguably services like outline.com and archive.is already cover this use case better.
As for sites requiring credentials, the way I see it users could run the cloud browser on their own server. This has benefits even for public sites, adding additional privacy. However it is not something this Cloud Browser really supports yet, since there is no support for forms, text fields, or other interactivity with the exception of hyperlinks.
Re: Show HN: Cloud browser – headless Chrome and image maps
#26Hello Hacker News, I made this as a quick weekend project after getting inspired by Ian Bicking's _The Firefox Experiments I Would Have Liked To Try_ submission last week, discussed at https://news.ycombinator.com/item?id=19304802 . Specifically, the "cloud browser" concept. Also partly inspired by https://html.brow.sh/ , but as a text-based browser browsh is much more limited than Cloud Browser. https://cloudbrowser…
Interesting. As the next step for automated testing, browsing on the cloud browser images can be automated with the kantu browser extension and its image and text recognition features https://a9t9.com/kantu/docs/xclick
It also points out a significant limitation of Cloud Browser's imagemap-based architecture. Screenshotting the page locks away the text behind an image, inaccessible to screen readers, copy and paste, or other interactions. This doesn't seem easy to solve, since the most the img tag offers for accessibility is an "alt" tag, which does not allow specifying which areas of the image contain what text. Sending the actual text (like html.brow.sh) would solve this problem, but then layout is up to the end-user browser again.
Client-side OCR'ing of the image may be a possible alternative, will look into it thanks!
Re: Show HN: Cloud browser – headless Chrome and image maps
#27Hello Hacker News, I made this as a quick weekend project after getting inspired by Ian Bicking's _The Firefox Experiments I Would Have Liked To Try_ submission last week, discussed at https://news.ycombinator.com/item?id=19304802 . Specifically, the "cloud browser" concept. Also partly inspired by https://html.brow.sh/ , but as a text-based browser browsh is much more limited than Cloud Browser. https://cloudbrowser…
I made a similar attempt at this a couple years ago, to allow browsing the (JavaScript) web with JavaScript disabled. It works by proxying all traffic through a headless Chrome instance... but a screenshot + an image map is even better. https://chrome.google.com/webstore/detail/prerendercloud-dis... https://www.prerender.cloud/
If you want to borrow the image map idea, feel free :). I'm not planning on developing cloudbrowser.website much further, moving onto other projects, but maybe I'll be a customer.
Re: Show HN: Cloud browser – headless Chrome and image maps
#28Hello Hacker News, I made this as a quick weekend project after getting inspired by Ian Bicking's _The Firefox Experiments I Would Have Liked To Try_ submission last week, discussed at https://news.ycombinator.com/item?id=19304802 . Specifically, the "cloud browser" concept. Also partly inspired by https://html.brow.sh/ , but as a text-based browser browsh is much more limited than Cloud Browser. https://cloudbrowser…
This is a fun experiment, but I cannot see the long-term advantage of what you are doing vs VNC (or similar) on the web. I'm pretty sure it would take less effort and give better results if you just hooked the viewer to something like a guacamole [1] session tethering you to a remote browser. http://guacamole.apache.org/
Looking into it more, maybe noVNC or Guacamole, with VNC or RDP, tethered to a remote browser instance. This would solve the problem of user interaction with the web page, which is currently very limited with Cloud Browser's image maps (hyperlinks only). On the other hand it would increase the end-user browser requirements (image maps date back to HTML 3.2! https://en.wikipedia.org/wiki/Image_map), but still not run the target website's content, so it could be worthwhile and most browsers actively in use now support HTML5.
Re: Show HN: Cloud browser – headless Chrome and image maps
#29Hello Hacker News, I made this as a quick weekend project after getting inspired by Ian Bicking's _The Firefox Experiments I Would Have Liked To Try_ submission last week, discussed at https://news.ycombinator.com/item?id=19304802 . Specifically, the "cloud browser" concept. Also partly inspired by https://html.brow.sh/ , but as a text-based browser browsh is much more limited than Cloud Browser. https://cloudbrowser…
Seems like both the demo and the static mirror are down or suffering from HN hug
Unfortunately, I'm only hosting the demo on a quad-core 6GB VPS, which frequently runs out of memory. There is a known issue (https://gitlab.com/epitactic/cloudbrowser/issues/2) where old Chrome processes are not cleaned up for some reason. I've restarted the VPS, should be available again for now, for at least a while.
Re: Show HN: Cloud browser – headless Chrome and image maps
#30Doing this via images seems... backwards. It's crazy bandwidth-intensive and almost never suits the client. There are other raster-options (SVG would be lighter on bandwidth) but they still don't scale. So why not just sanitise the DOM? Embed images. Remove script before sending. Add an event listener to send all events back to your server. User clicks, your server emulates and sends back a DOM diff. You'd need to do…
Another inspiration is image boards such as 4chan, where screenshots are a very common means of sharing information, including articles on websites, or even tweets. Even though it may not be technically ideal, and annotated text seems like it would be more efficient, in practice images as the lowest-common-denominator seem to be a reasonably effective format for sharing information.
On the other hand, if someone does come up with a true "browser in browser" implementation like you propose, I would be very interested in trying it out. Could be a promising idea, but a lot of work to get right.