Всем привет!
Сегодня разберём одну из самых частых тем, которую разработчики скипают при изучении, а потом на собесах хлопают глазками, когда их спрашивают:

“В чём же разница между CommonJS и ES Modules?”

Самое обидное — ведь мы сталкиваемся с этим каждый день на практике когда пишем код, но часто относимся по принципу “работает — и ладно, потом разберусь…”

⸻

Погнали! Первый пост: Модули в JavaScript

На первый взгляд может показаться: ну что тут сложного?
Все знают про npm, установку пакетов, зависимости… Но давайте копнём глубже — в историю.

⸻

1995 — появился JavaScript

1997 — он был стандартизирован как ECMAScript

До 2009 года разработчики писали JS только для браузеров, подключая скрипты через <noscript> и надеясь, что всё загрузится в нужном порядке.
Чтобы не загадить глобальный scope, изобретались всякие костыли:
IIFE (immediately invoked function expressions), namespace-объекты и прочее веселье.

Поддерживать такой код было больно. Структуры как таковой не было.

⸻

2009 — появляется CommonJS (первое имя — ServerJS)

В это время встает логичный вопрос:

Как подключать модули? Как делиться кодом между файлами? Как изолировать зависимости?

На сцену выходит CommonJS с его:
• require() — для импорта
• module.exports — для экспорта

(Я же говорила, что все просто, по-любому видели такой синтаксис, но просто не знали возможно что это CommonJS 😂)

И тут же появляется Node.js, который становится успешной реализацией CommonJS.

⸻

2010 — выходит npm, и CommonJS становится стандартом де-факто.

⸻

Но не всё было идеально.
require() — это обычная функция, которая может принимать не только строку, и невозможно заранее определить зависимости, не исполнив код.
А то, что экспортируется через module.exports, недоступно в локальной области — неудобно!

⸻

2015 — JavaScript получает собственную систему модулей:

ES Modules

Теперь у нас есть:
• import и export (это уж точно юзаем ежедневно)
• Импорт происходит до выполнения кода — это ускоряет разработку и упрощает сборку.

⸻

Как вам такой исторический экскурс?
Стало ли понятнее, откуда ноги растут у import и require?
Пишите в комментариях — интересно узнать, было ли что-то новое для вас!

P.S. По мне понимание базовых знаний — это фундамент, без которого новые технологии превращаются в хаос, а рост в профессии становится невозможным.

👋 Всем привет!

Итак, после предыдущего поста возник закономерный вопрос:

Как вообще уживаются вместе .cjs, .mjs и .js файлы в одном проекте? 🤔
Почему где-то используется require, а где-то import? И что за магия в поле "type" в package.json — обязательно ли его указывать?

💡 Давайте разбираться!

---

📚 Для начала предлагаю погрузиться чуть в документацию:
https://nodejs.org/api/packages.html#type

Вот краткая выжимка:

🔹 Тип: string
🔹 Поле "type" в package.json определяет, как Node.js будет трактовать .js файлы:
- "type": "module" — .js файлы считаются ES-модулями
- "type": "commonjs" или поле отсутствует — .js файлы считаются CommonJS

(независимо от значения "type")
- .mjs — всегда ES-модуль
- .cjs — всегда CommonJS

---

🧐 Если заглянете в package.json вашего проекта — скорее всего, поля "type" там нет.
А в конфиге, например, Webpack’а — увидите привычный require и module.exports, то есть commonjs.

Но при этом в самом приложении вы спокойно пишете import/export (es-modules) — и всё работает 🎉

Почему так?

Потому что Webpack сам умеет разбирать модули. Он не зависит от "type" в package.json и прекрасно парсит как import, так и require, по-своему собирая ваш код.

---

🔧 То есть:
- Конфиги (которые запускает Node.js напрямую) — требуют правильного формата (.cjs, .mjs, или "type").
- Код внутри фронта — обрабатывается Webpack’ом, и на поле "type" ему все равно.

---

Вот и вся магия 💫

👋 Всем привет!

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

