Playwright و Selenium هر دو مرورگر را برای اتوماسیون کنترل می‌کنند — در تست E2E و در استخراج سایت JavaScript. تفاوت در API، پایداری wait و هزینه نگهداری است؛ نه «همیشه یکی برنده».
- پروژه سبز + SPA → اغلب Playwright سریع‌تر به نتیجه می‌رسد.
- سازمان با Grid Selenium → migration تدریجی، نه الزام یک‌شبه.
- صفحه استاتیک → نه Playwright نه Selenium؛ Requests ارزان‌تر است.
هر دو چه هستند؟
Selenium WebDriver استاندارد قدیمی: driver جدا (مثلاً ChromeDriver) پروتکل W3C را صدا می‌زند. Playwright از Microsoft: مرورگر bundled، API یکپارچه، auto-wait پیش‌فرض.
| موضوع | Playwright | Selenium |
|---|---|---|
| Auto-wait | قوی، پیش‌فرض | اغلب explicit wait دستی |
| مرورگر | Chromium/Firefox/WebKit یکجا | Chrome/Firefox via driver |
| Network intercept | بله، راحت | محدودتر |
| Context جدا | new_context() ساده | profile/incognito قابل تنظیم |
| Parallel | چند context در یک browser | Grid سازمانی رایج |
| اکوسیستم | در حال رشد | بسیار بزرگ، legacy زیاد |
Scraping در برابر testing
هر دو برای تست نوشته شده‌اند؛ scrape یعنی همان ابزار با هدف extract و SLA متفاوت (حجم، rate limit).
سناریو: پروژه استخراج JS از امروز
تیم کوچک، بدون Grid موجود → Playwright معمولاً سریع‌تر به نتیجه می‌رسد. سازمان با صدها تست Selenium روی Grid → migration تدریجی؛ scrape جدید می‌تواند Playwright باشد در کنار legacy.
Legacy
کد Selenium سال‌ها جریان دارد؛ rewrite هزینه دارد. اگر فقط ۳ flow scrape دارید، migration محدود منطقی است.
صفحه استاتیک هنوز با Requests ارزان‌تر است — مرورگر را برای همه URL باز نکنید.
در عمل چه انتخابی کنیم؟
پروژه سبز + SPA → Playwright. قرارداد Grid/سازمان روی WebDriver → Selenium تا زمان migration. در هر دو: wait واقعی، pool محدود، مدیریت خطا. Pillar: وب‌اسکرپینگ.