LW IT Solutions
« Przegląd bloga /Tworzenie stron internetowych / Vanilla JavaScript i natywne API DOM jako...
Ten artykuł w innych językach:

Vanilla JavaScript i natywne API DOM jako alternatywa dla Reacta i innych frameworków

Vanilla JavaScript i natywne API DOM jako alternatywa dla Reacta i innych frameworków
Spis treści
  1. Vanilla JavaScript i natywne API DOM jako alternatywa dla Reacta i innych frameworków
  2. 1. Koszt wydajnościowy wirtualnego DOM i nadmiaru kodu JavaScript
  3. 2. Natywne interfejsy DOM oraz Web Components
  4. 3. Maksymalizacja wskaźników Core Web Vitals dzięki architekturze Zero-Dependency
  5. Podsumowanie
  6. Pytania i odpowiedzi
  7. Źródła

Vanilla JavaScript i natywne API DOM jako alternatywa dla Reacta i innych frameworków

Współczesna architektura frontendowa często automatycznie opiera się na złożonych frameworkach Single-Page Application (SPA), takich jak React, Angular czy Vue, nawet w przypadku prostych interfejsów i modułowych narzędzi SaaS. Jednak obciążenie generowane przez wielokilobajtowe paczki kodu, algorytmy porządkujące wirtualny DOM oraz zasobochołonną hydratację JavaScriptu bezpośrednio obniża wskaźniki Core Web Vitals – w szczególności Interaction to Next Paint (INP) oraz Largest Contentful Paint (LCP). Nowoczesne przeglądarki oferują natywne interfejsy DOM oraz Web Components, które sprawiają, że ciężkie frameworki stają się technicznie zbędne w pragmatycznej, wydajnej inżynierii internetowej.

1. Koszt wydajnościowy wirtualnego DOM i nadmiaru kodu JavaScript

Frameworki wykorzystują warstwę abstrakcji zwaną wirtualnym DOM (Virtual DOM) do grupowania i obliczania zmian w układzie przed nałożeniem ich na rzeczywisty Document Object Model. O ile w przeszłości rozwiązanie to niwelowało powolną pracą silników renderujących, o tyle współczesne potoki przeglądarek przetwarzają bezpośrednie manipulacje DOM z wyjątkową prędkością. Wprowadzenie wirtualnego pośrednika niesie ze sobą wymierne wady:

  • Narzut na pamięć i procesor: Utrzymywanie zduplikowanych drzew struktur w pamięci operacyjnej zmusza silnik JavaScript do wykonywania obciążających pętli weryfikacyjnych przy każdej zmianie stanu.
  • Blokowanie głównego wątku: Parsowanie rozbudowanych skryptów oraz hydratacja po stronie klienta blokują główny wątek przeglądarki, co opóźnia interaktywność stron i pogarsza wyniki INP na urządzeniach mobilnych.
Po lewej łańcuch frameworka: pakiet skryptów, hydratacja i Virtual DOM z gorszym INP i późniejszym LCP; po prawej natywne elementy jak Custom Elements, Shadow DOM, template, delegacja zdarzeń i querySelector. Na dole reguła z CustomStatusBadge: stałe znaczniki w innerHTML, className dla wariantu, textContent dla tekstu.
Ile kosztuje warstwa frameworka, jakie natywne API przeglądarki ją zastępują i reguła z przykładu CustomStatusBadge, by nie wstawiać wartości do innerHTML.

2. Natywne interfejsy DOM oraz Web Components

Specyfikacja ECMAScript oraz współczesne silniki przeglądarek natywnie udostępniają funkcjonalności, które w przeszłości wymagały instalacji zewnętrznych bibliotek. Projektowanie interfejsów w czystym Vanilla JavaScript pozwala na bezpośrednie wykorzystanie stabilnych standardów internetowych:

  • Custom Elements i Shadow DOM: Natywne Web Components umożliwiają hermetyzację struktury HTML, stylów CSS i logiki interaktywnej w wielokrotnego użytku znaczniki bez zewnętrznych zależności i etapów kompilacji.
  • Znaczniki HTML <template>: Natywne dla przeglądarki klonowanie fragmentów DOM wykonuje się natychmiastowo, eliminując potrzebę transpilacji JSX lub stosowania silników szablonów po stronie klienta.
  • Delegacja zdarzeń (Event Delegation): Podpinanie zunifikowanych nasłuchiwaczy do kontenerów nadrzędnych zmniejsza liczbę nasłuchiwaczy i eliminuje potrzebę ich dodawania lub usuwania przy dodawaniu i usuwaniu elementów potomnych.
