Jestem frontend devem

Wyłącz internet, odśwież stronę - a ona dalej działa. Stoi za tym Service Worker: osobny skrypt, który wchodzi między stronę a sieć i przechwytuje każde żądanie o plik, zanim trafi ono do serwera. To on decyduje, czy odpowiedzieć z sieci, z własnego cache (Cache API), czy po swojemu - a z tej jednej decyzji biorą się wszystkie strategie cache'owania, tryb offline i klasyczna pułapka 'po wdrożeniu user widzi starą wersję'.

Weź jeden plik style.css i prześledź jego dzień na działającej stronie: najpierw pobiera go przeglądarka, potem serwuje go z pamięci bez pytania serwera, później pyta serwer, czy jej kopia jest nadal aktualna, i zwykle dostaje samo potwierdzenie zamiast całego pliku, a po wdrożeniu nowej wersji pobiera go od nowa. Z tej jednej historii wychodzi cały HTTP caching - Cache-Control, ETag, 304 i stale-while-revalidate.

Cztery strategie renderowania nie są wyborem z menu, tylko decyzją per route: gdzie powstaje HTML i kiedy. Każda ma inny moment generacji, inny TTFB, inny koszt infrastruktury i inny stosunek 'świeże dane vs prędkość'. Rozkładam mechanikę czterech podejść i pokazuję, kiedy które ma sens.

Same-origin policy (SOP) w przeglądarce blokuje kod JavaScript z jednej strony przed czytaniem danych z innej domeny - chyba że serwer wprost pozwoli przez CORS. W poście opisuję, jak działa ten mechanizm zgody serwera i czemu czasem widzisz preflight OPTIONS, a czasem nie.

Każdy element DOM przechodzi przez pięć etapów, zanim go zobaczysz, niezależnie od frameworka. Niektóre style odpalają tylko ostatni etap, inne uruchamiają wszystkie pięć. Stąd różnica w kosztach animacji - od jednego etapu composite po pełny reflow.

Każdy obiekt, który tworzysz w JS, zajmuje miejsce w pamięci komputera. JavaScript usuwa nieużywane obiekty automatycznie, robiąc miejsce na nowe. Silnik czasem jednak nie potrafi rozpoznać, że dany obiekt nie jest już potrzebny - i wtedy obiekt zostaje w pamięci. Tak powstają memory leaki. Post o mechanizmie tego sprzątania (mark-and-sweep), o najczęstszych pułapkach i o tym, kiedy faktycznie sięgać po WeakMap czy WeakRef.

JavaScript ma jeden wątek, ale potrafi czekać na wiele rzeczy równocześnie. Sekret to event loop - prosty algorytm, który wybiera, co odpalić, gdy stack jest pusty. Microtaski wyprzedzają taski, render wpasowuje się między cyklami, a kolejność wykonania zaczyna mieć logiczny sens.

this w JS zachowuje się dziwnie tylko dlatego, że ludzie patrzą nie tam, gdzie trzeba. Wartość this ustala się dopiero w momencie wywołania funkcji - są tylko cztery reguły, które to wywołanie może wybrać, plus arrow functions, które wyłamują się z całego systemu.

async/await wygląda jak magia: piszesz await fetch(...), dostajesz wynik w kolejnej linijce, a wątek nie blokuje się ani na moment. Pod spodem nie ma magii - jest stary wzorzec generator + Promise + auto-runner, ukryty pod nowymi słowami async i await.

Zwykła funkcja w JS leci od góry do dołu, zwraca wynik i znika z pamięci. Generator jest inny - oznaczony function*, na każdym yield zatrzymuje swoje wykonanie, oddaje wartość i czeka na kolejne .next(). Mała zmiana w runtime, ale to ona stoi za sekwencjami liczonymi na żądanie i pod spodem async/await.

Standardowe tłumaczenie hoistingu mówi, że deklaracje przesuwają się na górę kodu. Specyfikacja ECMA-262 nie definiuje hoistingu jako mechanizmu, a let zachowuje się tak, jakby tej zasady nie znał. Co więc naprawdę dzieje się przed wykonaniem twojego kodu i dlaczego TDZ wygląda dokładnie tak, jak wygląda?

Każda linia JS musi gdzieś się wykonać, każda zmienna gdzieś żyć, każde wywołanie funkcji po sobie wrócić. Silnik trzyma to wszystko w dwóch strukturach - execution context (gdzie aktualnie jestem) i call stack (skąd przyszedłem). To one stoją za closure, this i asynchronicznością.

Słowo new w JS wygląda na krótkie, ale silnik uruchamia za nim cztery kroki naraz - tworzy pusty obiekt, podpina this, linkuje go do prototype'u funkcji i zwraca cały obiekt z powrotem. Bez new to samo trzeba napisać ręcznie z Object.create.

Async w JS bez Promise to callback hell - kod nie ma jak odwoływać się do trwającej operacji, a obsługa błędów siedzi osobno w każdym callbacku. Promise to obietnica wartości, która przyjdzie później - kod układa się płasko, a błędy łapiesz w jednym miejscu.

Funkcje w JS zwykle znikają ze swoją lokalną pamięcią. Closure łamie tę regułę - i to na niej opiera się module pattern, memoizacja, asynchroniczny JS i prywatny stan bez klas.