JavaScript *

3 декабря 2025 года критическая уязвимость в серверных компонентах React (React Server Components, RSC) потрясла сообщество веб-разработчиков. Была обнаружена уязвимость React2Shell/React4Shell (CVE-2025-55182) с оценкой CVSS 10.0, что является максимальным баллом для уязвимостей. Ошибка позволяет удаленно выполнять код (Remote Code Execution, RCE) на любом сервере, работающем с RSC. В течение нескольких часов после обнаружения уязвимости китайские государственные группы и криптомайнинговые компании начали взламывать уязвимые серверы.

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

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

Мне очень нравится идея потоков данных в Node.js - data streams. Они используются всюду: чтение файлов, сетевые запросы, архивирование файлов.

Не путать с потоками выполнения процессов - threads! Это совсем другое!

Есть много хороших статей по философии, теории и применении потоков, Хабр не стал исключением:
Ментальная модель потоков в Node.js

Много раз я сталкивался с необходимостью реализовывать свои потоки данных. И каждый раз я путался с кучей методов: write, push, _write, _read, с кучей событий - end, close, finish. В чем отличие write от _write?! Буквально почти все время, когда я имею дело с потоками у меня открыты доки Node.js - https://nodejs.org/api/stream.html.

Недавно, в моей статье про кастомный транспорт для ShadowSocks мне потребовался функционал передачи разных потоков данных по одному потоку (каналу)данных. Это задача мультиплексирования данных.

Я думаю, что эта задача является хорошей практикой для новичков в Node.js и программистов, любящих кодить всякие алгоритмы.
Во время программирования я встретился с несколькими "программистскими задачами" aka "подводными камнями", которые мне пришлось решить, и это было увлекательно, что и вылилось в данную статью.

В работе над React-проектами код почти всегда живёт дольше, чем кажется на старте: требования меняются, команда растёт, появляются новые сценарии и интеграции. В таких условиях выигрывает не тот, кто «быстрее собрал», а тот, кто оставил после себя понятную структуру — с предсказуемой логикой, прозрачными зависимостями и минимальным количеством скрытых допущений. 

В данной статье мы расскажем о принципах «чистого кода» в React, которые используем в повседневной разработке, и покажем их на коротких примерах.

Здравствуйте, товарищи! Меня зовут Валентин, и сегодня мы снова поговорим про Atomic CSS! Обсудим имеющиеся проблемы в верстке и посмотрим, как атомарный подход их решает (или не решает). Разберем основные мифы, посмотрим на лучшие практики этого подхода и сделаем выводы.

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

Уже многие годы JavaScript остаётся «рабочей лошадкой» веба. Если вам нужно сделать то, что невозможно реализовать средствами HTML и CSS, то обычно найти решение помогает JS. И это замечательно! JS помог расширить возможности пользователей, а также стимулировал прогресс HTML и CSS!

Но время идёт, функции HTML и CSS расширяются, поэтому мы должны начать заменять старые и привычные решения на JS новыми, требующими меньше JS.

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

В этой статье я приведу несколько примеров; сможете придумать свои?

Знаете это чувство, когда открываешь контроллер в Express проекте, чтобы поправить одну строчку логики, и видишь ЭТО? Бесконечная вложенность, проверки на существование полей, ручной парсинг ошибок от базы данных и, конечно же, его величество try-catch, который занимает 80% файла.

Я тоже через это проходил. В каждом новом микросервисе я копипастил одни и те же функции обработки ошибок. В одном проекте я ловил ошибки Mongoose через err.name === 'ValidationError', в другом — через instanceof. Где-то мы отдавали { error: "message" }, где-то { status: "fail", msg: "..." }.

В какой-то момент мне это надоело. Мне захотелось инструмент, который я могу просто подключить одной строкой, и он сам поймет, что "E11000" от Mongo — это 409 Conflict, а ошибка Zod — это 400 Bad Request. При этом я не хотел тянуть в проект тяжелые зависимости.

Так родилась библиотека ds-express-errors. Сегодня я расскажу, зачем я ее написал и почему она может сэкономить вам кучу нервов.

Представление чисел в IT сфере - одна из самых простых вещей, которую интуитивно знает каждый разработчик, аналитик, тестировщик, админ (нужное подчеркнуть).

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

Точные определения и механизмы легко гуглятся.

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

Привет, Хабр! Меня зовут Андрей Слесаренко — frontend‑разработчик с опытом работы более 8 лет. Прошёл путь от джуна до тимлида, работал над разными высоко‑нагруженными проектами. В начале этого года начал активно использовать LLM‑агентов в повседневной работе — и за это время набил немало шишек.

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

