The project is a modern text browser that supports CSS, Javascript and WebGL. if it was just text it wouldn't fulfill those requirements. and given it's targeting those, why would you choose to entirely re-implement the browser when you can use existing technology in a headless manner to handle the backend for you?
I mean, I think there's an argument to be made that at this point it's not a text-based browser in the classic sense, so much as an ASCII art frontend for a regular browser.
A text-based browser in the traditional sense explicitly wouldn't care about JS and WebGL, but may implement some CSS and image rendering via ASCII art.
To be clear: I don't understand the benefit of brow.sh over basically anything else on the market besides looking l33t to non-techie passers-by. It still chews up bandwidth and system resources pulling down and running JS, which also has privacy implications. Limiting JS support was a big selling point of Lynx for lots of people.
> text-based browser in the classic sense, so much as an ASCII art frontend
is ASCII art not text based?
> A text-based browser in the traditional sense explicitly wouldn't care about JS and WebGL
I guess that's the difference between "traditional" and "modern"? the whole point of doing something different is to stray away from the traditional
> I don't understand the benefit of brow.sh over basically anything else
I don't know if this is exactly how brow.sh works, but if it does its a use case for me. In my case, I have some remote machines whose IPs are whitelisted for certain third party vendors. These vendors have web portals we can access, but only on those machines. If I could use this to proxy through and be able to hit those web portals through those machines, it would be useful for me
ASCII is, but this isn't text-based. It's Firefox Quantum based, and then it probably downsamples graphics to represent them as ASCII while also scraping text.
It's very much just a text-based frontend, not a text-based browser, for a regular browser.
In hindsight this might not _literally_ use ASCII art, but hopefully the point gets across.
>the whole point of doing something different is to stray away from the traditional
Sure, but I genuinely see the value prop for brow.sh. It's strictly heavier than Firefox assuming it offloads the JS execution and at least some of the rendering to headless Firefox.
RE: your use case, why not just set up transparent HTTP proxies that enforce whitelists on those hosts? That's a much less cumbersome solution.
13 comments
[ 3.4 ms ] story [ 43.2 ms ] threadA text-based browser in the traditional sense explicitly wouldn't care about JS and WebGL, but may implement some CSS and image rendering via ASCII art.
To be clear: I don't understand the benefit of brow.sh over basically anything else on the market besides looking l33t to non-techie passers-by. It still chews up bandwidth and system resources pulling down and running JS, which also has privacy implications. Limiting JS support was a big selling point of Lynx for lots of people.
is ASCII art not text based?
> A text-based browser in the traditional sense explicitly wouldn't care about JS and WebGL
I guess that's the difference between "traditional" and "modern"? the whole point of doing something different is to stray away from the traditional
> I don't understand the benefit of brow.sh over basically anything else
I don't know if this is exactly how brow.sh works, but if it does its a use case for me. In my case, I have some remote machines whose IPs are whitelisted for certain third party vendors. These vendors have web portals we can access, but only on those machines. If I could use this to proxy through and be able to hit those web portals through those machines, it would be useful for me
ASCII is, but this isn't text-based. It's Firefox Quantum based, and then it probably downsamples graphics to represent them as ASCII while also scraping text.
It's very much just a text-based frontend, not a text-based browser, for a regular browser.
In hindsight this might not _literally_ use ASCII art, but hopefully the point gets across.
>the whole point of doing something different is to stray away from the traditional
Sure, but I genuinely see the value prop for brow.sh. It's strictly heavier than Firefox assuming it offloads the JS execution and at least some of the rendering to headless Firefox.
RE: your use case, why not just set up transparent HTTP proxies that enforce whitelists on those hosts? That's a much less cumbersome solution.
Also, it doesn't handle terminal shutdown; it leaves Firefox running but won't reconnect if you open up a new terminal and try to run it again.
Overall, unusable at this time, imo.