Wnętrze silnika JavaScript: co naprawdę się dzieje, gdy odpalasz kod

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

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?

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.

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.

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.

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.