DEV Community: Mari Kalyuzhna

✨♻️ Визуализируя JavaScript. Часть 2/7: цикл событий [перевод]

Mari Kalyuzhna — Wed, 06 Dec 2023 16:35:28 +0000

Данный текст является переводом оригинальной статьи ✨♻️ JavaScript Visualized: Event Loop авторства ****Lydia Hallie. В процессе адаптации на русский язык я попыталась сохранить стиль автора.

Статья является частью серии из 7-ми текстов, в которой Лидия доступно, с живыми иллюстрациями и юмором, раскрывает одни из самых базовых и, вместе с тем, сложных для понимания концепций и принципов JavaScript.

Введение

«О боже, цикл событий» — так наверняка думал хотя бы раз в своей жизни любой frontend–разработчик. Это одна из тех вещей, с которыми так или иначе приходится сталкиваться каждому JavaScript разработчику чуть ли не каждый день, но поначалу концепция Event Loop кажется запутанной. Я визуал и умею наглядно представлять информацию, поэтому решила попытаться помочь вам, объяснив это визуально с помощью гифок с низким разрешением, потому что на дворе 2019 год [на момент написания оригинального поста], а гифки почему-то все еще пиксельные и размытые.

Но прежде всего, что такое цикл событий и почему вас это должно волновать?

JavaScript является однопоточным : одновременно может выполняться только одна задача. Обычно в этом нет ничего страшного, но теперь представьте, что вы выполняете задачу, которая занимает 30 секунд... М-да... Во время этой задачи мы ждем 30 секунд, прежде чем что-то еще может произойти (JavaScript по умолчанию запускается в основном потоке браузера, поэтому весь интерфейс завис) 😬 На дворе 2019 год, никому не нужен медленный и не отвечающий сайт.

К счастью, браузер предоставляет нам некоторые функции, которых нет в самом движке JavaScript: Web API. Сюда входят DOM API, setTimeout, HTTP-запросы и т. д. Это может помочь нам создать асинхронное, поведение, которое не будет блокировать основной поток 🚀

Стек вызовов

Когда мы вызываем функцию, она добавляется в нечто, называемое стеком вызовов (call stack). Стек вызовов является частью движка JS и не зависит от браузера. Это очередь, что означает “первый пришёл, последний ушёл” (представьте себе стопку блинов). Когда функция возвращает значение, оно извлекается из стека 👋

Стек вызовов — это структура данных, которая, говоря упрощённо, записывает сведения о месте в программе, где мы находимся. Если мы переходим в функцию, мы помещаем запись о ней в верхнюю часть стека. Когда мы из функции возвращаемся, мы вытаскиваем из стека самый верхний элемент и оказываемся там, откуда вызывали эту функцию. Это — всё, что умеет стек.

1 || Функции помещаются в стек вызовов, когда мы их вызываем, и извлекаются, когда возвращают какой-то результат

Очередь вызовов и setTimeout

Функция respond возвращает setTimeout функцию. setTimeout предоставляется Web API: он позволяет нам откладывать задачи на заданное время, не блокируя основной поток. Функция обратного вызова (коллбэк), которую мы передали функции setTimeout, стрелочная функция () => { return 'Hey'}, добавляется в Web API. Тем временем setTimeout функция и функция respond извлекаются из стека, они обе вернули свои значения!

2 || setTimeout предоставляется нам со стороны браузера, Web API позаботится о коллбэке, который мы передали

В Web API таймер работает столько, сколько мы указали во втором аргументе, — 1000 мс (по умолчанию время в JS указывается в мс). Коллбэк не добавляется сразу в стек вызовов, вместо этого он откладывается в нечто, называемое очередью.

3 || Когда время таймера закончится (1000 мс, в данном случае), коллбэк будет помещён в очередь вызовов

Это может сбить с толку: окончание таймера не означает, что функция обратного вызова добавляется в стек вызовов (и, следовательно, возвращает значение) через 1000 мс! Коллбэк просто добавляется в очередь через 1000 мс. Но это очередь, функция должна дождаться своей очереди!

Очереди работают по принципу “первый пришёл, первый вышел” (представьте себе очередь в магазине).

Наконец, часть, которую мы все ждали… Пришло время циклу событий выполнить свою единственную задачу: соединить очередь со стеком вызовов! Если стек вызовов пуст, т. е. все ранее вызванные функции вернули свои значения и были извлечены из стека, первый элемент из очереди добавляется в стек вызовов. В этом случае никакие другие функции не вызывались, а это означает, что стек вызовов был пуст к тому моменту, когда функция обратного вызова стала первым элементом в очереди.

4 || Цикл событий смотрит на очередь коллбэков и на стек вызовов. Есть стек вызовов пуст, в него перемещается первый элемент из очереди коллбэков

Наконец, коллбэк добавляется в стек вызовов, вызывается, возвращает значение и извлекается из стека. Ура! 🎉

