Все мы часто используем в работе такие единицы измерения, как vh и vw, в основном, чтобы заставить какой-то блок растянуться на всю область видимости, указав для него width: 100vw; и height: 100vh;

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

Дело в том, что у мобильных браузеров есть два режима отображение собственного интерфейса - полноценная версия, и более компактная, которая появляется при скролле. Обратите внимание на панель браузера, когда скроллите какой-то сайт на телефоне - она в какой-то момент будет “ужиматься”.

Чтобы учесть это, лучше всего заменять vh и vw на dvh и dvw, единицы измерения для динамического вьюпорта. На десктопных браузерах они будут работать без изменений, а вот на мобильных при любом из вариантов отображения браузера - компактном или полноценном - будут подстраиваться под него. Если же все время использовать vh и vw, то при отображении полноценной навигации в браузере будет появляться дополнительный скролл. Этот эффект можно наглядно увидеть на примере с Doka (откройте его с мобильного браузера).

К тому же, если верить MDN, у новых значений на данный момент есть полная поддержка на всех современных браузерах. Пожалуй, стоит пойти и заменить все vh и vw на моих проектах на новые единицы.

P.S. На эту тему также есть интересная статья на dev.to.

Всем привет! На связи Настя)

В определенный момент развития своей карьеры фронтенд-разработчика я начала сталкиваться с вопросом «Куда мне расти?». С одной стороны, казалось, что все основные технологии я уже освоила. Но каждый раз, натыкаясь на новое для себя CSS-свойство или метод в JavaScript, я убеждалась в обратном. «Как же много всего я упускаю» - думала про себя.

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

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

Спустя какое-то время, мы с Машей и Олей собрались в Codeca Frontend, и в тот момент эта идея возродилась. К ней добавилась идея того, как полезно было бы новичкам иметь максимально подробный план со всеми ресурсами для изучения, чтобы, идя по нему, можно было оценить, на каком этапе ты сейчас находишься, и сколько еще тебе осталось до твоего первого собеседования.

Так появился наш проект - роадмап фронтендера. Честно, столько всего нового, сколько я узнала за время подготовки этого роадмапа, я давно не узнавала. И даже многие идеи постов для этого канала появлялись именно оттуда.

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

Мы работали над ним несколько месяцев и вот наконец готовы представить его!

🔗 (тут была ссылка на роадмап, но он больше не доступен 🤷‍♀️)

Нам очень волнительно, ведь это первый наш полноценный продукт, и надеемся, что он будет полезен 🙏

А вы знали, что какое-то время назад в CSS появилась функциональность для каскадных слоев?

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

При этом стили вне слоев все еще будут в приоритете над остальными. На картинке представлен небольшой пример, как это работает.

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

@import url("https://cdn.com/bootstrap.min.css") layer;

@layer {
 .fs-1 {
  font-size: 3rem;
 }
}

Да, это отличная возможность избавиться от !important, правда если ваш проект не настроен так, что стили из библиотек подкладываются в общий style.css вместе со стилями проекта при сборке. Из-за того, что стили вне слоя всегда будут в приоритете, переопределение через слои не будет работать. Тогда получается, что нужно либо весь проект переводить на использование слоев, или же не использовать их.

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

Подробнее про каскадные слои можно почитать в статье на Doka.

Всем привет! На связи снова Настя)

Как вы знаете, этот канал являлся частью проекта Codeca Frontend. Мы втроем с Машей и Олей делали образовательный и развлекательный контент про программирование, не только здесь, в телеграм, но и на других площадках.

Однако, все в мире меняется, и наш тандем не стал исключением. Теперь каждая из нас уходит в свободное плавание (хотя какие-то совместные проекты все же планируются).

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

Кроме этого, у меня остается тикток с мемасами.

Машу и Олю вы можете найти на других площадках:
- ютуб-канал Маши
- телеграм-канал Маши
- ютуб-канал Оли
- инстаграм Оли

Это было непростое решение, хоть у нас и пока что не слишком большая аудитория, но, тем не менее, нам важна ваша поддержка и понимание 🙏

Вот такие вот предновогодние новости 🙊

Я уже давно работаю во фронтенде, но все равно периодически забываю о том, что в JavaScript появляются новые удобные инструменты. Так, я заметила, что упускаю из виду Map и Set.

Для тех, кто так же, как и я, забывает про них, напомню:

- Map похож на обычный объект, с той разницей, что в качестве ключа в нем можно использоваться вообще любой тип, в том числе функцию или объект
- а Set позволяет хранить множество уникальных значений, то есть сколько бы раз вы не выполнили set.add() с одним и тем же значением, фактически оно будет добавлено только один раз

