API przeglądarek zastępują popularne pakiety npm w 2026 roku
Wyjaśnia, w jaki sposób rdzenne funkcje JavaScript i CSS, takie jak Signals, operator pipeline, Temporal oraz pozycjonowanie Anchor, zastępują popularne pakiety npm.
Warto na chwilę przyjrzeć się własnemu plikowi package.json: ile z tych wpisów istnieje wyłącznie po to, by udawać funkcjonalność, którą przeglądarka potrafi już wykonywać sama?
Przez większość ostatnich dziesięciu lat standardową odpowiedzią na niemal każdy problem z interfejsem użytkownika było „weź jakiś pakiet”. Potrzebujesz zarządzania stanem? Wybierz Redux, Zustand lub MobX. Potrzebujesz funkcji do obsługi dat? Moment albo dayjs. Potrzebujesz narzędzi pomocniczych? lodash. Potrzebujesz animacji? GSAP albo Framer Motion. Każda framework zgromadziła swój własny zbiór kodu pomocniczego, aby naprawić luki w platformie.
Do 2026 roku ten wzorzec zmienia się szybciej, niż większość zespołów zdaje sobie sprawę. TC39 oraz główni producenci przeglądarek spędzili ostatnie lata na stopniowym tworzeniu natywnych odpowiedników dla całych kategorii narzędzi stworzonych przez firmy trzecie. Poniżej znajduje się pięć pakietów, których można poważnie rozważyć usunięcie z listy zależności już teraz, plus dwa kolejne, które są dopiero w połowie drogi do uznania za przestarzałe.
1. Biblioteki do zarządzania stanem — natywne Signals właśnie pojawiły się
Zastępuje: Redux, Zustand, MobX, Recoil, Jotai oraz wbudowane w frameworki mechanizmy reaktywności, takie jak własne referencje reaktywne w Vue
Zastąpione przez: standaryzowane prymitywy Signal (State, Computed oraz pomocnik subskrypcji sub)
Niewiele problemów podzieliło rozwój frontendu tak radykalnie jak wybór sposobu zarządzania stanem. Ekosystem Reacta przechodził przez Redux, potem Zustand, następnie Jotai i w końcu Recoil. Vue stworzył własne elementy reaktywności, a później dodatkowo zaimplementował Pinia. Solid i Svelte natomiast od samego początku zostały zbudowane wokół mechanizmów sygnałów. Każda z tych platform opracowała własną wersję elementu reaktywności, co oznaczało, że ponowne wykorzystanie logiki stanu pomiędzy różnymi frameworkami było niemal niemożliwe.
To ograniczenie złagodziło się w 2026 roku, gdy propozycja natywnych sygnałów TC39 trafiła do realizacji. Element reaktywności znajduje się teraz bezpośrednio w silniku JavaScript:
// No library. This runs in the browser as-is.
const counter = new Signal.State(0);
const doubled = new Signal.Computed(() => counter.get() * 2);
Signal.sub(() => {
console.log(`count: ${counter.get()}, doubled: ${doubled.get()}`);
});
counter.set(1); // triggers the subscription automatically
Oto co daje nam ta zmiana:
- Logikę stanu można napisać raz i wykorzystywać wszędzie — React, Vue, Solid i Svelte mogą wszystkie czytać z tego samego podstawowego elementu reaktywności
Część inżynierów określa to jako zakończenie dekadowego konfliktu pomiędzy frameworkami frontend. Gdy rdzeń reaktywny stanie się wspólny dla różnych ekosystemów, pozostałe różnice pomiędzy frameworkami sprowadzą się do składni szablonów i struktury komponentów — a nie do mechanizmów propagacji aktualizacji stanu.
2. lodash — operator pipeline kończy „kuzyna piekła callbacków”
Zastępuje: lodash, ramda oraz większość zastosowań _.chain()
Zastąpiono przez: operator pipeline, |>
Prawdopodobnie już kiedyś pisałeś coś w tym stylu:
const result = fn3(fn2(fn1(data)));
Tego typu nawiasowe wywołania funkcji — w których trzeba czytać od środka na zewnątrz, aby zrozumieć rzeczywisty porządek wykonywania — od dawna należą do największych przyczyn trudności w odczytywaniu kodu w JavaScript. Funkcja _.chain() z biblioteki lodash miała to ukrywać, ale oznaczało to konieczność używania całej biblioteki tylko po to, by uzyskać bardziej przejrzysty porządek wywołań.
Od 2026 roku operator pipeline przeszedł do etapu 4 w ES2026. Ten sam wyrażenie teraz jest czytelny w naturalnym porządku od góry do dołu:
const result = data
|> fn1
|> fn2
|> fn3;
W połączeniu z wbudowaną obsługą await, asynchroniczne pipeline czytają się niemal jak skrypty shell:
const user = userId
|> fetchUser
|> await
|> extractProfile
|> await
|> formatOutput;
Operator pipeline rozwiązuje problem czytelności kodu, podczas gdy lodash służył głównie do radzenia sobie z dawniejszym problemem braku w języku funkcjonalnych narzędzi. Teraz, gdy operacja piping jest wbudowana, metody Array.prototype są bardziej rozwinięte, a structuredClone jest powszechnie dostępny, uzasadnienie istnienia lodash znacznie się zmniejszyło. Jeśli w 2026 roku nadal znajduje się on w twoich zależnościach, usunięcie go to prawdopodobnie najprostszy sposób na zmniejszenie rozmiaru pliku.
3. dayjs i moment — APITemporal osiąga 98% pokrycia w przeglądarkach
Zastępuje: moment.js, dayjs oraz date-fns w większości przypadków użycia
Zastąpiony przez: API Temporal
To wpis jest najmniej kontrowersyjny na liście. moment.js od lat funkcjonuje wyłącznie w trybie konserwacyjnym, a nawet „lekki” dayjs dodaje ponad 2 KB do Twojego pliku bundle. Tymczasem API Temporal osiągnęło 98% pokrycia w przeglądarkach.
// dayjs
const d = dayjs('2026-09-11').add(1, 'month').format('YYYY-MM-DD');
// Temporal
const d = Temporal.PlainDate.from('2026-09-11').add({ months: 1 }).toString();
Temporal dotyczy nie tylko bardziej uporządkowanej składni — eliminuje również prawdziwe błędy, z którymi biblioteki do obsługi dat zmagały się od lat:
- Obróbka stref czasowych jest wbudowana, więc nie potrzeba oddzielnego pluginu do stref czasowych
- Obsługa systemów kalendarzowych jest wbudowana, w tym kalendarzy innych niż gregoriański
- Instancje są niezmienne, co unika klasycznej pułapki moment.js polegającej na przypadkowej modyfikacji obiektu, o którym myślało się, że pozostał nietknięty
- Rozmiar pliku bundle zmniejsza się o 10 do 50 KB
Dla projektów skierowanych do dużej grupy użytkowników mobilnych ta redukcja objętości o 10–50 KB to nie tylko zaleta – przekłada się bezpośrednio na lepszy wynik LCP.
4. Popper.js i Floating UI – pozycjonowanie kotwicze jest teraz częścią standardowego CSS
Zastępuje: Popper.js, Floating UI, Tippy.js
Zastąpione przez: CSS Anchor Positioning
Jeśli kiedykolwiek tworzyłeś podpowiedzi, wiesz, o co chodzi. Potrzebujesz menu rozwijanego, które pojawi się tuż pod przyciskiem. Stary sposób polega na użyciu position: absolute, ręcznym obliczaniu wartości top i left, a następnie konfigurowaniu słuchaczy scroll i resize, aby element nie przesunął się z miejsca. Albo korzystasz z Popper.js lub Floating UI, co dodaje kolejne kilkanaście kilobajtów tylko po to, by obsłużyć pozycjonowanie.
Do 2026 roku CSS Anchor Positioning zajmuje się tym na poziomie platformy:
/* Step 1: name the anchor element */
.button {
anchor-name: --my-trigger;
}
/* Step 2: pin the floating element to it */
.tooltip {
position: anchor(--my-trigger);
inset-area: bottom; /* below the anchor */
}
To wszystko — całe rozwiązanie. Żadnego JavaScripta, żadnych ręcznych obliczeń pozycjonowania absolutnego, żadnych zewnętrznych bibliotek. Traktuj Anchor Positioning jak system lokalizacji GPS dla elementów interfejsu unoszonych w powietrzu: skieruj go na przycisk akcji, a on pozostanie na swoim miejscu bez względu na to, jak przewija się strona lub zmienia rozmiar okna przeglądarki.
5. Sass i PostCSS — wbudowane nawijanie, @layer oraz @scope
Zastępuje: Sass, Less, PostCSS oraz ich ekosystem pluginów
Zastąpione przez: wbudowane nawijanie CSS, @layer oraz @scope
Kiedyś Sass i Less wydawały się niezbędne. Zmienne, nawijanie, miksy, funkcje wielokrotnego użycia — zwykłe CSS po prostu nie oferowało nic z tego. W 2026 roku już tak nie jest.
Wbudowane nawijanie:
.card {
background: white;
& .title { font-weight: 600; }
&:hover { box-shadow: 0 4px 12px rgba(0,0,0,0.1); }
}
@layer do kontrolowania kolejności kaskady:
@layer reset, base, components, utilities;
@scope do lekkiej izolacji stylów:
@scope (.card) to (.card__content) {
:scope { border-radius: 8px; }
}
OKLCH stał się standardowym formatem kolorów:
:root {
--color-primary: oklch(0.65 0.2 250);
--color-hover: oklch(from var(--color-primary) calc(l - 0.1) c h);
}
Dodajmy do tego zapytania kontenerów, precyzyjne wyrównywanie tekstu za pomocą text-box, pozycjonowanie oparte na elementach rodzinnych za pomocą sibling-index() oraz animacje sterowane przewijaniem — wszystko to będzie stabilne we wszystkich przeglądarzach do 2026 roku — w rezultacie Sass przesunął się z obowiązkowego narzędzia na opcjonalne narzędzie w większości projektów. Jeśli nadal jest automatycznie dodawany do twojej bazy narzędzi, warto sprawdzić, ile z funkcji, dla których go używasz, jest teraz obsługiwanych natywnie.
Dwa pakiety, które zostały tylko częściowo zastąpione
Nie każdy element na tej liście ma już pełną natywną zastępcę. Dwa są bliskie temu, ale platforma jeszcze nie nadrobiła całkowicie tę różnicę.
Biblioteki animacji — GSAP i Framer Motion kontra wbudowane przejścia View Transitions. API View Transitions stało się stabilne wraz z React 19.3, a jego komponent <ViewTransition> może automatycznie animować elementy podczas ich pojawiania się, znikania, przesuwania lub zmiany rozmiaru. Animacje sterowane przewijaniem, za pomocą animation-timeline: scroll(), umożliwiają użycie wskaźników postępu, efektów paralaksy oraz efektów stopniowego pojawiania się bez żadnego JavaScriptu. Niemniej jednak w przypadku złożonych, ręcznie skomponowanych sekwencji animacyjnych — takich, w których specjalizuje się GSAP — narzędzia wbudowane nadal nie stanowią pełnej alternatywy.
Inferencja AI — ONNX Runtime Web kontra WebNN. Do inferencji modeli w przeglądarce API WebNN może bezpośrednio korzystać z przyspieszenia NPU na poziomie systemu, unikając konieczności ładowania dziesiątek megabajtów kodu ONNX Runtime.
const context = await navigator.ml.createContext();
const builder = new MLGraphBuilder(context);
// build the inference graph...
const output = await context.compute(graph, inputs);
Ograniczenie: WebNN nadal nie ma pełnego wsparcia w przeglądarkach, więc na razie ONNX Runtime Web pozostaje bardziej niezawodnym wyborem.
Usunięcie wszystkich pięciu tych kategorii z średniej wielkości kodbazy frontendowej może zmniejszyć rozmiar zależności o 100 do 300 KB. Przy wolnym połączeniu mobilnym takie zmniejszenie może przekładać się na oszczędność 1 do 2 sekund od momentu pierwszego wyświetlenia strony.
Wniosek
Rozwój frontendu w 2026 roku charakteryzuje się odrodzeniem platform natywnych. TC39 oraz silniki przeglądarek przejmują funkcje, które wcześniej należały wyłącznie do ekosystemu npm – zarządzanie stanem, pomocniki funkcyjne, obsługa dat, pozycjonowanie elementów pływających oraz przetwarzanie wstępne CSS. Problemy, które kiedyś wymagały używania pakietów, teraz mają rozwiązania wbudowane bezpośrednio w przeglądarkę.
JavaScript zaczyna przypominać prawdziwie samowystarczalny język platformowy. Umiejętność, którą warto rozwijać, to nie głęboka wiedza na temat konkretnego frameworka czy biblioteki — lecz umiejętność oceny, kiedy platforma wystarcza, a kiedy zależność nadal ma znaczenie.
Zobacz więc swój plik package.json: ile wierszy mógłbyś usunąć dzisiaj?
Literatura pokrewna
- Jak naprawić problemy z warunkami konkurencyjnymi – dlaczego sam debouncing nie wystarcza w interfejsach wyszukiwania — Dowiedz się, dlaczego sam debouncing nie może zapobiec nadpisywaniu aktualnego stanu interfejsu przez przestarzałe odpowiedzi API, oraz poznaj cztery praktyczne rozwiązania umożliwiające kontrolowanie kolejności zapytań.