Опыт одиночной разработки и поддержки долгоживущего веб-приложения: отказ от фронтенд-фреймворков, использование нативных возможностей браузера, работа с Core Web Vitals и влияние AI-поиска на трафик реального проекта.

TL;DR Автор в прошлой статье настроил Telegram-чат, куда несколько смартфонов скидывают пуши с помощью MacroDroid и/или Tasker. Проблема в том, что смартфоны брали на себя слишком много работы. Что, если они будут тонкими клиентами, которые шлют сырые данные на сервер, где уже происходит вся обработка и рассылка? Автор делится workflow и конфигурацией для n8n, которые позволяют это реализовать в режиме "Быстрого старта".

История о том, как одна критическая уязвимость (CVE-2025-55182) в серверных компонентах React привела к полному захвату нашего тестового сервера. Майнер, убитые системные процессы, сломанный GRUB и 10 часов борьбы за контроль. Разбираем хронологию взлома, наши ошибки и жесткие выводы о безопасности современной Full-Stack разработки.

Хабр, привет!

Меня зовут Стас Федянин, я ведущий инженер-программист в Контуре. Недавно завершился Advent of Code 2025 — в этом году он длился 12 дней вместо 25. Я участвовал, как и пять предыдущих лет. Созрел на эту статью, потому что подумал, что мой опыт и мнение будут интересны сообществу, ведь есть изюминка: каждый год я писал код на новом языке. Считаю, это отличный способ расширить кругозор. В статье делюсь нюансами всех опробованных языков.

🤖 Тысячи копий одного и того же алгоритма от Claude/Grok/ChatGPT торгуют друг против друга. Это создаёт спираль смерти, на которой зарабатывает только биржа через комиссии

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

Всем привет! Меня зовут Максим, и я работаю в ООО РТК ИТ руководителем направления в департаменте разработки и развития систем поддержки бизнеса (ОП ЮГ). В этой статье расскажу, как с помощью локальной языковой модели автоматизировал перевод Python-проектов в Node.js.Опишу технические детали реализации от сборки контекста до генерации файлов с кодом. Подниму вопрос масштабируемости, ограничений LLM при работе с большими проектами и возможных улучшений для повышения точности перевода.

Команда JavaScript for Devs подготовила перевод статьи о том, как на самом деле работают React Server Components. Автор разбирает RSC на уровне протокола: что именно стримится с сервера, как JSX путешествует по сети, почему состояние не ломается при обновлениях и зачем React вообще понадобился такой странный формат.

Меня зовут Алекс Гусев. В этой публикации я очень кратко раскрываю, почему переход с IntelliJ IDEA (PhpStorm) на VSCode ломает привычную работу с JSDoc в JavaScript-проектах.

Несмотря на весь технический прогресс IT, мне за всё время так и не удалось повстречать убедительное решение проблемы ввода «ghbdtn» вместо «привет» или «lf» вместо «да» — путаницы с раскладкой клавиатуры при наборе текста.

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

Я опишу реализацию решения для среды рабочего стола GNOME, проверенное на дистрибутивах Fedora 43 и Ubuntu 24.04.

Оптимизация в React почти всегда сводится к двум факторам: объёму работы, которую выполняет JavaScript, и частоте (а также «стоимости») перерисовок компонентов. Сам React работает достаточно быстро, но в крупных интерфейсах даже небольшие архитектурные промахи и на первый взгляд безобидные ререндеры начинают заметно бить по производительности.

В данной статье мы расскажем про ключевые подходы к оптимизации React-приложений: как уменьшить количество лишних ререндеров, сократить объём вычислений при вводе и скролле и снизить нагрузку стартового JavaScript.

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

Сколько будет корень из нуля? Даже школьник ответит не задумываясь: ноль. Но если задать этот вопрос JIT‑компилятору Maglev внутри движка V8, то при определённых обстоятельствах он сначала скажет: «ноль», а потом решит сэкономить на проверке безопасности и отдаст злоумышленнику доступ к памяти браузера.

Меня зовут Паша Кузьмин, я занимаюсь практической безопасностью Яндекс Браузера и проекта Chromium. В нашей команде мы регулярно разбираем уязвимости и исследуем методы атак — чтобы защищать пользователей до того, как их атакуют злоумышленники. Сегодня расскажу про CVE-2025-9864 — уязвимость, которую я нашёл в движке V8.

Это история о том, как безобидный Math.sqrt(0) превращается в use‑after‑free, а затем в произвольное чтение и запись памяти. Разберём проблему по шагам: от теории до работающего эксплойта.