Comment by epitactic | Hacker News Reader

Comment by epitactic | Hacker News Reader

Parent Full thread

Hello 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.website/ runs a headless Google Chrome instance on a VPS, loading a website and taking a screenshot using NodeJS puppeteer. The links are iterated to create an image map, so you can browse (many) websites as normal, but through the cloud. Not all websites work yet, but many do.

Why is this useful? While this is only a simple prototype, it is an experiment in a new way to browse the web which I believe shows promise. Websites have become increasingly complex, heavy on JavaScript and HTML5 features. Cloud Browser pushes this complexity to the cloud, so you can browse websites requiring JavaScript without enabling JavaScript on your end-user browser, for example.

It is still in its incipient stages, but I welcome any feedback/suggestions on how to expand and refine this concept, or better yet, code contributions ;) feel free to fork on GitLab.

Source code: https://gitlab.com/epitactic/cloudbrowser/

Live demo of Cloud Browser loading Hacker News: http://cloudbrowser.website/b/https://news.ycombinator.com/

Static mirror if the VPS is down: https://epitactic.gitlab.io/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 you to the path of using image maps. Neat technique.

I always thought the map element was an underutilized feature. When I was a kid I really enjoyed glorified mazes like the Bone Garden Estate, which inspired me to make my own stateless "games" using MSPaint and HTML.

It didn't really teach me anything about programming, but it seemed like such a novel thing to put hyperlinks on parts of images.

https://web.archive.org/web/20010301200926/http://www.bonega...

Just want to say thanks for bringing this to my attention. I really want to go through it! I was also very surprised the sound effect still works using the <embed> tag!

In retrospect, it's not very good. lol! But when I was 10 years old, the idea of a virtual haunted house(and being able to inspect the HTML) was really cool. I suppose it's one of the things that inspired me to become the web developer I am today.

Indeed, image maps seemed to be the simplest way to implement this, fitting into my goal of reducing the complexity of the content rendered on the web client. I still use CSS, but only in one place (for showing the cached timestamp in the corner). Technically I do use JavaScript, although only for getting the window dimensions, and it is optional.

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

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”.

Thanks!

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.

What if this service had been set up that you pay for it and when you do so you get an virtual server instance automatically set up. From a security perspective you are running a own virtual private server isolated from the company that provides the software. From a usability point of view everything is spun up via some clever scripts, so you don't have to go through the hazzle of configuring the VPS.

I've been toying with this configuration and think it might be usable for some opensource projects.

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

Thanks for the link, this Kantu XClick and XMove image-driven "real user simulation" project opens up some interesting possibilities.

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!

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/

Nice job with prerender.cloud! This looks like about the idea I had, but you took it a lot further, beyond the prototype stage into an actual product.

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.

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/

This is a good point, honestly I didn't consider it, or know of Guacamole but I agree it could be a better solution.

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.

I'm doing a lot of rather JS-calculation heavy projects. Then again a lot of this is leveraging canvases, how well would this approach with that sort of dynamic content.

I'd try for myself, but as I take it you are not doing this on a production scale the HN effect produces a lot of out error messages so I can't really see for my self.

Seems like both the demo and the static mirror are down or suffering from HN hug

The static mirror https://epitactic.gitlab.io/cloudbrowser/ is just a static HTML page + image hosted on GitLab Pages, so it should always be up, but the links there go back to the online demo which was down.

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.

Reply on news.ycombinator.com