TL;DR
Modern web applications change constantly. Components are re-rendered, generated attributes may differ between builds. Even when t...
For further actions, you may consider blocking this person and/or reporting abuse
Bypassing fragile DOM selectors by letting the agent infer UI intent is such a cleaner approach for dynamic pages! Have you noticed any trade-offs in execution speed or latency when letting the agent parse the visual layout compared to traditional selector-based automation?
Thanks! Yes, I don't think speed is all that important in testing, but I've noticed that Cursor works quite quickly.
Thanks for clarifying, Anthony! That makes total sense—reliability and avoiding flaky CI/CD pipelines definitely trump raw execution speed for dynamic web apps.
Follow-up question on scaling this approach: as test suites grow to hundreds of scenarios, how do you manage the higher LLM API token costs and inference latency that come with parsing full visual layouts repeatedly compared to lightweight DOM snapshots?
finally someone addressing the brittle selector nightmare lol. does this actually hold up with heavy shadow DOM usage?
ShadowDOM is not too important in this case because it is a browser layer.
finally someone talking about this. brittle selectors are the worst part of automation lol
Downside: token spend, and possibly some added latency ...
If your page's selectors are "known", and aren't brittle, then 'deterministic testing' (e.g. Playwright) still wins - right?
I wrote a chapter called "Where Playwright Still Fits." It has its advantages.
Dom is so un reliable approach for browser automation
What do you think about the article?
Gemini also fits?
Yes.
the inspect → act → reassess loop is exactly what we were missing when we tried wiring Playwright into an MCP tool set. hardcoded selectors are fine until the first deploy that adds a loading skeleton — then every test that assumed
.result-cardwould just be there on load starts flapping.we ended up wrapping Playwright's
page.locatorin a short polling layer that rereads the accessibility tree every 2s before acting. uglier than BrowserAct but solves the same class of failure. tbh i should just swap it out.does BrowserAct expose the page state as structured JSON or is it closer to a visual snapshot?
finally something that doesn't rely on hardcoded css classes. does this work well with shadow dom too?
finally someone addressing the brittle selector nightmare lol. does this actually hold up with heavily shadowed DOMs?