Could you share why it misses the point according to you?

On the website the following use-case is mentioned: > run firefox remotely in order to "significantly reduce bandwidth and thus both increase browsing speeds and decrease bandwidth costs."

Another use-case would be running firefox on a remote server with just enough power while using ssh on a smaller, weaker, device (raspbery pi like, an old smartphone with termux, very old hardware, ...).

It's hard to build a browser engine, especially if you intend to support a seemless modern web experience (and thus with javascript, unlike all the text-browsers out there). Some even argue it's not possible to build a modern web browser engine anymore [1].

I think it's the point for browsh to rely on another piece of software that will focus on just that (headless firefox).

Browsh is described as a "text-based browser", but under the hood, a more technical accurate way to summarize it would be "a software to stream a remote firefox in your terminal". The concept (and why it saves bandwitch) is detailed on the docs section "What is browsh?" [2].

[1] https://drewdevault.com/2020/03/18/Reckless-limitless-scope.... [2] https://www.brow.sh/docs/introduction/

edbrowse supports enough js to comment on some pages and download files. Felinks used to work, too.

Are you projecting? The point is to be able to use the modern web in all of its spectacular complexity, from within a text-based terminal. Which goal it actually achieves!

It's neat yes. But prevents it being used on a headless server without graphics installed. That's primarily where I'd use a text browser... need to download a package/archive but also need to search for it first.

If I have firefox installed, I'd just use it!

This can, however, be run entirely inside of Docker - something I’ve done numerous times on a remote sever. This even allows for the web interface to be used, though that kind of defeats the purpose.