POM puts page-specific locators and services in one class so a UI change is fixed in one place. Selenium's guidance is that page objects offer the page's services, should not hold assertions apart from a page-loaded check, and can be composed from smaller component objects. Screenplay models tests as actors with abilities who perform tasks and interactions, using domain language, and its advocates position it as a way to keep code reuse high as suites grow and to test through several interfaces (UI and API) with one design. POM tends to strain when page classes bloat, when the same workflow spans many pages, or when tests mix UI and API steps; component objects solve part of that. For a small suite, POM is enough; consider Screenplay when the team wants business-readable scenarios and reuse across UI, API and mobile.

In TypeScript, a component object can keep its selectors in a typed, read-only map, so a misspelled selector name fails at compile time instead of at run time:

import type { Page } from '@playwright/test';

const selectors = {
  profileLink: '[data-testid="nav-profile"]',
  settingsBtn: '[data-testid="nav-settings"]',
} as const;

export class NavigationComponent {
  constructor(private readonly page: Page) {}

  async goToSettings() {
    await this.page.locator(selectors.settingsBtn).click();
  }
}

Page classes are then composed from components such as NavigationComponent and HeaderComponent instead of growing into one large file.

Sources: Selenium docs, Serenity/JS handbook