This is a very cool project. It uses headless firefox and then renders to the terminal. Text remains text, and then videos and images get projected to super low res bitmap-via-characters in real time.
Interesting. I use w3m inside Emacs for most of my web-browsing, and am posting from it now. I do hate having to switch to Brave for so many sites these days (though it's been a good motivator to avoid those sites). I'll definitely give this a try to see if it can help close the gap. I especially hate how most of the sensitive stuff you might want to use the web for involving PII or money requires the more insecure client.
They haven't had a new release in over 3 years, and the program stopped working for me a long time ago. I start it up using the exact docker command they provide, then press Ctrl+L to go to the address bar, type in www.google.com and it just says Loading forever, nothing ever happens.
Now that I'm running a terminal (wez) that upports sixel I'm always hoping to find more apps that support it. Looks like this one doesn't although it might be a good way of rendering the graphics.
Because the desire for a leaner, unbloated browser or a browser that can 'run' JavaScript in the terminal still exists so this project floats up pretty regularly.
> Opera Mini was derived from the Opera web browser. Opera Mini requests web pages through Opera Software's compression proxy server. The compression server processes and compresses requested web pages before sending them to the mobile phone. The compression ratio is 90% and the transfer speed is increased by two to three times as a result. The pre-processing increases compatibility with web pages not designed for mobile phones. However, interactive sites which depend upon the device processing JavaScript do not work properly.
This looks interesting. It's probably also worth investigating ways for website owners to make pages that are easy for this engine to render as text while preserving as much of the page's structure as possible.
> Its main purpose is to be run on a remote server and accessed via SSH/Mosh or the in-browser HTML service in order to significantly reduce bandwidth and thus both increase browsing speeds and decrease bandwidth costs.
Um, if it is loading the exact same pages as a Chromium browser and then just streaming the site by converting it to a terminal, it will not improve speeds nor decrease bandwidth costs (maybe the cost from the remote server to the client, but not on the remote server).
If you are using a VPS to connect to the internet it will usually be much faster than most non-fiber residential internet connections. Transmitting the text based result over SSH should be much quicker on a slow connection than a full browser on a client on that same slow connection (as a browser would render things much more detailed).
> [will not] decrease bandwidth costs
I would imagine the bandwidth limits and speeds provided on a $5/month server with DigitalOcean or [insert other VPS provider] is much, much cheaper in most cases than an ISP's rate.
DigitalOcean's smallest servers include 1,000 GB of upload and download and each 1,000 GB over the limit is $10[1]. That's a ton of bandwidth for how cheap that is.
