Frontender's notes

JavaScript сегодня отмечает 30-летие 🎂 Именно 4 декабря 1995 года миру показали язык под знакомым нам названием — JavaScript. ❌ Вот история именинника:

• У языка было три имени за пару месяцев. Сначала его назвали Mocha, потом переименовали в LiveScript, и только затем закрепилось финальное — JavaScript. • К Java он почти не имеет отношения. Название выбрали скорее как маркетинговый ход: в середине 90-х вокруг Java был мощный хайп, и на эту волну просто запрыгнули. • JS слепили всего за 10 дней. Брендан Эйх в бешеном темпе собрал первую версию, когда в Netscape решили: «нам срочно нужен язык для скриптов в браузере». • Создатель языка успел стать CEO Mozilla — и быстро лишиться должности. Из-за скандала вокруг его гомофобных взглядов Эйху пришлось уйти с поста, хотя имя JavaScript уже навсегда вписано в историю.

🎉 Поздравляем старичка, который до сих пор двигает весь веб. 🚪 Frontender's notes

Нам нужна не просто кнопка, а кнопка-ШЕДЕВР! //Нам нужна не просто кнопка, а кнопка, которая понравится миллионам! В VK понимают — важен не только красивый код, но и понятный каждому интерфейс. Без единых стандартов здесь не обойтись — сегодня VK рассказывает о своих командах, их принципах и самых интересных результатах. Переходите по ссылке: там много интересного!

💬 Event Loop в Node.js VS в браузере Многие считают, что event loop в Node.js и браузере работает одинаково. Однако, несмотря на общие черты, существуют важные различия, которые влияют на асинхронное поведение и производительность приложения. Разобравшись с этими различиями, можно писать более эффективный асинхронный код и избежать лагов и задержек. Давайте разберемся, что именно отличает работу event loop в этих двух средах.

❌ Браузер: всё о пользовательском интерфейсе В браузере event loop сосредоточен на работе с пользовательским интерфейсом (UI). Его основная задача — обеспечить плавность рендеринга, быстроту реакции на события, выполнение JavaScript и обработку Web APIs. В процессе работы с UI браузер использует несколько типов очередей задач. Это microtasks, такие как обработка Promise и queueMicrotask, и macrotasks, в которые попадают setTimeout, setInterval и MessageChannel. Также есть отдельная фаза для рендеринга. Браузер обязан поддерживать плавность UI, поэтому между макротасками он обязательно вставляет фазу рендеринга, что позволяет минимизировать задержки при обновлении интерфейса. ❌ Node.js: event loop от libuv В Node.js event loop работает на основе библиотеки libuv, которая используется для асинхронных операций, таких как работа с файловой системой, сетью и другими I/O операциями. В отличие от браузера, в Node.js есть несколько фаз, которые позволяют эффективно управлять этими операциями. Node.js использует шесть фаз, включая Timers (setTimeout, setInterval), Poll (обработка I/O операций), Check (setImmediate) и другие. Основное отличие заключается в том, что Node.js управляет низкоуровневыми операциями с системой, такими как файлы и сеть, в то время как браузер сосредоточен на рендеринге и UI. Это позволяет Node.js быть более гибким в обслуживании серверных запросов и файловых операций. ❌ Где начинается путаница Существует несколько распространенных недопониманий между setTimeout и setImmediate. В браузере нет метода setImmediate, в то время как в Node.js он выполняется в фазе Check, а setTimeout — в фазе Timers. Это может привести к путанице, особенно при переносе кода между Node.js и браузером. Также стоит отметить различие в работе microtasks. В браузере микротаски выполняются сразу после каждого макротаска, а в Node.js они выполняются после каждой фазы event loop, что позволяет их более эффективно управлять и избегать блокировки цикла. ❌ Ещё одним важным отличием является рендеринг В Node.js нет рендеринга, так как он работает в серверной среде и не требует обновления визуальной части. В браузере, наоборот, рендеринг влияет на порядок выполнения задач и может вызвать задержки, если не правильно управлять этим процессом. Например, repaint может произойти между macrotask, microtask и снова macrotask, что важно учитывать при оптимизации производительности в браузере. ❌ Что важно помнить разработчику • В Node.js основное внимание уделяется I/O операциям, таким как работа с файлами, сетью и процессами. Эти задачи добавляют свои очереди и обрабатываются в разных фазах event loop. • В браузере event loop синхронизирован с частотой кадров, что критически важно для обеспечения плавности UI. • Microtasks в Node.js ведут себя агрессивнее, особенно process.nextTick, который может заблокировать переход между фазами event loop, если заспамить его слишком большим количеством задач. • setImmediate и setTimeout — это не одно и то же. Порядок их выполнения в Node.js зависит от контекста и фазы event loop, в которой они находятся.

