Команда JavaScript for Devs подготовила перевод статьи о долгом пути протокола QUIC в Node.js. Четыре года сообщество ждало, пока OpenSSL откроет нужные API — и вот, с выходом версии 3.5, это наконец случилось. Уже в Node.js 25 ожидается первая реализация QUIC — шаг, к которому проект шёл почти полдесятилетия.
Всем привет!
Давайте представим, что от бизнеса поступил запрос: "Нам надо, чтобы при входе на сайт сразу же открывалось модальное окно авторизации для сканирования клиентского QR-кода."
Вы запускаете стабильно работающий проект, применяете useEffect с необходимой фичей и пустой зависимостью, а затем - начинаете тестировать.
И вот незадача: модальное окно открывается на миллисекунду и моментально закрывается.
При этом: логи в порядке, стейты меняются корректно, но модальное окно живет своей жизнью и наотрез отказывается работать, как ей предписано.
Я потратил довольно длительное время на поиски этой ошибки. Но затем, удалив setTimeout, который мы использовали для анимирования модального окна, заметил, что все стало работать корректно.
Длительный поиск вариантов анимирования открытия/закрытия модального окна не помог.
Но стоит отметить, что я узнал множество способов и комбинаций его анимирования: как при помощи сторонних зависимостей, так и нативных.
Использование сторонних зависимостей я отбросил сразу. Смириться, что все модальные окна на проекте отныне будут работать без красивых анимаций я не мог, поэтому сразу же приступил к поискам решения данной проблемы.
Совершенно случайно наткнувшись на статью @GragertVD, которая, словом, не подходила под мои критерии поиска - я открыл для себя совершенно новый обработчик события onAnimationEnd и наконец решил указанную выше проблему.
Именно поэтому мне захотелось рассказать о том, как я это сделал.
В этой статье я расскажу:
Как найти и удалить неиспользуемый JavaScript код даже на крупном сайте. Объёмный, но простой в использовании способ.
Команда JavaScript for Devs подготовила перевод статьи о новом CSS-правиле @starting-style — инструменте, который обещает упростить анимацию появления элементов. Но всё ли так гладко? Автор показывает, что за красивым синтаксисом скрываются подводные камни специфичности и неожиданные баги, из-за которых старые добрые keyframes по-прежнему оказываются надёжнее.
Если вы работаете с JavaScript, то знаете, что есть несколько способов объявить переменную (let, const). Эти объявления существуют уже давно и имеют адекватные правила блочной области видимости. Возможно, вы также помните времена, когда их не было. У нас был только var. А var - отвратителен. Каждая переменная изменяема, нельзя навязать неизменяемость, и что ещё хуже - var выходит иногда за пределы блока. Поэтому для меня было большим сюрпризом узнать, что код TypeScript (написанный на TypeScript - пока что) усеян var-ами так, будто на дворе 2003-й. В чем же причина?
Примерно месяц назад я рассказывал о проекте @er77/code-graph-rag-mcp — инструменте, который превращает LLM из простого генератора кода в полноценного члена команды с глубоким пониманием архитектуры вашего проекта. Сегодня я рад представить самое крупное обновление, которое выводит анализ кода на совершенно новый уровень. Мы не просто добавили новые функции, мы кардинально расширили возможности инструмента, увеличили его производительность и добавили поддержку десяти языков программирования.
Пошаговое руководство по симуляции солнца, дождя, снега и грозы в интерактивном трехмерном приложении для прогноза погоды.
Меня всегда интересовала визуализация данных с помощью Three.js / R3F и я подумал, что приложение для прогноза погоды будет отличным началом. Одна из моих любимых открытых библиотек, @react-three/drei, содержит множество прекрасных инструментов, вроде облаков, неба и звезд, которые отлично подходят для визуализации погоды в 3D.
В этом туториале мы научимся преобразовывать данные из API в трехмерный опыт, добавив немного изюминки и веселья в визуализацию погоды.
Около года назад я написал первую часть статьи о Single SPA — о том, как я выбирал архитектурный подход, боролся с монолитом и пробовал собрать первые микрофронтенды. В статье были разобраны базовые принципы работы Single SPA, подключение importmap, сравнение с другими архитектурными решениями и настройка сборки на Webpack и Vite.
Эта статья — продолжение цикла. Здесь я поделюсь практикой: как на самом деле живётся с Single SPA, какие есть подводные камни и что можно вынести в виде рекомендаций.
Сразу скажу: Single SPA — не «серебряная пуля» и уж точно не современный тренд фронтенд-разработки. В 2025-м появилось еще больше других подходов, которые решают похожие задачи иначе. Но Single SPA всё ещё актуален там, где есть огромные легаси-системы, которые невозможно переписать с нуля. И вот именно для таких кейсов мой опыт может быть полезен.
Давно хотел попробовать Prolog, и вот появился удобный случай. Пришла идея логической игры, смесь шахмат, шашек и нашествия зомби. Prolog - логический язык программирования, говорят, на нём удобно решать комбинаторные задачи, что может пойти не так!
Пробуем собрать свой минималистичный starter-kit.
Комедия в трех действиях. Туториал из трех частей.
Создадим причудливый конфиг на webpack + собственный роутинг в первой части. Реализуем реактивные хранилища во второй и уменьшим сложность с помощью веб-компонентов в третьей.
Всем привет!
Самостоятельное создание ноды HTTP Request может быть сложной задачей. Нужно самостоятельно искать и указывать эндпоинт, прописывать body для запроса и проставлять нестандартный заголовок авторизации, что совершенно неудобно и сложно для многих пользователей.
По вышеописанной причине мы решили разобраться в этой проблеме, и опубликовать собственную комьюнити-ноду n8n-nodes-amvera-inference, которая сможет помочь пользователям, без сложностей, работать с нашим Inference API нужной модели.
В статье мы расскажем и про саму разработку комьюнити-ноды, и про её установку с настройкой.
Команда JavaScript for Devs подготовила перевод статьи о том, почему JavaScript-сообщество снова проигнорирует шанс исправить фундаментальные проблемы своей экосистемы после крупнейшей атаки на цепочку поставок. Автор предлагает здравый план — от стандартной библиотеки до новых практик управления зависимостями, — но считает, что индустрия снова ограничится символическими жестами.
Все вокруг стараются сделать мир лучше, пишут редакторы, используют нейросети. Скука! Я решил пойти другим путём и создал "Лабораторию Абсурда" — которая намеренно и с особым цинизмом превращает любой осмысленный текст в лингвистический бред.
Не спорю, существуют и другие генераторы бреда, но я дарю вам 50 (или что-то около того) разных способов издевательства над текстом и здравым смыслом! Никаких рекламных баннеров, только ванильный JS и словари на тысячи слов, только хардкор!
Мир веб‑разработки давно вышел за пределы простых проектов. Статьи про «Hello, world» больше не спасают, когда нужно собирать масштабируемые приложения для реальных пользователей. Что выбрать — монолит или микросервисы? REST или GraphQL? React, Vue или Angular? Node.js, Python или Go? Какая база данных лучше подойдёт — реляционная или NoSQL? Нужно ли кэширование? Как настроить CI/CD, контейнеризацию и мониторинг? И почему нельзя забывать о мобильной версии и SEO? В этой статье я делюсь опытом, описываю архитектурные подходы, сравниваю основные технологии и инструменты, рассказываю о бэкенд‑ и фронтенд‑best practices, базах данных, кэшировании, DevOps, мониторинге и оптимизации. Каждая тема подкреплена примерами и ссылками на источники. Материал рассчитан на тех, кто хочет уверенно руководить полным циклом разработки — от планирования до продакшна. Если вы давно ищете структурированное руководство по современному фулл‑стеку, оно перед вами. Из этого путеводителя вы также узнаете об оптимизации производительности Node.js (gzip, асинхронность, логирование), работе с графами данных и типизации GraphQL, особенностях React (hooks, SSR), Vue, Angular, Tailwind и shadcn/ui, выборе баз данных, настройке кэширования Redis, задачах CI/CD и Dockerfile, Kubernetes, а также об инструментах мониторинга и SEO, включая мобильную адаптивность и структурированные данные. Текст большой, но разбит на разделы и содержит кодовые примеры, так что вы сможете легко адаптировать идеи под свои задачи.
Всем привет!
Меня зовут Прокошкин Леонид, я Frontend-разработчик в компании DDPlanet.
Хочу рассказать о том, как мы решали проблему с высокой нагрузкой на сервер и большими расходами трафика при использовании тяжелых Lottie-анимаций.
В проекте было около 30 Lottie-анимаций, некоторые весили ~100 KB, и нам нужно было оптимизировать их загрузку.
Как снизить трафик и нагрузку? Правильно - кеширование. Мы выбрали кеширование на стороне Service Worker.
Как правило, обучающие материалы сводятся к показу одного «правильного» решения. Такие решения можно попробовать запомнить, но они быстро забываются и не помогают по-настоящему понять алгоритм.
Меня интригует вопрос: возможно ли объяснение, которое позволит не просто заучивать формулы, а понять саму логику? И если такое объяснение существует, даст ли оно возможность решать похожие задачи — или даже помогает становиться лучшим программистом?
Сразу оговорюсь: мы не будем останавливаться на тривиальных проверках,
вроде пустого массива или некорректных параметров. Фокус статьи — на сути алгоритма.
В этой статье мы не просто посмотрим на готовый код. Вместо этого мы:
1. Разберем ключевую идею алгоритма на простом примере.
2. Сконцентрируемся на крайнем случае, в котором ошибается большинство.
3. Сравним два подхода к реализации — с закрытым и полуоткрытым диапазоном.
4. Увидим, как небольшие изменения в коде позволяют решать целый класс задач.
Недавно мне понадобилось реализовать автоматическую генерацию QR для личного проекта. Идея простая: пользователь нажимает на кнопку «Пригласить друга», а небольшая функция на JavaScript закидывает в буфер обмена реферальную ссылку.
Все было бы хорошо, но нужно было добавить попап с QR-кодом, который при сканировании перекидывает по ранее полученной ссылке. И так как писать собственное решение было сомнительной идеей, пришлось использовать библиотеку — QRious. В этой статье расскажу, как с ней работать.
Привет, Хабр!
URLPattern дорос до того, чтобы его можно было использовать как нормальный «роутер без фреймворка». В браузерах API уже поддерживается широким набором движков, а в Node 24 он доступен глобально без импортов. Один и тот же паттерн можно матчить и в Service Worker, и в HTTP-сервере на Node.
URLPattern — это примитив платформы для сопоставления URLам по удобному паттерну. Он матчится по компонентам: protocol, hostname, port, pathname, search, hash. Есть test и exec, named groups и опции вроде ignoreCase. Важный плюс в том, что у нас есть одинаковая семантика в браузере и в рантаймах, которые его тащат из той же спеки.
В Node 24 объект доступен глобально, как URL, без require('node:url'). Сам класс появился в 23.8, в 24-й ветке он отмечен как experimental, но доступ из коробки.
По поддержке в браузерах ситуация здоровая. По Can I use, URLPattern работает в актуальных ветках Chrome, Firefox, Safari, Edge, включая мобильные.
По крайней мере так сказал блогер Demimurych у меня в комментариях:
Дальше была беседа в комментариях, из который я вынес два хороших замечания:
Тему замыканий в языках программирования стоит рассказывать с проблемы функционального аргумента.
Реализация этой проблемы наиболее и единственно полно описана в ECMAScript спецификации.
Я потратил время и покажу, что нашёл!
Более 50 % приложений вызывают высокорисковые API браузера, что может быть признаком наличия вредоносного кода. Почти 64 % загружают скрипты с хостов за пределами РФ. Более 70% компаний рискуют получить штрафы от 1 до 18 млн. руб. за сбор ПД с использованием баз данных, размещенных за пределами РФ.
Разбираем результаты исследования безопасности frontend-приложений 3000 крупнейших российских компаний за первое полугодие 2025 года.