5 || Коллбэк добавляется в стек вызовов и выполняется. После того, как функция возвращает значение, они извлекается из стека вызовов

Читать статью весело, но вам станет комфортно со стеком вызовов только тогда, когда будете работать с ним снова и снова. Попытайтесь выяснить, что выведется в консоль, если мы запустим следующей код:

const foo = () => console.log("First");
const bar = () => setTimeout(() => console.log("Second"), 500);
const baz = () => console.log("Third");

bar();
foo();
baz();

Разобрались? Давайте быстро взглянем, что происходит, “за кулисами” когда мы запускаем этот код в браузере:

Мы вызываем bar.bar возвращает таймер setTimeout.
Коллбэк, который мы передали в setTimeout, добавляется в Web API, функции setTimeout и bar извлекаются из стека вызовов.
Таймер запускается, тем временем foo вызывается и логирует First. foo возвращает *undefined*.
Вызывается baz и попадает в стек вызовов, тем временем, коллбэк таймера добавляется в очередь.
baz логирует Third. Цикл событий видит, что стек вызовов пустеет после того, как из baz возвращается *undefined*. Теперь коллбэк таймера добавляется в стек вызовов.
Наконец, логируется Second. Коллбэк отработал, вернул *undefined* и вышел из стека вызовов.

Заключение

Надеюсь, что благодаря этому посту вы почувствуете себя более комфортно с циклом событий! Не волнуйтесь, если это все еще кажется запутанным, самое главное — понять, откуда могут возникнуть определенные ошибки/поведение, чтобы эффективно находить в Google нужные термины и, в конечном итоге, оказаться на правильной странице Stack Overflow 💪🏼 Не стесняйтесь обращаться к автору, если у вас есть вопросы!

Lydia Hallie в соцсетях: Twitter || Instagram || GitHub || LinkedIn || Website

P.S. Автор использовала Keynote для создания анимаций и записей экрана.

P.P.S. В других статьях будут рассмотрены такие штуки, как Поднятие (hoisting), область действия (scope chain), прототипное наследование (prototypal inheritance), генераторы и итераторы (generators ans iterators), промисы (promises) и async/await.

🚀⚙️ Визуализируя JavaScript. Часть 1/7: ядро JavaScript [перевод]

Mari Kalyuzhna — Wed, 06 Dec 2023 13:55:49 +0000

Краткая иллюстрация процесса обработки скриптов движком JS

Данный текст является переводом оригинальной статьи 🚀⚙️ JavaScript Visualized: the JavaScript Engine авторства Lydia Hallie. В процессе адаптации на русский язык я попыталась сохранить стиль автора.

Вступление

JavaScript очень крут (и не только на мой взгляд). Но как, спросите Вы, машина может действительно понимать код, который мы пишем? Нам, JavaScript разработчикам, обычно не приходится иметь дело непосредственно с компиляторами. Однако, неплохо бы иметь базовые представления об устройстве ядра JavaScript и знать, как в нём наш human-friendly код обрабатывается и преобразуется в машинные команды. 🥳

Внимание! Данный пост, в основном, опирается на движок V8, используемый в Node.js и Chromium-подобных браузерах.

Итак. Что же происходит “за кулисами”?

Этап 1. Поток байтов

Парсер HTML сталкивается с тэгом script с указанием источника. Код из этого источника запрашивается из сети, кэша или установленного сервис воркера (service worker). Ответом на запрос является скрипт, представленный в виде потока байтов. Забота об этом потоке поручается специально обученному декодеру потока байтов, который обрабатывает данные по мере загрузки :)

1 || Скрипт загружается в виде потока байтов в кодировке UTF-16 из сети, кэша или воркера и передаётся в декодер потока байтов

Этап 2. Декодер потока байтов

Декодер потока байтов создаёт специальные токены на основе поступившего потока. Так, например, 0066 преобразуется в f, 0075 — в u, 006e — в n, 0063 — в c, 0074 — в t, 0069 — в i, 006f — вo, а 006e превратится в n с последующим пробелом. Кажется, здесь было закодировано ключевое слово function! В JavaScript это одно из специальных зарезервированных слов. Итак токен был создан и отправлен в парсер (и препарсер, что пока не отображено в иллюстрациях, потому что мы вернёмся к этому моменту позже). Похожая судьба постигает и все остальные символы во входящем потоке байтов.

2 || Декодер потока байтов переводит байты в токены. Токены отправляются в парсер

Этап 3. Парсер и Абстрактное Синтаксическое Дерево

Ядро движка на самом деле состоит аж из двух парсеров: препарсера (pre-parser) и парсера (parser). В попытках сократить время загрузки веб-сайта, движок старается не парсить код, в котором нет необходимости сразу, прямо сейчас. Препарсер обрабатывает код, который может быть использован позже, в то время как парсер работает над кодом, который нужен “здесь и сейчас”!

Например, если какая-то функция вызывается только когда пользователь нажимает на кнопку, нет нужды компилировать эту часть кода немедленно для загрузки сайта. А вот, когда пользователь вызовет событие клика по кнопке, запрашивая тем самым конкретную функцию, тогда парсер обработает её.