📌 Знание этих различий позволяет избежать лагов и писать эффективный асинхронный код, который будет работать предсказуемо как в браузере, так и в серверной среде Node.js. 🚪 Frontender's notes

Если JavaScript у вас пока живёт в консоли и учебных задачках, самое время вытащить его в «настоящий мир». На открытом вебинаре соберём мини-приложение, которое очень похоже на реальный продуктовый интерфейс: каталог с карточками, фильтрами и поиском по данным с внешнего API. Что будем делать на вебинаре: - Подключим внешний API и загрузим реальные данные — без фейковых «заглушек». - Построим каталог с карточками: изображение, название, описание — как в интернет-магазинах или сервисах подбора. - Добавим поиск, фильтры и индикатор загрузки, чтобы интерфейс выглядел и вёл себя живо. - Покажем, как обрабатывать ошибки и показывать корректные UI-состояния, а не просто «ничего не происходит». - Разберём структуру приложения на чистом JS: где хранятся данные, где бизнес-логика, как устроен рендеринг. 9 декабря, 20:00 МСК. Открытый урок проходит в преддверии старта курса «JavaScript Developer. Basic». Регистрация открыта: https://vk.cc/cRTpaz Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🤣 Гениальный план, как избавиться от бесящих коллег 💥 xCode Journal

Нужна мощная и гибкая CRM-платформа? Выбирайте Модус — модульную CRM-платформу, созданную для больших компаний! Почему Модус лучше обычной CRM? ✅ Масштабируемость — одновременная работа в системе 10 000+ пользователей ✅ Гибкость — выбирайте только нужные инструменты или комплексное внедрение ✅ Полный цикл взаимодействия с клиентом — от первого контакта до подписания контракта и постпродажного обслуживания ✅ Надежность — 100% российское решение, работайте в облаке или на своих серверах Хотите узнать больше? 📅 Закажите демонстрацию и запросите стоимость для вашей компании: Перейти на сайт #реклама 16+ nota.tech О рекламодателе

⬆️ Профилирование бандла: что скрыто внутри .map файлов Когда размер вашего фронтенд-бандла начинает расти, вы, вероятно, используете такие инструменты, как Webpack Bundle Analyzer, чтобы увидеть, что именно увеличивает размер. Но на самом деле эти инструменты работают с .map файлами и тут скрывается гораздо больше информации, чем кажется на первый взгляд. Давайте разберемся, что лежит внутри этих файлов и как их использовать для глубокого профилирования.

