JavaScript *

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат.

Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой.

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

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

Правильная файловая структура - скелет любого фронтенд-приложения. В Vue 3 нет строгих предписаний, как раскладывать файлы по папкам, кроме базового разделения components/, views/. Но с ростом проекта хаотичное размещение кода быстро превращается в проблему. В этой статье разберём популярные подходы к организации Vue-проектов: от простейшего плоского до микрофронтендов.

Открываете очередной React-проект в 2026 году и смотрите на белый экран package.json. Какой роутер? Vite или Next.js? shadcn/ui или Mantine? Zustand или всё-таки Redux Toolkit? React Hook Form или TanStack Form? И как вообще теперь делать таблицы — TanStack Table или AG Grid?

Каждая из этих категорий за последние 2-3 года прошла через смену лидера. То что было стандартом в 2022 (Redux, Material UI, Webpack, styled-components, Formik), в 2026 либо в legacy-режиме, либо проиграло свежим конкурентам. Те кто работают в одной экосистеме годами, могут не заметить как сместились веса в соседних слоях стека — пока не открывают новый проект и не сталкиваются с тем что “стандарт”, которым они пользовались, теперь редко выбирают.

Эта статья — карта актуального React-стека 2026 года, разбитая по 60+ категориям. По каждой — что выбрал бы я для нового проекта в 2026, какие есть альтернативы для специфических случаев, что считается legacy и почему. Плюс — типовые комбинации стека под разные виды проектов (SaaS dashboard, collaborative editor, real-time dashboard, streaming app, consumer landing).

Уже не первый раз сталкиваюсь в проектах на Qt QML с проблемой управления диалогами и всплывающими окнами.

QML — декларативный язык и это здорово! Мы описываем, что хотим видеть на экране, и, если всё сделали правильно, при запуске программы получаем желаемый результат.

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

Первая — код начинает разрастаться. Даже если вынести диалог в отдельный компонент, его всё равно придётся «тюнить» каждый раз перед отображением, что не очень удобно.

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

Другой вариант, который тоже часто встречается — это обёртка диалога в Component и его непосредственное создание в нужный момент. С точки зрения потребления памяти это уже лучше, но проблему лишнего кода это не решает. Зачастую из-за подготовки такого диалога кода может оказаться даже больше. К тому же нужно не забывать вызывать destroy() для всех динамически созданных объектов, когда они больше не нужны.

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

Как и в предыдущие месяцы, по итогам апреля мы решили рассказать про то, как изменилась GigaIDE за прошедший месяц. Ниже краткий обзор обновлений PRO-функциональности GigaIDE, который можно найти на нашем маркетплейсе.

HistoryPrint берёт любой город и говорит, какая часть человеческой истории случилась в его радиусе. ~13 000 событий за 5 000 лет, 12 категорий (войны, революции, пандемии, открытия), скоринг по экспоненциальному убыванию расстояния, и в финале — один из 20 архетипов: «Born in Fire», «Plague Walker», «Heir of Enlightenment».

wkhtmltopdf долгое время был одним из основных инструментов для генерации PDF из HTML. Мы столкнулись с ним на собственном проекте, но, когда потребовалось реализовать сложные макеты, колонтитулы и повторяющиеся заголовки в многостраничных документах — возникли проблемы.

В этой статье — краткий обзор альтернатив (Headless Chrome, Puppeteer, Playwright, WeasyPrint, Gotenberg), их плюсы и минусы, а также наш итоговый выбор и подводные камни, которые всплыли в процессе внедрения.

Привет!

Это 15-й выпуск Frontend Status — дайджеста по фронтенд-разработке.

В этом выпуске:

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

⚛️ React Server Components и кеширование страниц: разбираем partial page caching, чтобы ускорять загрузку и снижать стоимость рендеринга без потери актуальности контента.

🤖 AI из «вау-демо» переходит в дисциплину: разбираем рабочие промпт-пайплайны и практики Claude Code, которые дают предсказуемый результат, а не случайный успех.

🛡️ Безопасность больше не факультатив: кейс критической уязвимости в GitHub и массовый багхант в Firefox напоминают, как быстро один пропуск превращается в инцидент.

🎨 CSS и анимации взрослеют: от scroll-driven подходов до нативной случайности и новых API, которые делают интерфейсы богаче без тяжёлого JS.

⚡ JavaScript и React на новом витке: ES2025/ES2026, типизированные контракты, React Compiler, TanStack Form и useHotkeys как база для масштабируемой фронтенд-разработки.

🌐 Стандарты и платформа двигаются вперёд: Baseline, Long Animation Frames, CBOR-LD и апдейты WebGPU меняют практику производительности и межплатформенной разработки.

…и многое другое.

В январе 2014 года мир сошёл с ума из-за игры, где нужно просто тыкать в экран. Flappy Bird приносила создателю $50 000 в день, пока он не удалил её из-за давления и бессонницы. Игру начали продавать на чёрном рынке вместе со смартфонами.

Я решил собрать свой веб-клон, чтобы понять, в чём же здесь магия. А в конце — откровенный список из 12 проблем, из-за которых мой клон всё ещё не тянет на оригинал.

