ReactJS *

Иногда возникает странное ощущение, что фронтенд уже не про решение задач.
А про поддержание сложности.

Я в разработке ещё до AngularJS и React. Тогда всё было просто: HTML и немного JavaScript — и этого хватало даже для приложений с rich UI.

Потом пришли фреймворки.
Один из первых — AngularJS — и это был вау-эффект.
Ты больше не трогаешь DOM руками. Просто описываешь, что хочешь получить.

Потом: Flux, Redux, TypeScript, Angular 2+. Фронтенд в этот момент стал высокотехнологичным, но в то же время неприятным. Нужно писать кучу обслуживающего кода, не всегда понятно, как оно работает, возникают сложности с отладкой.

Tailwind отлично работает для быстрого прототипирования, но становится проблемой когда проект растёт. Разбираю три подхода к построению дизайн-системы на Tailwind — CVA, CSS-переменные и @utility — и объясняю почему каждый из них не решает проблему комбинаторного взрыва вариантов.

Недавно я обнаружил, что далеко не все знают об одной простой вещи — и это меня удивило.

Многие думают примерно так: «я описал интерфейс, указал что GET /users возвращает User[], TypeScript подсвечивает все поля, автодополнение работает — значит всё под контролем». Звучит разумно. Но есть одна проблема.

TypeScript работает только во время компиляции. В рантайме его нет.

Когда реальный ответ прилетает с сервера — никакой проверки не происходит. TypeScript просто верит вашей аннотации и молчит. Что реально вернул сервер — string вместо number, переименованное поле, отсутствующий объект — он не знает и знать не будет.

Вы узнаете об этом позже. Обычно от пользователей.

14 ошибок TypeScript. Такой был результат моего первого промпта в ChatGPT, когда я попросил написать тесты для React-компонента.

Через несколько месяцев тот же запрос "напиши тесты" выполняет мультиагентный пайплайн из 7 AI-агентов. Он сам планирует тест-кейсы, пишет код, проверяет его по философии RTL, а потом намеренно ломает компонент, чтобы убедиться, что тесты не врут. 40+ компонентов уже прошли через него на проде.

Это история про путь между этими двумя точками. Без прикрас, с тупиками и неработающими подходами.

В любом зрелом фронтенде проблема редко в том, чтобы написать еще один Button.

Проблема начинается позже. Когда у компонента уже есть десятки использований, Storybook, типы, обвязки, legacy-слои и пара человек, которые “чуть-чуть расширили API, потому что так было удобнее”.

В этот момент UI-kit начинает незаметно плыть.

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

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

Модальные окна — один из самых недооценённых слоёв UI-архитектуры. Формы, подтверждения, панели действий — в любом крупном проекте их десятки. И почти в каждом проекте их управление со временем превращается в хаос.

Не потому что разработчики ленивые. А потому что модалки обманчиво просты. useState(false) — и готово. Пока модалка одна, в одном месте, с одним набором данных — проблем нет.

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

В голосовых комнатах появилось нейросетевое шумоподавление. Фоновый шум, клавиатура, вентиляторы — всё это теперь фильтруется на лету. Для тех, кому важна экономия ресурсов, остаётся классический режим.

Добавили отложенные сообщения — пишешь текст, выбираешь время, и сообщение уходит само. Работает во всех типах чатов.

Поле ввода сообщений переработали: обновлённая панель форматирования, поддержка диаграмм и опросов прямо из тулбара.

На бэкенде пересобрали хранение данных о прочтениях и добавили индексы под основные запросы — снизилась задержка и ускорился вывод информации.

На дворе 2026-й, и за это время как React, так и Vue сделали гигантский скачок в развитии и создании экосистемы вокруг себя. Но статистика до сих пор беспощадна к Vue. На React в два раза больше вакансий, чем на Vue. Сколько я ни спрашивал React-инженеров, ответ был всегда один и тот же: «React для серьезных проектов, а Vue так уж».. Серьезно? Почему вы до сих пор так думаете?? Ну хоть один пример приведите, что нельзя сделать во Vue. Хотя бы потратьте 1 день на изучение экосистемы Vue 3 Composition API, Vue Router, Pinia - да вы после этого забудете про свой React. А про различные useState я вообще молчу, Vue тут вообще вас всех обошел с обычными ref. Это вы еще не слышали про keep-alive.