У обоих сущностей есть метод has(), который позволяет проверять наличие ключа (в случае Map) или значения (в случае Set).

Если мы хотим добавить элемент, когда его нет, или удалить, когда он есть, то вот как можно было бы написать это в обычном массиве:

const index = allValues.indexOf(currentValue);

if (index === -1) {
  allValues.push(currentValue);
} else {
  allValues.splice(index, 1);
}

А вот как в Set:

if (allValues.has(currentValue)) {
  allValues.add(currentValue);
} else {
  allValues.delete(currentValue);
}

Согласитесь, что второй пример читается гораздо понятнее, уже не говоря о производительности.

Все это наводит меня на мысль, что, хоть в разработке и важно следить за обновлениями, но не зазорно упускать какие-то моменты. Главное - хотя бы постфактум замечать и использовать это.

Нет ничего утомительнее, чем делать задачи, где нужно по 100 раз перезапускать одно и то же. Например, когда настраиваешь CI в проекте. Сделал правку → залил → ждешь пока CI раскочегарится и выдаст тебе очередную ошибку, которую ты пойдешь исправлять.

Или вот, недавно переходила на проекте с npm на pnpm. И опять - что-то исправляешь → ждешь пока все модули переустановятся → смотришь, что не работает → исправляешь дальше.

Пока сидела и ждала, подумала, а почему вообще pnpm? Основной аргумент перехода - это лучше npm-а, но стало интересно, а чем же. Пошла искать и собрала для вас небольшую статью, которую можно почитать на досуге.

Кстати, в этой статье я вообще никак не затронула тему работы с peer dependencies, а этому в документации pnpm посвящена отдельная страница. Так что дайте знать, если вам будет интересно, и я подготовлю отдельный материал (заодно и сама разберусь получше 🙃).

Что такое роадмап фронтендера?

Когда мы только задумали этот проект, то конечно же пошли смотреть, а что уже существует в интернете. Мы нашли несколько роадмапов для начинающих фронтендеров. Там были перечислены технологии, которые нужно освоить (такие как HTML, CSS и JavaScript), и основные темы внутри них.

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

И конечно, наша гордость - разделы с практическими заданиями. Это и отдельные элементы интерфейса, и темы для целых проектов, со ссылками на подходящие макеты и моковые API для подключения.

Роадмап можно приобрести только до 31 января. За небольшую стоимость вы получите огромное количество информации и кучу полезных ссылок!)

🔗 (тут была ссылка на роадмап, но он больше не доступен 🤷‍♀️)

(А еще это отличный подарок на Новый год фронтендеру или тому, кто собирается им стать))

Обо мне

Привет всем новеньким и стареньким в этом канале! Сегодня хочу познакомиться поближе)

Меня зовут Настя, я занимаюсь коммерческой разработкой больше 7 лет - в декабре 2017-го устроилась на свою первую работу и закрутилось… Последние 3 года я работаю в Яндексе над внутренними продуктами, но не только.

Я фанат бэкенда, недаром начинала свою карьеру как фуллстек на php (все мы там были, друзья). Поэтому иногда поглядываю на Node.js и всякие инфраструктурные истории, CI/CD, базы данных и прочее, а сейчас на досуге изучаю Kotlin 🙊

Кроме этого, я люблю качественные UI и UX. Не могу назвать себя задротом по скруглениям кнопочек и не думаю, что мой глаз заточен на поиск смещения в 2 пикселя. Но уверена, что удобство интерфейсов - это важно. Наличие лоадеров/скелетонов и сообщений об ошибках как база, и плавные анимации там, где они к месту, как приятное дополнение 💅

Ещё я люблю публичные выступления (да-да, такие люди существуют!). Я выступала на внутренних мероприятиях в Яндексе, один доклад на Podlodka Crew тоже был. А в планах на 2025 год начать свой путь как спикера на митапах и конференциях.

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

Ну а в остальном, я - очередной формошлёп и кнопокрасильщик 🤡
Добро пожаловать, и надеюсь, мы подружимся)

Tiktok | Twitter(X)

В продолжении темы про непопулярные структуры данных в JavaScript, такие как Map и Set.
Я решила вспомнить, в чем особенность WeakMap и WeakSet, и вот краткая памятка.

WeakMap
- Хранит пары ключ-значение, где ключи — только объекты.
- Ключи "слабые": если на объект-ключ больше нет ссылок, он удаляется сборщиком мусора.
- Нет методов для итерации.

WeakSet
- Хранит только объекты, каждое из которых уникально.
- Объекты "слабые": они удаляются, если нет других ссылок на них.
- Не поддерживает итерацию и не имеет свойства размера.