✅ Что такое .map файлы? Файлы .map — это JSON-структуры, которые содержат полную информацию о вашем коде. В них хранятся ссылки на оригинальные файлы, сам исходный код, соответствие между минифицированными и оригинальными строками кода, а также список символов и имён. Это не просто файлы для дебага, это своего рода словарь вашего кода, который позволяет анализировать и профилировать его работу. ✅ Почему .map файлы полезны для профилирования? С помощью этих файлов вы можете выявить множество проблем с бандлом, которые не очевидны при обычном просмотре. Они помогают определить, какой модуль занимает больше всего места, что попадало в бандл случайно, а также какие зависимости или фрагменты кода оказываются тяжёлыми для производительности. Это важно для профилирования, так как неправильные UI-операции часто вызывают лаги и фризы на страницах с большими бандлами. ✅ Что можно увидеть в .map файле? С помощью .map файлов можно выявить различные проблемы. Например, они помогут понять, если вы случайно импортировали весь пакет lodash вместо конкретной функции или подключили слишком тяжёлый UI-кит, хотя использовали только одну кнопку. Также вы сможете найти дублирование модулей, если разные версии одной и той же библиотеки были добавлены в ваш проект. В некоторых случаях .map файлы показывают подтягивание ненужных polyfills или «раздутые» функции, которые не были удалены после трешейкинга. Всё это можно обнаружить, если внимательно изучить .map файл. ✅ Как читать .map файлы? Для анализа .map файлов можно использовать специальные инструменты, такие как maps-codec, source-map-explorer или даже встроенные инструменты в браузере через DevTools. Эти инструменты помогут вам понять, что именно добавляет вес вашему бандлу и как это влияет на производительность. Если вы хотите пройти путь профилирования вручную, можно использовать source-map-explorer, который визуализирует содержимое .map файла и помогает быстро найти проблемные места. ✅ Когда вы работаете с .map файлами, стоит следовать нескольким простым рекомендациям • Во-первых, всегда анализируйте source map на продакшн-сборке, так как staging-сборки могут иметь разные флаги, влияющие на результат. • Во-вторых, используйте опцию hidden-source-map, чтобы скрыть карты от публичного доступа, но использовать их в CI. • Также не забывайте отслеживать динамические импорты, ведь .map файл может показать, что именно попадало в ваши чанки. • И, конечно, сравнивайте .map файлы между сборками, чтобы понять, что именно увеличивает размер бандла.

📌 Если научиться правильно читать и использовать эти файлы, можно не только понять, почему бандл растёт, но и выявить, что в него попало лишнего. Вы увидите, какие импорты раздувают код и, в конечном счёте, что на самом деле происходит в вашем toolchain. 🚪 Frontender's notes

💡 Render Cost: как оценивать стоимость UI-операций Производительность фронтенда — это не просто «быстрее». Важно понимать, какие операции UI обходятся браузеру в наибольшую цену. Render cost помогает измерять стоимость рендера, обновлений, изменений DOM, расчётов layout и стилей. Это важная метрика для оптимизации интерфейсов.

ℹ️ Что такое render cost? Render cost — это сумма всех затрат, которые браузер несёт при выполнении операций с пользовательским интерфейсом, включая создание и изменение DOM-узлов, обновление стилей, пересчёт layout, перерисовка элементов и выполнение JS, которое запускает все эти операции. В крупных проектах неправильные UI-операции могут стать причиной лагов и фризов интерфейса. ❌ Самые дорогие операции Перерасчёт геометрии элементов, запуск рендеринга с кистью и смешивание слоёв — все эти процессы могут быть затратными для производительности приложения. Пересчёт геометрии элементов происходит при чтении свойств offsetWidth, getBoundingClientRect(), изменении размеров, положения или шрифтов, а также при применении сложных CSS-правил. Запуск рендеринга с кистью особенно дорог при использовании эффектов, фильтров или градиентов. Смешивание слоёв обычно несложная операция, но может стать дорогой, если слоёв слишком много. Кроме того, тяжёлые вычисления на JavaScript могут блокировать главный поток и задерживать рендеринг пользовательского интерфейса. ✅Как оценить render cost в реальных проектах • React DevTools Profiler: Позволяет понять, какие компоненты перерисовываются слишком часто, где тратится больше всего времени и какие пропсы вызывают каскадные обновления. • Chrome Performance panel: Главный инструмент для анализа. Позволяет увидеть трейсинг JS, layout events, paint events и точные триггеры reflow. • Performance Insights: Подсвечивает проблемные места и даёт рекомендации по улучшению производительности. • Lighthouse: Отлично показывает точки деградации на высоком уровне и предлагает пути для их устранения. 🤚 Что считается «дорогим» в UI? В пользовательском интерфейсе (UI) «дорогим» считается всё, что требует значительных ресурсов для выполнения и может замедлять работу приложения. К таким элементам относятся частые полные перерисовки списков вместо частичных обновлений, громоздкие компоненты, где один стейт перерисовывает всю страницу, сложные CSS-стили, например, глубокие селекторы, а также DOM с тысячами узлов на одном экране и последовательное чтение и изменение layout (forcing reflow). ⚡️ Как снижать render cost Чтобы снизить render cost, важно оптимизировать компоненты: делите их на мелкие для уменьшения области перерисовки. Используйте fine-grained реактивность с помощью сигналов, селекторов или memoized stores, чтобы обновлялось только необходимое. Избегайте живых reflow, группируя измерения и изменения DOM. Применяйте виртуализацию для рендеринга только видимых элементов в DOM. Используйте transform вместо top/left в CSS, избегайте тяжёлых эффектов и следите за структурой CSS. Для тяжёлой логики можно использовать Web Workers, перенося вычисления в основной поток и сохраняя отзывчивость UI.