Я считаю, что такое мнение построилось из-за простой причины: люди просто поставили свою карьеру на React, вот почему они его защищают, а компании продолжают его использовать.

Предлагаю открыть портал в ад и задать вопрос, который сейчас, кажется, витает в воздухе у всех, кто связан с разработкой: фронтенд вообще еще жив? Или логичнее уже сейчас срочно переучиваться, пока через пару лет не пришлось делать это в панике?

Я задаю этот вопрос не как человек с десятилетним опытом, стабильной работой и философским спокойствием. Я задаю его как человек, который четыре года учился, чтобы войти в профессию, а вышел на рынок в момент, когда отовсюду слышно одно и то же: IT умерло, джуны никому не нужны, нейросети уже пишут код, а дальше будет только хуже.

Здравствуйте, меня зовут Дмитрий Карловский и я.. автор самого крутого на текущий момент (и в ближайшем будущем) фреймворка $mol. Вот уже десяток лет я рассказываю о заложенных в него идеях, которые конкуренты, если и пытаются повторить, то получается у них плохо. За это время вокруг него сложилось множество мифов, которые люди с радостью ретранслируют друг другу для самоуспокоения. Что ж, давайте соберём их все вместе, разберёмся, как они возникли, и как обстоят дела на самом деле.

Далее идёт развеивание мифов, касательно разработки "на $mol" в сравнении с разработкой "на React", как типичной ситуации в индустрии. Но вместо React вы смело можете подставлять любой другой его аналог.

Когда разработчик начинает писать на Next.js с TypeScript, первая реакция часто довольно холодная. Вместо того чтобы двигаться быстрее, он начинает чаще видеть ошибки. Где-то не совпал shape объекта, где-то строка не подходит в более узкий тип, где-то TypeScript напоминает, что значение может быть undefined. На этом месте легко сделать неправильный вывод. Кажется, что TS просто добавляет трение и требует больше служебного кода.

Обычно проблема не в TypeScript, а в способе мышления. Если использовать его как набор аннотаций поверх уже написанного кода, пользы действительно немного. Но если смотреть на типы как на систему контрактов между слоями приложения, картина меняется. Особенно в Next.js App Router, где у нас постоянно есть границы server и client, внешний ввод из URL, формы, мутации и разные состояния интерфейса.

В этот момент TypeScript перестаёт быть типизацией ради типизации. Он начинает отвечать на более важный вопрос: какие состояния в проекте вообще допустимы, а какие не должны пройти дальше границы. По такой модели я выстроил один из своих проектов Workbench. Не начинать с мысли давайте везде поставим типы, а начинать с мысли где у нас проходит граница, что в неё входит и что из неё может выйти. После этого многие решения в коде становятся почти очевидными.

Привет! Я Никита, Staff-инженер в крупном финтехе. В этой статье я хочу поделиться нашим опытом построения системы observability. Мы прошли путь от простых логов до сквозной трассировки, и я покажу, как это работает на фронтенде.

TL;DR: В статье разбираем опыт внедрения OpenTelemetry в крупном финтех-проекте.
Проблема: Логи без контекста не позволяют быстро найти причину 500-й ошибки в распределенной системе.
Решение: Сквозная трассировка (Distributed Tracing) от фронтенда до бэкенда.
Что внутри: Реализация CompositeLogger на TypeScript, патчинг fetch для сохранения контекста и примеры того, как превратить технические трейсы в карту бизнес-процесса. А именно - frontend реализация и практические детали интеграции.

Yandexbot заходит на ваш SPA сайт, получает пустой <div id="root"></div> и уходит. Именно так выглядит индексация большинства одностраничных приложений без SSR. Страницы не попадают в выдачу, органический трафик стоит на нуле, а команда недоумевает: сайт же работает.

