I think this is more of a complement to Selenium, where you can use Selenium to drive the browser to test the UI, with Polly providing recorded back-end responses.
I need to look into it more, but this might address a need we have to make it easy (and quick) for our front-end developers to run our test suite locally during development, without having to spin up anything in the backend or rely on flaky non-Production environments.
EDIT: I am aware there are many other tools that can address this, we just haven't had the time yet to implement them. :)
Yes exactly, that's the idea anyway. Has a few nice features on top such as controlling the network latency and expiring recordings (useful when working on a project supported by a big team).
I still don't get why we do this [mocking http endpoints].
Sure this makes the problem of mocking the server less painful. Well done. But I'd take completely integrated tests over these any day. Sure they're slower but that's more or less irrelevant with feature toggling, staged roll-out and continuous production monitoring.
It's totally possible to completely avoid mocking http endpoints thus making these tools completely obsolete.
In your selenium code, the browser was talking to a database.
But sometimes that database is down, or really slow.
Polly says "browser, don't talk to the database anymore, instead here's what the database said last time".
So, yes, both Selenium and Polly poke DOM elements, but Selenium stops there, where as Polly does that + as well as tricks the browser into going through the whole test without making a real call to the database (assuming it has a previous recording of "what the database said" for that test).
EDIT: I am aware there are many other tools that can address this, we just haven't had the time yet to implement them. :)