Такие структуры данных можно использовать, например, для кэширования (WeakMap) или хранения информации вида “да/нет” (WeakSet).

Полезности пост: оказывается, в CSS есть функция attr, которая помогает получать значение любого атрибута, и использовать его в CSS.

“Так это же полностью убирает необходимость явного использования inline-стилей!”, - подумала сначала я, пока не увидела поддержку этой функции в браузерах. По факту, её сейчас можно использовать только для CSS-свойства content и только как строку. То есть, вытащить значение вы можете из любого атрибута HTML-элемента (даже data-атрибута), а вот использовать - в очень ограниченном виде.

Как всегда в CSS - находишь что-то классное, но использовать пока что не можешь. 🥲

Подробнее можно почитать на Doka (где я про него и узнала)

На выходных сидела игралась с peer deps в pnpm, чтобы написать 2 часть, как и обещала, и неожиданно увидела, что мне установился React 19. Пошла почитать бложик, и оказалось, что в декабре 2024 года они наконец выпустили стабильный релиз. (Чуть не пропустила такую новость)

Ну что же, добро пожаловать в новую эру!

В связи с этим предлагаю стряхнуть пыль со старых постов в этом канале, где мы немного рассматривали самые интересные фичи:
- Обзор новинок React 19
- Новые хуки React 19 с примерами:
- Часть 1
- Часть 2
- Server Components и Server Actions:
- Часть 1
- Часть 2

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

Скажу немного про себя. На наших рабочих проектах мы нескоро пойдем обновляться, как минимум потому, что потребуется обновить и Next.js.

Есть один проект, который сейчас не использует его, а имеет кастомную сборку на Webpack, и у нас в планах как раз лежит задача обновления React там с 17 версии. Лично мне пока не хочется прыгать на 19, тем более, что в проекте много легаси, в том числе и классовых компонентов. Хотя на сайте React уверяют, что все еще не прекращают их поддержку.

Как в жизни, не люблю рисковать, так и в работе, когда вижу установку версии x.0.0, невольно начинаю думать про нерешенные баги, на которые можно наткнуться, и хочется немного подождать. Но повод подумать все же есть.

P.S. После того, как написала этот пост, пошла смотреть, и увидела, что на проекте сейчас стоит [email protected]. Эти люди были явно смелее, чем я, так что, может быть, тоже не бояться?)

Как и обещала, вторая часть про peer dependencies.

Не сильно углублялась в то, как это работает на глубоком уровне в pnpm, но рассмотрела пару интересных примеров конфликтов зависимостей с использованием peer deps.

Некоторое время назад мы на работе проводили догфуддинг.

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

У нас это был догфуддинг перед запуском новых фичей для сайта. Так как наш продукт специфичный (как, я думаю, многие продукты в IT), у нас нет возможности использовать его каждый день на работе. Поэтому догфуддинг нужно организовывать специально.

Как это проходило

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

Что в результате

По итогу догфуддинга мы завели 67 багов и 22 фича-реквеста. Если вы думаете, что это слишком много, то лично мне так не показалось)
Во-первых, это был первый раз с начала разработки, когда мы “отошли подальше”, чтобы посмотреть на всё то, что было сделано.
Во-вторых, не все из этих багов и фичей были приоритетными. Мы руководствовались принципом “записывай все, что приходит в голову, а потом разберемся”. Лучше записать и потом с командой решить, что это неактуально, чем упустить какой-то важный момент. Мне это напоминает принцип Inbox-а из GTD.
К тому же, часть багов и задач дублировали друг друга. Дубли закрывались уже после окончания догфуддинга, чтобы не тратить на это время сразу.


Я уже не первый раз сталкиваюсь с догфуддингом на работе. Каждый раз для него могут быть разные цели: познакомиться с продуктом, который вы делаете (например, для новеньких в команде или при передаче проекта от одной команды к другой), или понять, какие боли испытывают ваши пользователи, возможно, некоторые из них можно решить двумя строчками кода.
В нашем случае догфуддинг показал, где решения в нашем продукте были еще сырыми и недоработанными.

От меня точно лайк такой практике!)

Про фикс NODE_OPTIONS=--openssl-legacy-provider

У меня на работе в каждом втором проекте, который использует Node.js 17+, добавлен этот параметр при запуске npm run build или pnpm run dev. Хочется понять, что же он значит, а значит, пришло время покопаться.

Начнём с того, что если убрать NODE_OPTIONS=--openssl-legacy-provider, то приложение может упасть с такой ошибкой:

error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:69:19)
at Object.createHash (node:crypto:133:10)

