В 2026 году обновят JavaScript. Окончательный список изменений сформируется из проектов ECMAScript, достигших 4 этапа к марту. Но многие из них уже на заключительной стадии, а другие готовы и доступны в некоторых браузерах и средах. Под катом — что ждёт разработчиков и какие проблемы будут решены в этом апдейте.
Всем привет!
Долго я возился с маркдауном в своих проектах и, честно говоря, знатно подгорел. Первая проблема — это вечный выбор библиотеки.
С одной стороны, есть «конструкторы» типа unified, remark и rehype. Штуки мощные, но настраивать весь этот AST-конвейер и систему плагинов — это какой-то оверхед и лишняя сложность, имхо.
С другой стороны, есть @next/mdx, который вроде и ок, но слишком завязан на страницах и вообще не умеет работать на клиенте.
Раньше я обычно выбирал что-то вроде markdown-to-jsx или react-markdown.
DX у них приятнее, работают и на клиенте, и на сервере, весят мало.
Но вот беда: они «из коробки» не переваривают HTML или MDX, и ты снова вязнешь в настройке плагинов. А если добавить туда i18n (типа i18next или next-intl), начинается настоящий ад. Куча if/else в коде, чтобы отрендерить нужный язык, и бандл раздувается до небес. Плюс вечные косяки с front-matter. Ну и до недавнего времени всё это было только для React.
В общем, решил я написать свое решение для intlayer. Чтобы просто работало.
> К слову, за основу я взял форк markdown-to-jsx v7.7.14 (от quantizor), который базируется на simple-markdown v0.2.2 (от Khan Academy).
Когда пилил этот парсер, ставил перед собой такие цели:
- Максимально легкий вес
- Кросс-фреймворковость (React, Vue, Svelte, Angular, Solid, Preact)
- Простая настройка: никаких бесконечных цепочек плагинов
- Поддержка SSR и клиентского рендеринга
- Настройка на уровне провайдера: можно легко прокинуть свои компоненты из дизайн-системы
- Компонентный подход: полный контроль над рендерингом каждой части приложения
Здравствуйте, снова я — Дмитрий, React-разработчик. Все мы видели с вами такие карты, именуемые картойдами, в данном случае — карта России, я взял первую попавшуюся из интернета, для примера.
За 8 дней частичной занятости я собрал RAG-систему на NestJS + PostgreSQL (pgvector), которая обрабатывает ~11 000 чанков документов.
Первая версия отвечала около 4 минут, после оптимизации - 40–60 секунд.
Главный вывод: RAG - это не «векторный поиск + LLM», а в первую очередь подготовка данных, фильтрация контекста и аккуратная работа с промптами.
В этой статье мы познакомимся и детально изучим процесс создания приложения на кроссплатформенном фреймворке React Native. Рассмотрим, какие библиотеки понадобятся для работы, как правильно настроить структуру приложения, собрать его и протестировать его на различных устройствах.
Всем привет, на связи снова я — Дмитрий, React-разработчик. И сегодня хочу поднять тему, которая на первый взгляд кажется простой, но на практике может доставить немало сюрпризов - округление и форматирование чисел в интерфейсе.
Изначально может показаться, что здесь сложного практически ничего нет: есть toFixed() и toLocaleString(), но практика показывает, что реальные интерфейсы почти никогда в это не укладываются.
Почему? Потому что в разных диапазонах чисел пользователи ждут разного поведения.
Именно с этим сталкиваются разработчики при работе с таблицами, отчётами, финансовыми данными и аналитикой.
В этой статье я предложу функцию, которая решает определенные задачи округления и форматирования, и разберу, как она подбирает количество знаков после запятой в зависимости от величины числа
Ниже опишу требования к форматированию, которые легли в основу функции, и покажу, как они отражаются в коде и в интерфейсе.
localStorage кажется простым решением, пока приложение не начинает расти. useEffect, useState, рассинхронизация между компонентами, проблемы с SSR и отсутствие типизации быстро превращают его в источник багов и хаоса.
В этой статье я показываю, почему localStorage стоит рассматривать как external store, а не как обычный state React, и как правильно работать с ним с помощью useSyncExternalStore. Мы шаг за шагом усложняем реализацию: добавляем строгую типизацию, реактивность между компонентами и вкладками, поддержку sessionStorage, валидацию данных и SSR-совместимость — без Redux и лишней инфраструктуры.
Материал основан на реальном коде и практических сценариях. В конце я показываю финальную архитектуру и готовую библиотеку, которую можно использовать в продакшене, если вам нужен безопасный и предсказуемый доступ к localStorage в React-приложениях.
Подход по компонентам — не новое понятие. Например, в экосистеме Vue vue-i18n поддерживает [i18n SFC (Single File Component)](https://vue-i18n.intlify.dev/guide/advanced/sfc.html). Nuxt также предлагает [переводы на уровне компонента](https://i18n.nuxtjs.org/docs/guide/per-component-translations), а Angular использует похожий паттерн через свои [Feature Modules](https://v17.angular.io/guide/feature-modules).
Даже в Flutter-приложении часто встречается следующий паттерн:
В этой статье мы разберем основные причины деградации производительности иммутабельных сторов в связке с React и рассмотрим подходы к написанию высоконагруженного кода, включая неочевидные и многим не знакомые.
Наступил 2026 год, и у меня были новогодние праздники для создания международного стартапа - единорога 🦄. Поставил себе цель - заработать миллиард денег, поэтому проект должен быть международный(мультиязычный), чтобы увеличить трафик. Чтобы успеть за две недели, я решил использовать vibe-кодинг, а то потом ещё к ЕГЭ готовится.
VIBE-кодинг
Для написания кода я использую cursor.com версию pro - стоимость 20 $. Забегая вперёд, скажу что есть лимит токенов, и за пару неполных недель я сжёг лимиты токенов 3-учёток на проект.
У React-разработчика две беды:
1. Целевые данные изменились, а ререндера нет.
2. Целевые данные не изменились, а ререндер есть.
Есть много вариантов подружить данные с интерфейсом, в рамках данной статьи я пройдусь по самым популярным из них. Выясним, как они устроены и для чего каждый из них подойдет лучше, обсудим конкретные реализации разных паттернов.
Ранее публиковал теоретическую часть по рекурсивным импортам, желательно ознакомиться перед тем как продолжить, чтобы было общее преставление.
Рекурсивные импорты рассмотрим на примере React/Redux приложении.
Исходный код приложения опубликован тут, можете склонировать и попробовать самостоятельно исправить ошибки. Так сказать закрепить теорию на практике.
Evershop https://evershop.io — опенсорсная платформа для создания интернет-магазинов на Node.js. Платформа включает необходимый функционал: интеграции с платежными системами (Stripe, PayPal), админ-панель для управления заказами и контентом, систему промокодов и аналитику продаж.
Официальная документация Evershop не покрывает многие практические аспекты разработки. Данная статья — практическое руководство по созданию интернет-магазина на основе Evershop, включающее:
Пошаговую настройку проекта
Создание тем и расширений
Решение типичных проблем и необходимые патчи
Описание внутренней архитектуры для разработки кастомных решений
Для корректной работы некоторых функций (например, PayPal) и избежания ошибок при оформлении заказов необходимо применить патчи, описанные в статье. Рекомендуется прочитать материал полностью перед началом разработки, это сильно облегчит вам жизнь, если вы решите создавать Evershop приложение.
Что сделала уязвимость react2shell c моим сайтом на nextjs 15, как мне удалось понять, что это именно она и что я предпринял чтобы снизить риски.
Во многих случаях при разработке веб-сервисов и сайтов возникает необходимость в поиске готовых UI-компонентов — как для вдохновения, так и для ускорения работы над интерфейсом. Подобные решения будут полезны всем, кто занимается веб-дизайном и веб-разработкой.
В статье представлена подборка ресурсов с качественными и интересными UI-компонентами. Список будет дополняться по мере появления действительно достойных сайтов и сервисов.
❕ - пометка нового контента в статье.
[Статья обновлена 15 января 2026 года]
Баг с модульными стилями на динамически импортируемых компонентах в Next.js до 15 версии и немного о том, как работают стили в старых версиях Next.js.
3 декабря 2025 года критическая уязвимость в серверных компонентах React (React Server Components, RSC) потрясла сообщество веб-разработчиков. Была обнаружена уязвимость React2Shell/React4Shell (CVE-2025-55182) с оценкой CVSS 10.0, что является максимальным баллом для уязвимостей. Ошибка позволяет удаленно выполнять код (Remote Code Execution, RCE) на любом сервере, работающем с RSC. В течение нескольких часов после обнаружения уязвимости китайские государственные группы и криптомайнинговые компании начали взламывать уязвимые серверы.
В этой статье подробно разбирается, что и почему произошло, а также как незначительное, на первый взгляд, проектное решение в протоколе React Flight превратилось в одну из самых серьезных уязвимостей React в 2025 году.
Мы также обсудим, как защитить себя и как эта уязвимость подчеркивает важнейшие принципы безопасности.
В работе над React-проектами код почти всегда живёт дольше, чем кажется на старте: требования меняются, команда растёт, появляются новые сценарии и интеграции. В таких условиях выигрывает не тот, кто «быстрее собрал», а тот, кто оставил после себя понятную структуру — с предсказуемой логикой, прозрачными зависимостями и минимальным количеством скрытых допущений.
В данной статье мы расскажем о принципах «чистого кода» в React, которые используем в повседневной разработке, и покажем их на коротких примерах.
В прошлой статье я показал как скриптами перевести 10 000 строк на 3 языка. Скрипты оказались полезными - решил оформить в npm-библиотеку.
Теперь вместо копирования 4 файлов: npx i18next-toolkit update - и готово.
Команда JavaScript for Devs подготовила перевод статьи о том, как на самом деле работают React Server Components. Автор разбирает RSC на уровне протокола: что именно стримится с сервера, как JSX путешествует по сети, почему состояние не ломается при обновлениях и зачем React вообще понадобился такой странный формат.