Проблема не в качестве кода, а в архитектуре рендеринга. Поисковые роботы медленно или вообще не выполняют JavaScript, а значит, видят страницу до того, как ваш React или Vue успел что-то нарисовать. Настройка Server Side Rendering для индексации SPA приложений поисковиками решает эту проблему: HTML приходит уже готовым прямо с сервера.

Привет! Я Пётр Гришечкин, эксперт в области SEO для e-commerce. Последние 15 лет я проектирую системы кратного роста трафика для крупнейших сайтов. И последнее время пишу всякие околоSEO статьи – https://t.me/seo_and_sem

Это статья написано для начинающих frontend и backend разработчиков, которые хотят разобраться с технической SEO-оптимизацией. Здесь будут конкретные команды, примеры кода для React/Next.js, Vue/Nuxt.js и Angular, а также чек-лист внедрения.

На своём MacBook M4 я не замечал проблем. Два скрипта на Node.js 18 собирали информацию по проекту, обходили файлы, считали строки, агрегировали данные и отрабатывали за пару секунд. Жить можно.

А потом на созвоне коллега расшарил экран. У него удалённый рабочий стол, Intel Core i5-1035G1, 8 ГБ RAM. Он запустил тот же скрипт, и мы оба смотрели на терминал восемь секунд. В тишине.

Решил написать продолжение к предыдущей моей статье Операционная система Анна. Назвал "операционной системой" скорее как отсылку к фильму "Она" (Her) - понимаю, что это, конечно, не ОС в классическом смысле, так что прошу воспринимать это как художественное название, а не технический термин. Ну и вот недавно моя жена затеяла вести расходы в Google Sheets. Увидел её мучения о том, как создать формулы, листы и т. д. В итоге ей посоветовал поставить Анну на её домашний компьютер. При установке она настроила интеграцию с Google Sheets. Потом я ей посоветовал попросить Анну сделать следующее:

Когда говорят «React перерендерился» — обычно имеют в виду что-то расплывчатое. Новичкам это слово объясняет всё и ничего одновременно. В официальной документации процесс описан точнее: trigger → render → commit. Давайте разберём, что происходит на каждом этапе — без магии, зато с Fiber, флагами и браузерным пайплайном.

Когда разработчик приходит в Next.js из обычного React SPA, он часто тащит с собой старую схему мышления. Есть поле ввода, значит будет useState. Есть поиск, значит будет useEffect. Есть список данных, значит будем следить за изменением состояния и вручную запускать новый запрос.

На маленьком экране это вроде работает. Но очень быстро выясняется, что в приложении уже не одно состояние, а три. Есть значение в поле, значение в URL, данные, загруженные по одному из этих значений. Потом появляется четвёртая проблема. Кнопки Back и Forward начинают вести себя странно. Ссылкой на результат поиска неудобно делиться. А отладка превращается в угадайку, потому что не до конца понятно, что именно сейчас считается главным источником правды.

В App Router это решается проще. Если фильтр является частью состояния страницы, его логично держать в URL. Тогда схема становится прямой: URL изменился -> сервер прочитал searchParams -> выполнил fetch -> отрендерил новый список. В этот момент Next.js начинает восприниматься как понятный инженерный инструмент.

Предыстория

В октябре был в путешествии, за пару месяц до, наша компания как и многие компании в РФ стали переходить на свои мессенджеры в замен Telegram. У нас выбор пал на Mattermost, ну это такой, аналог Slack. За период примерно 3 месяца я столкнулся с максимально ужасным UI по моему мнению. Нет, проработка его очень отличная. Но вот трудности в самом представлении для пользователей — ужас.

Всем привет!

Меня зовут Михаил Витик, я работаю в Лемана Тех техлидом в сервисной команде, которая поддерживает команды разработки сайта Лемана ПРО.

Однажды у нас возникла задача — массово переписать стили во множестве проектов. При более близком рассмотрении эта рутинная задача оказалась типичным инженерным болотом: много однотипной работы, высокая цена ошибок. А главное, огромные временные затраты.

Эта задача и привела меня к идеям автоматической миграции, codemod‑трансформеров и использованию ИИ. В этой статье подробно расскажу о практическом опыте разработки автоматического мигратора кода на примере миграции с Linaria — CSS‑in‑JS решения — на CSS Modules.