Парсер генерирует узлы (ноды), основанные на токенах, полученных из декодера потока байтов. Из этих узлов формируется Абстрактное Синтаксическое Дерево (Abstract Syntax Tree, AST). 🌳

3 || Парсер генерирует узлы, основанные на токенах, и создаёт Абстрактное Синтаксическое Дерево

Этап 4. Интерпретатор

Наконец, в дело вступает интерпретатор! Интерпретатор, который проходит через AST, и генерирует байтовый код, основанный на информации, полученной от AST. После того, как код сгенерирован полностью, Абстрактное Синтаксическое Дерево удаляется, очищая память. Итак, наконец, мы имеем что-то, с чем может работать наша машина (компьютер/телефон и т.д.)! 🎉

4 || Интерпретатор проходится по AST (Абстрактное Синтаксическое Дерево) и генерирует байтовый код

Этап 5. Оптимизирующий компилятор

Хотя байт-код быстрый, он может быть быстрее. По мере выполнения этого байт-кода генерируется информация. Он может определить, часто ли повторяемся определенное поведение, а также типы используемых данных. Возможно, вы вызываете какую-то функцию десятки раз: пришло время ее оптимизировать, чтобы она работала еще быстрее! 🏃🏽‍♀️

Байт-код вместе с фидбеком сгенерированного типа отправляется оптимизирующему компилятору. Оптимизирующий компилятор принимает байт-код и фидбэк типа и генерирует на их основе высокооптимизированный машинный код. 🚀

5 || Байт–код и фидбек типа отправляются в оптимизирующий компилятор, который генерирует высоко оптимизированный машинный код

Про работу движка с динамической типизацией

JavaScript — это динамически типизированный язык, а это означает, что типы данных могут постоянно меняться. Было бы очень медленно, если бы движку JavaScript приходилось каждый раз проверять, какой тип данных имеет определенное значение.

Чтобы сократить время, необходимое для интерпретации кода, оптимизированный машинный код обрабатывает только те случаи, которые движок видел раньше при запуске байт-кода. Если мы неоднократно использовали определенный фрагмент кода, который снова и снова возвращал один и тот же тип данных, оптимизированный машинный код можно просто использовать повторно, чтобы ускорить процесс. Однако, поскольку JavaScript является динамически типизированным, может случиться так, что один и тот же фрагмент кода внезапно вернет данные другого типа. Если это произойдет, машинный код будет деоптимизирован, и движок вернется к интерпретации сгенерированного байт-кода.

Допустим, определенная функция вызывается 100 раз и до сих пор всегда возвращала одно и то же значение. Предполагается , что он также вернет это значение при 101-м вызове.

Допустим, у нас есть некоторая функция sum, которая (до сих пор) всегда вызывалась с числовыми значениями в качестве аргументов каждый раз:

function sum(a, b) {
    return a + b
}

sum(1, 2)

Вызов функции в примере выше вернёт число 3! В следующий раз, когда мы вызовем нашу функцию, движок будет считать, что мы вызываем её снова с двумя числовыми значениями.

Если это правда, динамический поиск не требуется, и можно просто повторно использовать оптимизированный машинный код. В противном случае, если предположение было неверным, вместо оптимизированного машинного кода произойдет возврат к исходному байтовому коду.

Например, при следующем вызове мы передадим строку вместо числа. Поскольку JavaScript является динамически типизированным, мы можем сделать это без каких-либо ошибок!

function sum(a, b) {
    return a + b
}

sum('1', 2)

В таком случае, число 2 будет преобразовано в строку, и вместо числа 3 функция вернет строку "12". Движок JavaScript возвращается к выполнению интерпретированного байт-кода и обновляет обратную связь о типе.

Заключение

Надеюсь, этот пост был полезен для вас! Конечно, остаётся ещё много частей ядра JS, которые я не раскрыла в этом материале (JS heap, стек вызовов, и т.д.), о которых я расскажу позже! Я определенно рекомендую вам начать самостоятельно проводить исследования, если вы интересуетесь внутренними особенностями JavaScript. V8 имеет открытый исходный код и имеет отличную документацию о том, как он работает под капотом! 🤖

Полезные ссылки: V8 Docs || V8 Github || Chrome University 2018: Life Of A Script

Ролик на YouTube на английском, где Лидия ещё более наглядно разбирает устройство движка JavaScript:

Understanding the V8 JavaScript Engine

Lydia Hallie в соцсетях: Twitter || Instagram || GitHub || LinkedIn || Website

P.S. Автор использовала Keynote для создания анимаций и записей экрана.

P.P.S. В следующих статьях будут рассмотрены такие штуки, как Поднятие (hoisting), Цикл событий (event loop), область действия (scope chain), прототипное наследование (prototypal inheritance), генераторы и итераторы (generators ans iterators), промисы (promises) и async/await