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

Spis treści
- Vanilla JavaScript i natywne API DOM jako alternatywa dla Reacta i innych frameworków
- 1. Koszt wydajnościowy wirtualnego DOM i nadmiaru kodu JavaScript
- 2. Natywne interfejsy DOM oraz Web Components
- 3. Maksymalizacja wskaźników Core Web Vitals dzięki architekturze Zero-Dependency
- Podsumowanie
- Pytania i odpowiedzi
- Ź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.
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.