A comparison repository has to choose how many things to compare. Too few and there is no contrast; too many and every scenario must be written several more times, the coverage gaps multiply, and the repository becomes a museum of half-finished stacks — which teaches the opposite of the intended lesson.
Three audiences were worth serving: the maintainer inheriting a legacy Selenium suite, the engineer learning the modern default, and the Python team that cannot adopt a Node-only toolchain. Each additional stack costs a full implementation of every scenario it claims, forever.
Maintain exactly three tracks, each with its own toolchain, dependency manifest, and README, sharing no code:
| Track | Serves |
|---|---|
| Java Selenium/TestNG | The legacy-maintainer audience |
| TypeScript Playwright | The modern flagship |
| Python Playwright | Teams whose language is Python |
Treat Cypress and WebdriverIO as comparison topics only, documented but not
implemented, for the reasons recorded in
../framework-comparison.md: Cypress would add a
fourth overlapping browser stack, and WebdriverIO has low marginal teaching value
once Selenium and Playwright are both present. Argue their tradeoffs in prose
rather than paying their maintenance cost in tests.
Deliberately do not extract a shared abstraction layer across the three tracks. The differences between them are the subject matter; hiding those differences behind a common wrapper would destroy the thing being taught.