Эволюция: От Selenium к WebDriver BiDi

Updated Jul 2026

Хронология

2004 ──── Selenium 1.0 (JavaScript injection)
   │
2011 ──── Selenium 2.0 / WebDriver (HTTP + JSON)
   │
2017 ──── Chrome DevTools Protocol (CDP) gains traction
   │      Puppeteer launches (CDP-based)
   │
2018 ──── WebDriver becomes W3C standard
   │
2020 ──── Playwright launches (CDP-based, multi-browser)
   │
2021 ──── WebDriver BiDi work begins at W3C
   │
2023 ──── Puppeteer adds BiDi support
   │
2024 ──── Selenium 4 integrates BiDi
   │
2025 ──── Vibium launches (BiDi-native)
   │      Playwright MCP server ships
   │
2026 ──── BiDi ecosystem matures
         CLI + Skills pattern emerges for AI agents

Интересный факт: Vibium создан тем же человеком, который создал Selenium (2004) и Appium (2012).

Эра 1: Selenium и инъекция JavaScript (2004-2011)

Как это работало

Selenium инъектировал JavaScript в браузер для имитации действий пользователя. Java-сервер «Selenium RC» выступал прокси.

Test Script → Selenium RC Server → Injected JS in Browser

Проблемы

• Same-Origin Policy: JavaScript не мог пересекать доменные границы
• Безопасность браузера: Всё больше ограничений на то, что мог делать инъектированный JS
• Хрупкость: Зависимость от внутренних механизмов браузера, которые часто менялись
• Медленность: HTTP-обращения на каждое действие

Эра 2: WebDriver и нативные API браузера (2011-2017)

Как это работало

Каждый производитель браузера предоставлял бинарный «драйвер» (chromedriver, geckodriver), который использовал нативные API браузера для управления им. Коммуникация шла через HTTP + JSON.

Test Script ──HTTP──► ChromeDriver ──Native API──► Chrome

Протокол WebDriver (стандарт W3C, 2018)

POST /session                          → Create session
POST /session/{id}/url                 → Navigate
POST /session/{id}/element             → Find element
POST /session/{id}/element/{id}/click  → Click element
POST /session/{id}/element/{id}/value  → Type text
GET  /session/{id}/screenshot          → Take screenshot
DELETE /session/{id}                   → Close session

Преимущества перед Selenium 1

• Нативное управление: Не нужна инъекция JavaScript
• Кросс-доменность: Нет ограничений same-origin
• Стандартизация: Стандарт W3C, все браузеры его реализуют
• Надёжность: Использование собственных API браузера

Ограничения

• Однонаправленность: Клиент спрашивает, браузер отвечает. Никаких событий.
• Крупнозернистость: Ограничен тем, что определяет спецификация
• Нет реального времени: Невозможно слушать логи консоли, сетевые события и т.д.
• Необходим опрос: Для обнаружения изменений на странице нужно постоянно спрашивать

Эра 3: Chrome DevTools Protocol — CDP (2017-настоящее время)

Как это работало

Chrome открыл свой интерфейс инструментов разработчика как WebSocket API. Puppeteer (Google) и Playwright (Microsoft) построили на этом.

Test Script ──WebSocket──► Chrome (DevTools)

Что CDP дал

// Bidirectional: Browser pushes events
{"method": "Console.messageAdded", "params": {"message": {"text": "error!"}}}

// Network interception
{"method": "Network.requestWillBeSent", "params": {"request": {"url": "..."}}}

// DOM manipulation
{"method": "DOM.getDocument", "params": {}}

// Performance profiling
{"method": "Performance.getMetrics", "params": {}}

Преимущества перед WebDriver

• Двунаправленность: События передаются из браузера клиенту
• Богатство: Сеть, производительность, DOM, покрытие, доступность
• Скорость: WebSocket имеет меньшие накладные расходы, чем HTTP

Проблемы

• Только Chrome: CDP — внутренний протокол Chrome
• Нестабильность: Google может изменить его без предупреждения (он «внутренний»)
• Специфичен для браузера: Playwright пришлось писать отдельные бэкенды для Firefox, WebKit
• Привязка к вендору: Ваши тесты зависят от протокола, контролируемого Google

Обходной путь Playwright

Playwright абстрагирует CDP (Chrome), модифицированный протокол Firefox и протокол отладки WebKit за единым API. Это впечатляющая инженерная работа, но создаёт бремя поддержки — Playwright должен отслеживать внутренние изменения в трёх браузерах.

Эра 4: WebDriver BiDi (2021-настоящее время)

Лучшее из двух миров

Как BiDi решает проблемы CDP

1. Стандартизирован W3C — Производители браузеров обязуются реализовать его
2. Кросс-браузерный по дизайну — Chrome, Firefox, Safari, Edge участвуют
3. Стабильный API-контракт — Изменения проходят через процесс стандартизации
4. Та же мощность, что у CDP — События, сеть, скрипты, ввод

Текущая поддержка браузерами (2026)

Где Vibium вписывается

Vibium нативно построен на BiDi с первого дня. Он не абстрагируется поверх CDP или устаревшего WebDriver — он говорит на BiDi напрямую.

Traditional stack:           Vibium stack:

Test → Playwright → CDP      Test → Vibium → BiDi
       Playwright → Firefox         (same protocol for all browsers)
       Playwright → WebKit

Преимущества

• Нет абстракционных накладных расходов — BiDi — это протокол, а не уровень совместимости
• Защита от устаревания — По мере улучшения BiDi улучшается и Vibium
• Кросс-браузерный потенциал — Когда Safari завершит поддержку BiDi, Vibium будет работать там
• Простота — Один протокол, одна реализация, один бинарник

Компромисс

• BiDi новее, чем CDP — некоторые продвинутые функции (перехват сети, покрытие) ещё стандартизируются
• CDP в Chrome более функционален сегодня — но он не стандартизирован
• Подход Playwright на основе CDP даёт больше функций сейчас ценой зависимости от вендора

Влияние на стратегию автоматизации тестирования

Для архитекторов, выбирающих стек

Конвергенция

Все основные инструменты сходятся к BiDi:

• Selenium 4 добавляет поддержку BiDi
• Puppeteer имеет режим BiDi
• Playwright признаёт BiDi как направление будущего развития
• Vibium нативно построен на BiDi

В течение 2-3 лет BiDi, вероятно, станет доминирующим протоколом, делая спор CDP vs BiDi неактуальным.

Тезис для собеседования

«Автоматизация браузеров прошла через четыре эры. Selenium 1 использовал инъекцию JavaScript, WebDriver добавил нативные API браузера через HTTP, CDP принёс двунаправленную WebSocket-коммуникацию, но был специфичен для Chrome и нестабилен, а теперь WebDriver BiDi объединяет стандартизацию с двунаправленностью. Vibium выбрал строить на BiDi с первого дня, а не абстрагироваться поверх CDP — это означает один протокол, одну реализацию и нативную кросс-браузерную поддержку по мере того, как браузеры завершают свои реализации BiDi. Это тот же создатель, который начал Selenium в 2004 году, теперь строящий на протоколе, который является его преемником. Компромисс в том, что набор функций BiDi всё ещё догоняет CDP в некоторых областях, но траектория стандартов ясна.»