Я хотел сделать простую штуку: написал пост один раз, а он сам улетел в Threads* и X*. С Threads всё оказалось почти скучно: официальный API, токен, два запроса, готово.

С X* началась отдельная инженерная прогулка по тёмному лесу: официальный API стоит денег, сервер из России напрямую ходит нестабильно, а браузерный GraphQL-путь то публикует, то отвечает 200 без созданного поста, то присылает 226, 344 или внезапное Tweet needs to be a bit shorter.

В этой статье разбираю, как я собрал кросспостинг через Cloudflare Worker, где достать auth_token и ct0, почему нельзя верить HTTP-статусу, какие лимиты и антибот-ошибки реально прилетают, и что показали две недели логов.

Расходы на AI API копятся незаметно: сессия Claude Code тут, batch к GPT-5 там — и к концу месяца биллинг удивляет. Собрал бесплатное Chrome-расширение, которое показывает траты Anthropic, OpenAI и Gemini в реальном времени прямо в badge браузера.

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья — продолжение предыдущей: Мой справочник по Feature-Sliced Design. На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD — архитектурной методологии для проектирования фронтенд-приложений.

В конце статьи есть ссылки на другие подходы к организации файловой структуры фронтенд-приложений.

Действия ИИ-агента в браузере через скриншоты и клики — минута и десятки центов. Через WebMCP — секунды и доли цента. Два порядка разницы.

Так что же под этим черновиком стандарта WebMCP и куда он нас ведёт?

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

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

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

Обзор на браузерные API, которые стали Widely available в апреле 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде.

Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем.

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

В моей коллекции лежат фильмы в формате Top-Bottom стереопары. Без 3D-телевизора или VR-очков смотреть их без потерь нельзя. Поляризованные очки и активные затворы на десктопе работают плохо или дорого. Анаглифные красно-синие очки убивают цвет.

Хотелось третьего варианта — смотреть на обычном мониторе, без очков, с минимальным железом. Идея, на которую опирался: head-coupled perspective, известный с 2008 года по знаменитому Wii-демо Johnny Chung Lee. В октябре 2025 бывший инженер Meta Daniel Habib опубликовал True3D — head-tracked Window Mode, где экран ведёт себя как окно в 3D-сцену. У них под капотом MediaPipe FaceLandmarker + iris tracking + off-axis projection matrix + volumetric scene на Gaussian splats. Я попробовал перенести подход на готовую Top-Bottom стереопару из коммерческих фильмов. И тут начались интересные компромиссы.

В статье — технический разбор моей реализации: пайплайн сглаживания трекинга в четыре ступени (EMA + velocity buffer + jump threshold + adaptive scaling), predictive tracker на double exponential smoothing (метод Холта) для компенсации end-to-end лага в 65 ms, фрагментный шейдер на GLSL с view switching и blend zone через smoothstep, попытка извлечения disparity через OpenCV StereoSGBM. Подробное сравнение моего подхода и True3D с таблицей: где в их волюметрической архитектуре получается то, что у меня в принципе невыводимо из двух фиксированных 2D-видов.

Финал — пять документированных проблем (jitter на резких движениях, ghosting в blend zone, потеря половины разрешения, латентность, UV-параллакс vs настоящий off-axis) и шесть открытых вопросов к читателю: про DepthAnything в WebGPU+ONNX, про RIFE/DAIN как view-интерполяторы, про DIBR на compute shader, про принципиальную возможность восстановить volumetric scene из стереопары в реальном времени.

Статья о том, как единый типизированный контракт позволяет получить проверяемые на этапе компиляции сервер, клиент и React-хуки — без кодогенерации и без дублирования типов.

Дисклеймер: все описываемые библиотеки носят экспериментальный характер — они созданы в рамках эксперимента. Несмотря на это, покрытие тестами у них достаточно хорошее.

С кэшированием в Next.js обычно случается одна и та же история. API уже отдаёт новые данные, страница открывается заново, а на экране всё ещё старая версия. После этого в код быстро добавляют cache: "no-store", данные начинают запрашиваться на каждый заход, и через пару минут появляется уже другой вопрос - зачем тогда вообще нужен встроенный механизм кэширования.

Проблема в том, что кэширование обычно звучит как одно явление, а на практике в App Router похожие ощущения могут давать разные уровни поведения. Навигация назад и вперёд может переиспользовать клиентский кэш маршрута, сам маршрут может рендериться по-разному, а серверный fetch в Next.js имеет собственные стратегии кэширования и перевалидации. В актуальной документации это уже разделено на новый режим с Cache Components и на прежнюю модель без них. В этой статье речь именно о привычной модели App Router без Cache Components, где поведение обычно задаётся через fetch, cache, next.revalidate и route segment config. (Next.js)

Полезнее всего разбирать такую тему не с теории, а с наблюдения. Не с вопроса как устроены все слои кэша в Next.js, а с вопроса почему на одном и том же маршруте иногда обновляется рендер страницы, а иногда обновляются данные, и это не всегда одно и то же.

Для примеров ниже используется проект Goods Finder и внешний API DummyJSON. Идея - сначала добавить на страницу штамп серверного рендера, потом отдельно показать момент получения данных, а уже после этого сравнить force-cache, no-store и revalidate.

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