Проблема появилась, когда Node.js 17 решили переехать на новую версию библиотеки OpenSSL. Её версия 3.0 использует новые методы шифрования, а многие старые методы (например, md4) оказались неподдерживаемыми.

В свою очередь, на методах из OpenSSL основана и Node.js библиотека crypto (мы можем увидеть её упоминание в самом коде ошибки).

А тут уже Webpack, и некоторые другие библиотеки, особенно устаревших версий, могут использовать старые алгоритмы шифрования из crypto. Далеко ходить не надо, вот ишью в Webpack 5 про использование md4.

Получается такая цепочка:
→ мы на нашем проекте используем, например, webpack
→ он использует алгоритм шифрования md4 из встроенной Node.js-библиотеки crypto
→ сам Node.js уже использует OpenSSL версии 3.0, а поэтому и md4 в crypto больше не работает
→ ловим ошибку при попытке собрать приложение

Если бы команда Node.js в свое время выкатила релиз без возможности поддержки старых инструментов, то у нас бы сломалось пол интернета. Поэтому они, конечно, предусмотрели фикс - та самая опция --openssl-legacy-provider, которая позволяет использовать Legacy версию OpenSSL. Мы можем или добавить опцию сразу в консольную команду:

node --openssl-legacy-provider server.js

или через специальный параметр, как встречается чаще всего:

NODE_OPTIONS=--openssl-legacy-provider npm run build

Но конечно, лучше всего отказываться или обновлять библиотеки, которые требуют устаревший алгоритм (+1 причина переходить с Webpack на Vite)))

Недавно джавист спросил меня: "А в чём вообще проблема использования var в JavaScript?". Я на автомате ответила что-то про замыкания, но потом поняла, что конкретику-то уже подзабыла. А значит, как я люблю, самое время покопаться и вспомнить, что же с ним не так.

Почему var считается устаревшим?

Когда в ES6 в 2015 году появились let и const, почти весь мир фронтенда перешёл на них. Но var никуда не делся и до сих пор встречается в старом коде. Почему же все от него отказались?

1. var живёт в рамках функции, а не блока

Если объявить var внутри if, for или `{}`-блока, он доступен во всей функции, а если функция не задана – в глобальной области видимости.

function example() {
    if (true) {
        var message = "Hello";
    }
    console.log(message); // "Hello"
}
example();

2. var поднимается (hoisting), но остаётся undefined

Переменные, объявленные через var, поднимаются в начало функции и принимают значение undefined, если к ним обратиться до объявления.

console.log(user); // undefined
var user = "Cat";

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

Почему работу с var не исправили сразу, как заметили проблемы?

Когда JavaScript создавался в 1995 году, он задумывался как язык для небольших скриптов, которые просто добавляли интерактивность на веб-страницы. Никто не думал, что на нем будут писать сложные приложения с десятками тысяч строк кода. Поэтому такие вещи, как var с функциональной областью видимости, не казались проблемой – ведь весь скрипт обычно находился в одном файле и выполнялся сверху вниз. Но затем веб-разработка начала усложняться. JS стал полноценным языком для больших приложений, а старые решения начали тянуть за собой ошибки.

В ES6 наконец-то добавили let и const, чтобы исправить проблемы var, но полностью убрать или изменить принцип его работы было невозможно. JavaScript выполняется на машинах пользователей, а браузеры у всех разные – кто-то сидит на новой версии Chrome, а кто-то на старом IE. В отличие от компилируемых языков, где ты контролируешь, какая версия используется, в вебе это сделать невозможно. Поэтому var остался в языке таким, какой он есть, ради обратной совместимости.

К слову, может показаться, что особенности var – это только источник багов, но в некоторых случаях это удобно. Например, hoisting позволяет вызывать функции до их объявления.

В общем-то, JS менялся и продолжает меняться под давлением времени, и отказ от var – одна из тех вещей, которые сделали разработку на этом языке чуть предсказуемее.

Как я переношу проект с Webpack 4 на Vite

Сейчас на работе мы обновляем один старый проект и решили мигрировать его с Webpack 4 на последний Vite. В два этапа: сначала dev-сборку, потом уже продакшен.

Дано

• Проект на Webpack 4, dev- и прод-сборки собираются одной конфигурацией.
• Нужно перенести dev-сборку на Vite, а прод оставить на Webpack.
• У проекта кастомный сервер на Express, который сам отдаёт HTML.
• Vite же по умолчанию использует свой собственный HTML.

1. process.env

Первым делом выяснилось, что Vite не понимает process.env (что, в целом, логично), а у нас этого добра в коде много, и менять каждый экземпляр вручную не хочется. Помог vite-plugin-environment.