Меня зацепила вот эта статья:
🔗 https://www.developerway.com/posts/initial-load-performance
Initial load performance for React developers: investigative deep dive
(или — «Первоначальная производительность загрузки для React-разработчиков: глубокое исследование»)

Язык статьи — английский, но всё написано максимально понятно, даже если вы не native speaker говорится.

💡 Уже в самом начале Надя ловко подмечает: сегодня код может писать каждый, особенно с приходом ИИ.
Но... ✨быстрое приложение✨ — это не про просто "написать код". Это про понимание, как устроена под капотом веб-платформа.

В статье разбираются:

👉 что такое TTFB, FCP, LCP,

👉 как поведение страницы меняется при разных сетевых условиях,

👉 как работает CDN и зачем он вообще нужен,

👉 как браузеры кэшируют ресурсы,

👉 что делает заголовок Cache-Control и почему его нужно настраивать с умом

🔥 И да — Надя сделала небольшой проект, с которым можно поиграться, и прям показывает: "вот открой DevTools, вот поменяй настройку — и посмотри, как это влияет на метрики".

Короче, рекомендую от души, особенно если хочется стать не просто кодером, а настоящим инженером ❤️‍🔥

Вот это да!

Я совсем не ожидала, что за один день на канал подпишутся более 100 человек!
И причём — люди из совершенно разных областей 😄 Помимо фронтенд-разработчиков, тут есть (я точно знаю) один дизайнер, один девопсер, один продакт и, скорее всего, ещё мобильные разработчики!

И все вы ждёте чего-то интересного, полезного и познавательного 💡

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

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

Посты будут разные: какие-то больше подойдут разработчикам, а какие-то будут более универсальными — такими, чтобы были интересны вообще всем.

Ну что, поехали?
Через 5 минут выйдет новый пост 🔥

🔥 Ещё одна тема, которую многие не понимают по опыту. Особенно фронты!
👉 И причина, скорее всего, в лени, нехватке времени или других приоритетах — "разберусь потом", "и так работает", ну вы поняли...

А ведь если ты не понимаешь эту механику — велика вероятность, что предложишь не самое удачное решение в реальных задачах...
Давайте я попробую объяснить чуть проще.

👀 Вашему вниманию:

Service и Web Workers

Все знают, что браузер использует один поток (main thread) для выполнения JavaScript-кода, отрисовки страницы и сборки мусора.
Но если JavaScript-а слишком много — основной поток блокируется, и весь пользовательский интерфейс тормозит.

👉 Как избежать блокировок?
Воркеры (workers)!
Они позволяют выполнять код в фоновом потоке, не мешая рендеру и взаимодействию с пользователем.

---

💡 Кратко:

- Воркеры — отдельная среда выполнения JS, без доступа к window и document.
- Не могут трогать DOM напрямую.
- Используют отдельный поток → не мешают UI.

---

👷‍♂️ Web Workers

📌 Что умеют:
- Обрабатывать большие объёмы данных
- Выполнять сложную логику, чтобы не тормозил интерфейс

📌 Живут только пока вкладка открыта. Закрыл вкладку — web воркер завершил работу.

---

🛰 Service Workers

📌 Что умеют:
- Перехватывать сетевые запросы (fetch)
- Обрабатывать push-уведомления (push)
- Работать в фоне, даже если ни одна вкладка не открыта

📌 Где применяют:
- PWA (работа сайта без интернета)
- Push-уведомления на новостных сайтах
- Кэширование и заглушки при недоступности сервера

---

Надеюсь, стало понятнее 🙂
Если хотите — могу создать репу с примерами, чтобы было проще разобраться руками.

---

🔗 Полезные ресурсы:
https://web.dev/articles/workers-overview
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers

Буквально на этой неделе произошла интересная история.

Мы с коллегой проводили ассессмент одного frontend-разработчика.
И он буквально с порога — с ходу начинает негативить:

> «Вот эти ваши проверки ни к чему!»
> «Теория вообще не нужна — всё приходит с опытом!»

Честно говоря, мы немного опешили.
Ну да, если бы всё действительно приходило *только* с опытом — возможно, жить было бы и проще 🤷‍♀️

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