📌 Render cost — это не про то, как быстро что-то рендерится, а про то, сколько стоит сделать изменения. Иногда, чтобы оптимизировать, нужно не ускорять рендеринг, а избегать ненужных действий. Оптимизация UI — это как правильно распределить ресурсы и убрать лишнее. Важно не только сделать рендеринг быстрее, но и чтобы он был предсказуемым и точным. 🚪 Frontender's notes

📸 Атрибуты loading, decoding, fetchpriority — как ускорить загрузку изображений с нативными атрибутами Есть три простых и нативных атрибута HTML, которые могут значительно ускорить загрузку изображений и сделать ваш интерфейс более отзывчивым. И хотя они поддерживаются всеми современными браузерами, почему-то их редко используют на практике. Давайте разберём их по порядку.

⬅️ loading="lazy" — откладываем загрузку Атрибут loading="lazy" заставляет браузер откладывать загрузку изображений за пределами экрана, что экономит трафик пользователей, уменьшает время до интерактивности (TTI) и снижает нагрузку на слабые устройства. Его следует применять для всех изображений ниже первого экрана, а также для карточек, списков и галерей. Однако, не стоит использовать этот атрибут для важных для интерфейса изображений на первом экране, таких как логотипы и hero-изображения, чтобы избежать задержек в загрузке сайта. ⚡️ decoding="async" — асинхронная декодировка Атрибут async позволяет браузеру асинхронно декодировать изображения, не блокируя рендеринг других элементов, что уменьшает визуальные задержки и ускоряет загрузку страниц. Это особенно полезно для больших изображений и элементов в лентах и списках, улучшая восприятие производительности и снижая «дерганье». 🔫 fetchpriority="high | low" — управление приоритетом загрузки Атрибут loading определяет приоритет загрузки изображения: high для первоочередной загрузки, low для загрузки позже. Это уменьшает конкуренцию между ресурсами, ускоряет LCP и снижает визуальные задержки при рендеринге страницы, обеспечивая более быструю и плавную загрузку.

👀 Примеры и как использовать вместе

<!-- Откладываем загрузку --> <img src="hero.png" loading="lazy" /> <!-- Асинхронная декодировка --> <img src="photo.jpg" decoding="async" /> <!-- Управление приоритетом загрузки --> <img src="hero.jpg" fetchpriority="high" /> <img src="avatar.jpg" loading="lazy" fetchpriority="low" /> <!-- Всё вместе --> <img src="hero.jpg" decoding="async" fetchpriority="high" /> <img src="thumb.jpg" loading="lazy" decoding="async" fetchpriority="low" />

🚪 Frontender's notes

📕Angular SSR за час: превращаем SPA в ракету 👤Подходит разработчикам JavaScript/TypeScript, Junior/Middle разработчикам, желающим освоить Angular, Frontend-разработчикам на других фреймворках (React, Vue) На открытом уроке 2 декабря в 20:00 мск мы освоим внедрение SSR в приложение: серверный рендеринг, SEO-метаданные, работа с API и базовое понимание hydration: 📗 На вебинаре разберем: 1. Понимание базовой архитектуры SSR в Angular. 2. Понимание поведения приложения до и после hydration. 📘 В результате на практике изучите и освоите умение подключить SSR к существующему приложению, работу с серверным рендерингом данных и настройку SEO-метаданных. 👉 Регистрация на урок и подробности о курсе Angular Developer: https://vk.cc/cRMGnL Все участники открытого урока получат скидку на курс "Angular Developer" с промокодом ANGULAR12 Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576