I always get nervous when stories about Selenium reach the front page of HN. If at any point in the past Selenium has kicked your dog, please accept my apologies.
Why is that? I've done pretty extensive work using Selenium; it's finicky and sometimes too limited for what I need it to do, but I haven't found serious reason to hate it. Documentation's good, it's exceptions are pretty easy to understand, and it does what it says on the tin without much in the way of surprises or drama. It's usefulness has far outweighed any irritation it might have caused me.
Only thing I'd wish for right now is more robust handling for the frequent StaleElementExceptions that can crop up, but it's not too much pain to work around those yourself IMO.
On the contrary, I find myself wishing for the transparency and simplicity of Selenium bindings when I work with other (newer) tools... especially tools that hijack control flow and promises. Protractor, Cypress, etc.
It injects its testing code into the webpage via an http reverse proxy which means it doesn't require internal access to the browser and thus works for unmodified remote mobiles for example. One can simply get a URL that any browser can go to & start executing the tests. Many of the issues with using WebDriver or DevTools seem to be avoided.
Another part of the architecture I've found really useful is that test scripts execute in a nodejs environment outside the browser sandbox and thus have the ability to run external programs, make their own API calls, and so on.
Not completely related to the article in question but I have to say that after years of trying many browser testing solutions, Cypress is the first one I have used which actually works the way I want it to and isn't a total PITA to use on a day-to-day basis. I don't have to hack workarounds to common use cases and for some reason they seem have the first implementation of this idea which achieves this. I understand that Selenium is a mature technology but man, it has caused so much pain to be over the years despite the many wrappers around it which have endeavoured to make it ergonomic.
"The program does not continue until the remote end receives the corresponding HTTP response. In the initial browser.go call, for example, the remote end will only send its response once the browser has finished loading the requested page."
I think this should read "until the remote end SENDS the corresponding HTTP response", or "until the LOCAL end receives the corresponding HTTP response."