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