Client Implementation Parity

## The five official clients At **Selenium 4** the Selenium project itself maintains and releases client bindings for exactly five languages: - **Java**, published as the `org.seleniumhq.selenium` artifacts; - **Python**, published as the `selenium` package; - **C#/.NET**, published as the `Selenium.WebDriver` package; - **Ruby**, published as the `selenium-webdriver` gem; - **JavaScript**, published as the `selenium-webdriver` npm package. These five are released together from the same source repository, so a given Selenium version number means the same set of features in each of them. A team automating a **veterinary appointment book** can therefore pick whichever of the five matches the language its engineers already write, and expect the same commands to be available. ## What "official" actually buys you - **Lock-step releases.** When the project ships a version, all five bindings get it, so a newly standardised command or capability appears everywhere at once. - **Project support.** Issues, documentation and examples on the Selenium site cover these five; the code samples in the official docs are written in all of them. - **Consistent coverage of the standard.** Each official binding aims to expose the full W3C WebDriver command set rather than a convenient subset. ## Community bindings and where they sit Beyond the five, engineers have written **community bindings** — clients maintained outside the Selenium project, for languages such as PHP, R, Rust, Perl and Go. They are not second-class in principle: because the protocol is a published standard, a community client sends the same requests to the same driver executables and can drive the same browsers and the same self-hosted Grid. What makes them different is stewardship, not capability. | | Official binding | Community binding | |---|---|---| | Maintained by | the Selenium project | independent authors | | Release cadence | with each Selenium release | its own schedule | | Protocol spoken | W3C WebDriver | W3C WebDriver | | Drivers it can use | the standard driver executables | the same executables | | Covered by project docs and support | yes | no | ## What stays the same either way The browser end never knows which client called it. That has three consequences worth stating plainly: 1. **Locators port.** A CSS selector or XPath that finds the appointment grid is evaluated by the browser, so it behaves the same from any client. 2. **Capabilities port.** The key names in the session request are JSON members defined by the standard, not identifiers in your language. 3. **Failures port.** The remote end names a failure with the same string code no matter who asked, so a `no such element` in one language is a `no such element` in another. ## What an interviewer is checking This is a screening question, and the weak answer is a bare list. The stronger answer names the five, then adds the distinction that actually matters day to day: the official five are the ones the project ships and supports, community bindings exist and are legitimate, and every one of them — official or not — is a client of the same protocol rather than a separate automation tool. A candidate who says "Selenium is a Java tool with wrappers for other languages" has the model backwards, and that misconception shows up later as designs that assume Java-only helpers are available everywhere.