LW IT Solutions logo LW IT Solutions logo 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 pozwalają zamknąć HTML, CSS i logikę interaktywną w znacznikach wielokrotnego użytku, 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): Nasłuchiwacze zdarzeń przypięte do kontenerów nadrzędnych zmniejszają liczbę potrzebnych nasłuchiwaczy. Nie trzeba ich wtedy osobno dodawać ani usuwać, gdy zmieniają się elementy potomne.
JavaScript
// 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?

Nie. Pole wewnątrz Shadow DOM samo nie zostaje wysłane z zewnętrznym formularzem. Granica Shadow DOM oddziela nie tylko style, lecz także powiązanie pola z tym formularzem.

Rozwiązaniem jest element powiązany z formularzem: static formAssociated = true, ElementInternals i jawne ustawianie wartości przez setFormValue. Wiele poradników o Web Components pomija ten krok. Bez niego komponent wygląda poprawnie, ale przy wysyłce formularza jego dane przepadają bez ostrzeżenia.

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.

Kontakt

Masz pytanie lub pomysł na projekt internetowy? Napisz krótko, o co chodzi. Formularz korzysta z reCAPTCHA do ochrony przed spamem.

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ą.