---

❓А вы что думаете? Нужно ли тратить время на самообразование и развитие?

Или достаточно просто «на работе разобраться» и все ресерчи делать походу?

✨ Всем привет!

В продолжение недавнего поста — сегодня немного про веб-воркеры 👩‍💻

Честно говоря, на практике мне не приходилось их использовать — ведь сложные вычисления в идеале вообще не должны происходить на фронте. Всегда топлю за то, чтобы этим занимался бэкенд или хотя бы BFF.
Ну, если только вы не делаете игру с кучей анимаций и динамики 🤯

Но если всё-таки так вышло, что надо делать тяжёлые вычисления прямо на клиенте и при этом не блокировать интерфейс — вот небольшой лайфхак.

📦 Быстро накидала репу с простейшим примером:
https://github.com/gohintosh/web-worker-example

🎥 И рассказала всю логику в коротком трехминутном видео — без воды, всё по делу!

Надеюсь, пример окажется полезным, а объяснение — понятным.
Посмотрите обязательно! 🧡

🔗 Полезные ресурсы:
https://web.dev/learn/performance/web-worker-overview
https://doka.guide/js/web-workers/
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
https://www.w3.org/TR/2021/NOTE-workers-20210128/

💼Из разработчика в руководителя: с какими трудностями я столкнулась

Поскольку моя текущая роль — руководитель разработки, решила поделиться, с какими внутренними вопросами и сложностями я столкнулась, когда перешла на эту позицию:

🧠 Я почти не пишу код. Боже, я деградирую?!

💬 Как мотивировать команду?

🪫 Как работать с не мотивированными людьми?

📚 Как не забыть всё, что знала, и продолжать развиваться?

⏰ Где взять время, чтобы и задачи разгребать, и хоть чуть-чуть кодить?

📅 Почему так много встреч? И зачем я на всех?

🧾 Как ничего не забыть и не продолбать важное?

⚖️ Как не стать микроменеджером, когда всё кажется важным?

😵 Как не выгореть, пока разбираешься, кто ты теперь вообще?

Если есть что еще добавить пишите в чат.

Буду понемного писать посты о том как мне удается решать такого рода вопросы в том числе.

Потому что мы ведь все понимаем: не всю жизнь мы будем писать код. Надо как-то учиться двигаться дальше 🚀

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

🎓 Как я получила A++ за курсовую на магистратуре в Лондоне🙈😂

Март 2015, магистратура в Лондоне. Нам выдали assignment по модулю Network Computing. Задание: реализовать RMI (Remote Method Invocation) на Java.
RMI — это такой способ, с помощью которого один объект может вызывать методы другого объекта на другом компьютере.

На тот момент никто из нас — ни я, ни мои одногруппники — вообще не понимал, что такое этот RMI, и Java у всех был только на начальном уровне. С чего начинать — непонятно 🫠

Нашла в библиотеке очень толстую книгу про RMI. Прочитала вступление… поняла ничего 😅

Перерыла весь интернет — пусто.
Потом решилась поискать на YouTube… и О ЧУДО! Нашла чувака, который быстро и чётко всё объяснял, даже показал исходники 🙏 Я смотрела это видео раз 100, ставила на паузу, делала скриншоты, повторяла шаг за шагом.
Всё поняла! Переписала код, изменила названия переменных, классов, интерфейсов , расписала всё в отчёте до самых мелочей. Прям in details, как говорится 😎

Сдала курсовую. В день результатов я просто молилась, чтобы получить хотя бы C — особенно с учётом проверки на плагиат 😬

И вот… мне ставят A++ 😱
Да ещё и забрали мой диск с работой в архив — чтобы показывать другим студентам как пример 🫠

Остальные получили так себе. Даже один араб, которому было лет на 6 больше меня и он вроде как опытный Java разраб, получил B+ 😒 Ну, может и несправедливо… но я ведь реально поняла тему и могла бы ответить на любой вопрос 😆

P.S. С того момента прошло 10 лет 😂 лучше меня не спрашивать про RMI 🤣 на харде может быть смогу найти исходники, но это не точно 😂 давайте лучше потом обсудим RPC, gRPC, REST 😂