2. require()

В коде использовался require() для импорта переводов и языков в highlight.js, а Vite его не поддерживает. Решила заменить на import.iss.oneta.glob() – он как раз умеет динамически подгружать файлы! Но… Webpack 4 не поддерживает import.iss.oneta.glob(), и в прод-сборке всё снова сломалось. -_-

В итоге спасло третье решение:
• Для переводов – передаю данные сразу с сервера через тег в HTML.
• Для highlight.js – пока вручную использую await import, подгружаю все нужные языки. После отказа от Webpack можно будет переехать на import.iss.oneta.glob().

3. moment.js

Старая сборка прекрасно работала с moment.js и специальными плагинами для импорта локалей и таймзон, но с Vite они так себе друзья, и заставить его подгружать всё нужное оказалось нетривиальной задачей.

Решение:
• Добавила ручной импорт локали там, где это необходимо (import 'moment/dist/locale/ru'; moment.locale('ru');).
• Но перед окончательным переходом на Vite в проде хочется полностью отказаться от moment.js и связанных с ним компонентов (react-datetime).

Выводы

Если хотите перенести dev-сборку с Webpack 4 на Vite, обратите внимание на эти вещи:
• process.env в Vite по дефолту не работает – нужен либо import.iss.oneta.env, либо плагин.
• Если в коде есть require(), Webpack и Vite не договорятся – придётся искать обходные пути.
• moment.js + Vite могут создать проблемы с локалями и таймзонами, их нужно загружать вручную.

P.S. Пока я разбиралась с этой задачей, впервые на полную использовала ChatGPT (да-да, только сейчас, в 2025-м!))). Я постоянно загружала в него ошибки, с которыми сталкивалась, и решения, которые в итоге помогли (не обязательно из его предложенных).
Отчасти благодаря этому и родился этот пост – как эксперимент. Его мне помог написать чат, имея всю предыдущую информацию. Опыт интересный, но рассказ о формате лично моего взаимодействия с ChatGPT лучше вынести в отдельный пост)

Когда-нибудь замечали в HTML что-то вроде <script nonce="abc123">?

Nonce – это одноразовый токен, который помогает защитить сайт от XSS-атак. Когда на сайте используется механизм CSP (Content Security Policy), браузер по умолчанию блокирует все inline-скрипты. Но если очень хочется использовать их, можно, вместо указания директивы unsafe-inline (которая будет разрешать любые такие скрипты), добавить nonce, который заранее прописан в заголовках ответа сервера. Тогда браузер выполнит только те скрипты, у которых этот токен правильный.

Пример CSP-заголовка:

Content-Security-Policy: script-src 'nonce-abc123'

​
Теперь в коде можно использовать:

<script nonce="abc123">console.log('Безопасный JS');</script>
<script nonce="efg567">console.log('Будет заблокирован');</script>

​
Обычно nonce создаётся для каждого запроса отдельно и передаётся в шаблон, чтобы его можно было подставить в скрипты.

Пример для Express:

app.use((req, res, next) => {
  // Генерируем nonce
  res.nonce = crypto.randomBytes(16).toString('base64');
  // Устанавливаем CSP-заголовок
  res.setHeader('Content-Security-Policy', `script-src 'nonce-${res.nonce}'`);
  next();
});

app.get('/', (req, res) => {
  res.send(`
    <html>
      ...
      <script nonce="${res.nonce}">
        console.log('Этот скрипт выполнится');
      </script>
    </html>
  `);
});

​
Теперь каждый запрос получает новый nonce, который передаётся в CSP-заголовке и также вставляется в HTML. Это позволяет безопасно использовать inline-скрипты, не открывая сайт для XSS.

#startpoint_dev_nodejs
Как-то вечером я задумалась: мне ведь нравится Node.js, но я знаю о нём далеко не всё. Так зародилась идея копнуть глубже — разобраться в таинственных механизмах, которые заставляют эту систему работать на благо разработчиков.

Поэтому приглашаю вас в увлекательное путешествие по просторам вечных циклов макро- и микротасок, setTimeout-ов и nextTick-ов. Мы будем постепенно погружаться, в частности, в работу Event Loop — от базового “что это вообще такое” до фундаментальных вещей, на которых строится Node.js.

P. S. Я пишу эти посты прямо сейчас и, как истинный писатель, сама не знаю, куда заведёт меня эта история и чем закончится путь её героев. Так что если у вас есть интересные темы или экзистенциальные вопросы про Node.js — пишите, будем разбираться вместе!)

Event Loop крутится, Node.js мутится. Часть 1. Браузер VS сервер.