// Przykład: Pragmatyczny komponent UI ze stałymi znacznikami w innerHTML i textContent (light DOM, bez Shadow DOM)
class CustomStatusBadge extends HTMLElement {
  connectedCallback() {
    const status = this.getAttribute('data-status') || 'idle';
    this.innerHTML = `
      <span class="badge">
        <span class="dot"></span> Status: <span class="label"></span>
      </span>
    `;
    this.firstElementChild.className = `badge badge-${status}`;
    this.querySelector('.label').textContent = status.toUpperCase();
  }
}
customElements.define('status-badge', CustomStatusBadge);

3. Maksymalizacja wskaźników Core Web Vitals dzięki architekturze Zero-Dependency

Pragmatyczna inżynieria stawia szybkość dostarczania treści oraz deterministyczne wykonywanie kodu ponad warstwy abstrakcji frameworków. Całkowity brak wielokilobajtowych bibliotek obcych producentów sprawia, że strona jest parsowana i gotowa do interakcji natychmiast po pobraniu dokumentu HTML. Połączenie natywnych selektorów DOM (querySelector), siatek CSS Grid oraz kontrolerów w czystym Vanilla JavaScript pozwala tworzyć responsywne, łatwe w utrzymaniu interfejsy SaaS osiągające doskonałe wyniki Core Web Vitals bez komplikowania architektury.

Podsumowanie

Nowoczesne silniki przeglądarek nie wymagają już ciężkich frameworków JavaScript do budowy responsywnych i łatwych w utrzymaniu interfejsów użytkownika. Oparcie architektury na czystym Vanilla JavaScript, natywnych Web Components oraz bezpośrednich manipulacjach DOM eliminuje nadmiar kodu, zapobiega blokowaniu głównego wątku i gwarantuje najwyższe wskaźniki Core Web Vitals na wszystkich urządzeniach.

Pytania i odpowiedzi

Czy pole formularza umieszczone w Shadow DOM bierze udział w wysyłce formularza, w którym stoi element?

Samo z siebie nie bierze. Pole wewnątrz Shadow DOM nie trafia do wysyłki zewnętrznego formularza – granica cienia zatrzymuje nie tylko style, ale i tę zależność.

Rozwiązaniem jest element powiązany z formularzem: static formAssociated = true plus ElementInternals i jawne ustawianie wartości przez setFormValue. To jest ta część, którą pomija wiele poradników o Web Components, a bez niej komponent wygląda poprawnie i po cichu gubi dane przy wysyłce.

Z dostępnością jest podobnie: role, etykiety i powiązania trzeba ustawić samodzielnie, bo domyślnej semantyki nie ma. Oba te koszty przemawiają za podejściem z przykładu w artykule, który renderuje zawartość w zwykłym DOM: dla prostego komponentu to rozwiązanie rozsądniejsze, a Shadow DOM zwraca się dopiero tam, gdzie ten sam komponent ma działać w wielu miejscach o nieprzewidywalnych stylach.

Źródła

Lukas Wójcik

Lukas Wójcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

Napisanie komentarza

Przypadki brzegowe pominięte w artykule i pytania o kod są tu mile widziane.

Adres e-mail nie jest publikowany. Pola obowiązkowe oznaczono gwiazdką.

Artykuły i kategorie

CCTV

Śledź tę kategorię przez RSS

Cloud & AI

Wszystkie artykuły w tej kategorii (17) Śledź tę kategorię przez RSS

Data Privacy

Wszystkie artykuły w tej kategorii (19) Śledź tę kategorię przez RSS

Digital Analytics

Wszystkie artykuły w tej kategorii (58) Śledź tę kategorię przez RSS

Digital Marketing

Wszystkie artykuły w tej kategorii (37) Śledź tę kategorię przez RSS

IT & Networks

Wszystkie artykuły w tej kategorii (18) Śledź tę kategorię przez RSS

Music Production

Wszystkie artykuły w tej kategorii (17) Śledź tę kategorię przez RSS

Raspberry Pi

Śledź tę kategorię przez RSS

SaaS & Internet Earning

Śledź tę kategorię przez RSS

Smart Home

Wszystkie artykuły w tej kategorii (18) Śledź tę kategorię przez RSS

Tworzenie stron internetowych

Wszystkie artykuły w tej kategorii (11) Śledź tę kategorię przez RSS

Wtyczki i triki WordPress

Wszystkie artykuły w tej kategorii (14) Śledź tę kategorię przez RSS