👋 Всем привет!

Недавно наткнулась на интересный сайт — https://bigfrontend.dev/ — его называют LeetCode-ом для фронтендеров. Там собрано много клёвых задач для практики, и я решила поделиться находкой 😊

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

Давайте сегодня разомнёмся на одной из задач JavaScript уровня medium:
👉 https://bigfrontend.dev/problem/get-DOM-tags

Условие:
Есть DOM-дерево. Нужно вернуть массив уникальных имён тегов (в нижнем регистре). Порядок не важен.

Как подойти к решению:
Поскольку перед нами дерево — логично пройти его в ширину или глубину. А для хранения уникальных тегов идеально подойдёт Set.

Как нам сделать дерево так чтобы удобно было обходить его? Думаю что таким вопросом уже кто-то точно задавался. (тут даже можно погуглить если ничего на ум не приходит чтобы не изобретать велосипед, тут главное правильное направление мыслей все же)

Есть такой встроенный в браузер объект [TreeWalker](https://developer.mozilla.org/en-US/docs/Web/API/TreeWalker). Он позволяет удобно обойти DOM.
Создаётся он через document.createTreeWalker:
👉 [Документация](https://developer.mozilla.org/en-US/docs/Web/API/Document/createTreeWalker)

Шаги:
1. Создаём TreeWalker:
document.createTreeWalker(tree, NodeFilter.SHOW_ELEMENT), второй аргумент нам нужен для того чтобы нам в дереве были возвращены только элементы
2. Создаём экземпляр класса Set, в который будем добавлять теги.
3. Берём текущую ноду treeWalker.currentNode.
4. Пока есть ноды — добавляем их tagName (в нижнем регистре) в Set и двигаемся к следующей.
5. Когда обойдём всё дерево — возвращаем массив из Set.

Решение:

/**
 * @param {HTMLElement} tree
 * @return {string[]}
 */
function getTags(tree) {
  const treeWalker = document.createTreeWalker(tree, NodeFilter.SHOW_ELEMENT);
  const res = new Set();
  let cur = treeWalker.currentNode;
  while (cur) {
    res.add(cur.tagName.toLowerCase());
    cur = treeWalker.nextNode();
  }
  return Array.from(res);
}

P.S. надеюсь оказалось полезно и вы что-то новое узнали и возможно даже продолжите решать задачки из этого сайта)
#frontend #javanoscript #разборЗадач #leetcodeДляФронта

🎨 Организация стилей в современных веб-приложениях

Когда-то мы писали просто style.css — и всё работало.
А теперь… десятки подходов, библиотек и баталии в комментариях 😅

Вот краткий обзор популярных решений (по моему мнению).

---

💡 Styled-components
📄 [Документация](https://styled-components.com/docs)
💻 [Пример](https://styled-components.com/docs/basics#getting-started)

⏱️ Когда применяются стили: во время выполнения (runtime)
🛠 Настройка Webpack: ❌ не требуется
🔥 Размер бандла: больше, т.к. включает runtime
🚀 Плюсы: удобный синтаксис, динамические стили
⚠️ Минусы: runtime cost

---

💡 Linaria
📄 [Документация](https://github.com/callstack/linaria/tree/master/docs)
💻 [Пример](https://github.com/callstack/linaria/tree/master/examples)

⏱️ Когда применяются стили: build-time
🛠 Настройка Webpack: ✅ обязательна, нужны плагины
🔥 Размер бандла: минимальный — в итоговом JS нет стилей
🚀 Плюсы: без runtime
⚠️ Минусы: сложнее настроить

---

💡 CSS Modules
📄 [Документация](https://github.com/css-modules/css-modules/tree/master/docs)
💻 [Пример](https://github.com/css-modules/webpack-demo)

⏱️ Когда применяются стили: на этапе сборки (build-time)
🛠 Настройка Webpack: да, если настраиваешь вручную
🔥 Размер бандла: небольшой
🚀 Плюсы: простой, без runtime
⚠️ Минусы: не такой гибкий как css in js

---

✨ В итоге:
- Хочешь простоты — CSS Modules
- Нужны динамические стили — Styled-components
- Хочешь скорость и zero-runtime — Linaria

А какой из подходов вам больше всего нравится и почему?

#frontend #css #styledcomponents #linaria #cssmodules #вебразработка

Всем привет!

Вижу по вашим реакциям, что мой последний пост вам не особо зашел 😅
А потом совершенно случайно натыкаюсь на этот апдейт от команды styled-components — https://opencollective.com/styled-components/updates/thank-you — и понимаю, что с 18 марта 2025 года библиотека официально признана deprecated.

Причины:

🛑 Команда React де-факто задепрекейтила некоторые API, включая Context API, которое недоступно в React Server Components и не имеет пути миграции.

🌪 Экосистема в целом ушла от концепции css-in-js. Альтернативы вроде Tailwind набрали дикую популярность и вытеснили старые подходы.

👋 Основной мейнтейнер библиотеки (под ником quantizor) больше не использует styled-components в продакшене крупных проектов. А значит, реальные кейсы применения тоже будут постепенно исчезать.

В арсенале у нас по-прежнему остаются CSS Modules и Linaria, которые продолжают жить и развиваться 💪

Всем привет!
И вот — мой первый пост из серии «Борьба с тараканами» (читай: внутренними установками 🪳).

### 🧠 Таракан №1:
«Я почти не пишу код. Боже, я деградирую?!»

Долгое время мне казалось, что всё в нашей профессии крутится вокруг кода.
Типа: я пишу код — значит, делаю что-то важное и сложное.
А всё остальное — «ну это же просто, там думать особо не надо».
(Спойлер: надо. И ещё как.)

Однажды я попробовала себя в роли аналитика. И знаете, мой мозг отказывался воспринимать написанную задачу как результат моей работы. Типа: *всё? серьёзно?*

Как же я ошибалась.

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

Разработка — это лишь один из этапов. Чтобы идея, рожденная на этапе discovery, воплотилась в реальность, нужно пройти длинный путь: исследование, проектирование, согласования и только потом реализация.

И честно? По мне иногда дизайн интерфейсов сложнее, чем «просто реализовать по ТЗ».

🧩 А ещё одно важное наблюдение:
Если в команде не налажены процессы, атмосфера токсичная, нет мотивации и ясности — никакой код не спасёт.

Да, программирование — это круто. Но по-настоящему оно может быть и хобби.
А вот тимлид — это про масштаб. Это и наставничество, и поддержка команды, и создание культуры. Это про системные изменения и осознанный вклад.

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

---

#тараканытимлида
Продолжение следует 👀

Всем привет!
Недавно задумалась: как же несправедливо, что почти все фронты отлично знают как работают setTimeout и setInterval, но мало кто (по моему опыту на собесах) в курсе про requestAnimationFrame.

📌 На самом деле всё просто. Вот отличная статья, где всё на пальцах:
https://css-tricks.com/using-requestanimationframe/

---

🧠 Что это вообще?

 Метод window.requestAnimationFrame() сообщает браузеру:
> “Эй, я хочу сделать анимацию — позови меня перед следующим кадром.”

Браузер вызовет вашу функцию ровно перед перерисовкой экрана.
Это обычно происходит 60 раз в секунду (60 Гц), но может быть и 120 или 144 Гц — в зависимости от монитора.
(И вам не нужно определять частоту — кайф же!)

👀 А если вкладка в фоне — браузер приостановит вызовы, чтобы не тратить ресурсы зря.

---

✍️ Синтаксис супер-простой:

function repeatOften() {
  // делаем что-то на каждом кадре
  requestAnimationFrame(repeatOften);
}

requestAnimationFrame(repeatOften);

📌 Вызовите один раз — и функция будет рекурсивно запускаться перед каждым кадром. Идеально для прогресс-баров, скролл-эффектов, игр, всего где нужна плавность.

---

⚠️ Главное — не забывайте вовремя отменять requestAnimationFrame, если он больше не нужен: иначе будет утечка памяти.