I could see this being part of a lightweight browser UI testing framework.
There's already ways to drive a headless UI (Selenium, puppeteer), but they require automation testers to interact with page elements via the "normal" DOM which can be quite painful in terms of creating automation tests - DSLs to drive DOM automation are necessarily huge.
I could envision browser automation via browsh using a very small DSL e.g. browsh.url() to navigate to a URL, browsh.click() to click on an element, browsh.text_exists?() to check whether text exists, browsh.link_exists?() to check whether a clickable link exists
I've thought of that too. The trouble is that Browsh's text renderer is more of a science than an art. It's quite hard to actually get a guarantee of the same text twice, which is a pretty important condition of testing.
But yes, I'd love for Browsh to be used in such a way!
As an anecdote, somebody at my workplace has just spent a day tearing their hair out trying to figure out how to get our selenium tests running automatically on a headless machine, because the resolution flat refused to go above 1024x768. Even then, they're slow and heavyweight.
A very fast browser not tied to a graphical display with the bonus of being able to put error screenshots into all of our existing tooling could actually be quite beneficial here, whether the text is character-identical every time or not.
Guaranteeing the same text twice might not be so important. There are pixel comparison testing tools for popular browsers. Your advantage is probably speed. Would cypress end-to-end tests run way faster in Browsh than in a graphical browser? If so, you've got something of value to big companies. You might want to partner with or contract for Cypress.
EDIT: Since Browsh depends on Firefox I'm curious whether it's actually faster than a graphical browser.
There's already ways to drive a headless UI (Selenium, puppeteer), but they require automation testers to interact with page elements via the "normal" DOM which can be quite painful in terms of creating automation tests - DSLs to drive DOM automation are necessarily huge.
I could envision browser automation via browsh using a very small DSL e.g. browsh.url() to navigate to a URL, browsh.click() to click on an element, browsh.text_exists?() to check whether text exists, browsh.link_exists?() to check whether a clickable link exists