Всем привет!
Меня зовут Гаухара, но можно просто Гоша — именно так меня называют многие.
Я тимлид с опытом работы во фронтенд-разработке более 8 лет. Имею степень Master of Science in Computer Communications Networks, которую получила в Brunel University London.
Недавно я задумалась: а почему бы не создать Telegram-канал, где я смогу делиться своим опытом и размышлениями о пути в IT? Возможно, это будет полезно и для кого-то другого.
В канале я планирую затрагивать самые разные - темы:
➡️ Мысли и инсайты, которые приходят неожиданно.
➡️ Дайджесты — разбор статей, которые действительно стоит прочитать, и основные идеи, которые можно из них почерпнуть.
➡️ Обзоры и размышления о книгах, которые я прочитала.
➡️ Решение различных задач, с которыми я сталкиваюсь.
Зачем мне это?
Для меня это в первую очередь дисциплина. Регулярно делиться чем-то полезным и углубленно изучать новые темы, чтобы иметь возможность объяснить их другим. Кроме того, это способ рефлексировать над прожитым опытом, который, возможно, окажется полезным или найдет отклик у кого-то еще.
Честно говоря, я не знаю, что из этого получится. Но, как говорится, пока не попробуешь — не узнаешь. Так что давайте начнем! Уверена, будет интересно и познавательно.
Меня зовут Гаухара, но можно просто Гоша — именно так меня называют многие.
Я тимлид с опытом работы во фронтенд-разработке более 8 лет. Имею степень Master of Science in Computer Communications Networks, которую получила в Brunel University London.
Недавно я задумалась: а почему бы не создать Telegram-канал, где я смогу делиться своим опытом и размышлениями о пути в IT? Возможно, это будет полезно и для кого-то другого.
В канале я планирую затрагивать самые разные - темы:
Зачем мне это?
Для меня это в первую очередь дисциплина. Регулярно делиться чем-то полезным и углубленно изучать новые темы, чтобы иметь возможность объяснить их другим. Кроме того, это способ рефлексировать над прожитым опытом, который, возможно, окажется полезным или найдет отклик у кого-то еще.
Честно говоря, я не знаю, что из этого получится. Но, как говорится, пока не попробуешь — не узнаешь. Так что давайте начнем! Уверена, будет интересно и познавательно.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤4👍4🤡1👨💻1
Всем привет!
Сегодня разберём одну из самых частых тем, которую разработчики скипают при изучении, а потом на собесах хлопают глазками, когда их спрашивают:
“В чём же разница между 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. По мне понимание базовых знаний — это фундамент, без которого новые технологии превращаются в хаос, а рост в профессии становится невозможным.
Сегодня разберём одну из самых частых тем, которую разработчики скипают при изучении, а потом на собесах хлопают глазками, когда их спрашивают:
“В чём же разница между 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. По мне понимание базовых знаний — это фундамент, без которого новые технологии превращаются в хаос, а рост в профессии становится невозможным.
👍17👨💻3❤2🤡1
👋 Всем привет!
Итак, после предыдущего поста возник закономерный вопрос:
Как вообще уживаются вместе
Почему где-то используется
💡 Давайте разбираться!
---
📚 Для начала предлагаю погрузиться чуть в документацию:
https://nodejs.org/api/packages.html#type
Вот краткая выжимка:
🔹 Тип:
🔹 Поле
-
-
(независимо от значения
-
-
---
🧐 Если заглянете в
А в конфиге, например, Webpack’а — увидите привычный
Но при этом в самом приложении вы спокойно пишете
Почему так?
Потому что Webpack сам умеет разбирать модули. Он не зависит от
---
🔧 То есть:
- Конфиги (которые запускает Node.js напрямую) — требуют правильного формата (
- Код внутри фронта — обрабатывается Webpack’ом, и на поле
---
Вот и вся магия 💫
Итак, после предыдущего поста возник закономерный вопрос:
Как вообще уживаются вместе
.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" ему все равно.---
Вот и вся магия 💫
👍8❤3🔥2🤡1
👋 Всем привет!
Недавно наткнулась на блог классной девушки по имени Надя — она фронтенд-архитектор, разработчица, преподаватель и просто крутая профи. Пишет супер полезные статьи на темы, о которых редко говорят глубоко, но просто.
Меня зацепила вот эта статья:
🔗 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, вот поменяй настройку — и посмотри, как это влияет на метрики".
Короче, рекомендую от души, особенно если хочется стать не просто кодером, а настоящим инженером ❤️🔥
Недавно наткнулась на блог классной девушки по имени Надя — она фронтенд-архитектор, разработчица, преподаватель и просто крутая профи. Пишет супер полезные статьи на темы, о которых редко говорят глубоко, но просто.
Меня зацепила вот эта статья:
🔗 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, вот поменяй настройку — и посмотри, как это влияет на метрики".
Короче, рекомендую от души, особенно если хочется стать не просто кодером, а настоящим инженером ❤️🔥
Developerway
Initial load performance for React developers: investigative deep dive
Exploring Core Web Vitals, Chrome performance panel, what initial load performance is, which metrics measure it, and how cache control and different networking conditions influence it.
🔥8🤡1
Frontend Developer pinned «Всем привет! Меня зовут Гаухара, но можно просто Гоша — именно так меня называют многие. Я тимлид с опытом работы во фронтенд-разработке более 8 лет. Имею степень Master of Science in Computer Communications Networks, которую получила в Brunel University…»
Вот это да!
Я совсем не ожидала, что за один день на канал подпишутся более 100 человек!
И причём — люди из совершенно разных областей 😄 Помимо фронтенд-разработчиков, тут есть (я точно знаю) один дизайнер, один девопсер, один продакт и, скорее всего, ещё мобильные разработчики!
И все вы ждёте чего-то интересного, полезного и познавательного 💡
Обещаю, что буду выкладываться на максимум, чтобы этот канал действительно прокачивал — без воды, только по делу и с душой.
Не знаю, как так получилось, но мне всегда нравилось делиться с людьми полезными знаниями — и особенно видеть тот самый блеск в глазах, когда человек действительно понял тему и точно применит полученные знания на практике.
Через Telegram-канал, конечно, этот блеск я не увижу 🙂
Но зато смогу понять, насколько зашла информация, — по вашей обратной связи 💬
Посты будут разные: какие-то больше подойдут разработчикам, а какие-то будут более универсальными — такими, чтобы были интересны вообще всем.
Ну что, поехали?
Через 5 минут выйдет новый пост 🔥
Я совсем не ожидала, что за один день на канал подпишутся более 100 человек!
И причём — люди из совершенно разных областей 😄 Помимо фронтенд-разработчиков, тут есть (я точно знаю) один дизайнер, один девопсер, один продакт и, скорее всего, ещё мобильные разработчики!
И все вы ждёте чего-то интересного, полезного и познавательного 💡
Обещаю, что буду выкладываться на максимум, чтобы этот канал действительно прокачивал — без воды, только по делу и с душой.
Не знаю, как так получилось, но мне всегда нравилось делиться с людьми полезными знаниями — и особенно видеть тот самый блеск в глазах, когда человек действительно понял тему и точно применит полученные знания на практике.
Через Telegram-канал, конечно, этот блеск я не увижу 🙂
Но зато смогу понять, насколько зашла информация, — по вашей обратной связи 💬
Посты будут разные: какие-то больше подойдут разработчикам, а какие-то будут более универсальными — такими, чтобы были интересны вообще всем.
Ну что, поехали?
Через 5 минут выйдет новый пост 🔥
🔥16❤4👏3👍2
🔥 Ещё одна тема, которую многие не понимают по опыту. Особенно фронты!
👉 И причина, скорее всего, в лени, нехватке времени или других приоритетах — "разберусь потом", "и так работает", ну вы поняли...
А ведь если ты не понимаешь эту механику — велика вероятность, что предложишь не самое удачное решение в реальных задачах...
Давайте я попробую объяснить чуть проще.
👀 Вашему вниманию:
Service и Web Workers
Все знают, что браузер использует один поток (
Но если JavaScript-а слишком много — основной поток блокируется, и весь пользовательский интерфейс тормозит.
👉 Как избежать блокировок?
Воркеры (workers)!
Они позволяют выполнять код в фоновом потоке, не мешая рендеру и взаимодействию с пользователем.
---
💡 Кратко:
- Воркеры — отдельная среда выполнения JS, без доступа к window и document.
- Не могут трогать DOM напрямую.
- Используют отдельный поток → не мешают UI.
---
👷♂️ Web Workers
📌 Что умеют:
- Обрабатывать большие объёмы данных
- Выполнять сложную логику, чтобы не тормозил интерфейс
📌 Живут только пока вкладка открыта. Закрыл вкладку — web воркер завершил работу.
---
🛰 Service Workers
📌 Что умеют:
- Перехватывать сетевые запросы (
- Обрабатывать 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
👉 И причина, скорее всего, в лени, нехватке времени или других приоритетах — "разберусь потом", "и так работает", ну вы поняли...
А ведь если ты не понимаешь эту механику — велика вероятность, что предложишь не самое удачное решение в реальных задачах...
Давайте я попробую объяснить чуть проще.
👀 Вашему вниманию:
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
web.dev
Workers overview | Articles | web.dev
How web workers and service workers can improve the performance of your website, and when to use a web worker versus a service worker.
👍14🔥4
Буквально на этой неделе произошла интересная история.
Мы с коллегой проводили ассессмент одного frontend-разработчика.
И он буквально с порога — с ходу начинает негативить:
> «Вот эти ваши проверки ни к чему!»
> «Теория вообще не нужна — всё приходит с опытом!»
Честно говоря, мы немного опешили.
Ну да, если бы всё действительно приходило *только* с опытом — возможно, жить было бы и проще 🤷♀️
По ощущениям, у человека опыт есть, это видно.
Но — как мне показалось — не было кругозора и глубины знаний.
---
❓А вы что думаете? Нужно ли тратить время на самообразование и развитие?
Или достаточно просто «на работе разобраться» и все ресерчи делать походу?
Мы с коллегой проводили ассессмент одного frontend-разработчика.
И он буквально с порога — с ходу начинает негативить:
> «Вот эти ваши проверки ни к чему!»
> «Теория вообще не нужна — всё приходит с опытом!»
Честно говоря, мы немного опешили.
Ну да, если бы всё действительно приходило *только* с опытом — возможно, жить было бы и проще 🤷♀️
По ощущениям, у человека опыт есть, это видно.
Но — как мне показалось — не было кругозора и глубины знаний.
---
❓А вы что думаете? Нужно ли тратить время на самообразование и развитие?
Или достаточно просто «на работе разобраться» и все ресерчи делать походу?
🔥12
Media is too big
VIEW IN TELEGRAM
✨ Всем привет!
В продолжение недавнего поста — сегодня немного про веб-воркеры 👩💻
Честно говоря, на практике мне не приходилось их использовать — ведь сложные вычисления в идеале вообще не должны происходить на фронте. Всегда топлю за то, чтобы этим занимался бэкенд или хотя бы 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/
В продолжение недавнего поста — сегодня немного про веб-воркеры 👩💻
Честно говоря, на практике мне не приходилось их использовать — ведь сложные вычисления в идеале вообще не должны происходить на фронте. Всегда топлю за то, чтобы этим занимался бэкенд или хотя бы 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/
🔥16