JavaScript *

Обзор на браузерные 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 и гарантиям записи.

Рендерер Scratch имеет долгую историю связанных с SVG уязвимостей. Их источником становится то, что Scratch парсит сгенерированный пользователем (то есть контролируемый нападающими) контент в элемент <svg> и добавляет его в основной документ для выполнения различных операций (например, для измерения ограничивающего прямоугольника SVG более надёжным образом, чем viewbox или width/height).

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

Я считаю, что подход Scratch к санации SVG обречён на провал. Чтобы объяснить это, нам нужно совершить путешествие по истории санации SVG в Scratch и посмотреть, насколько хорошо он с этим справлялся.

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

Привет, Хабр! Меня зовут Даниил Подольский, я программист и архитектор, разрабатываю программное обеспечение и спецификации для создания ПО в YADRO. Вот уже девять месяцев я использую методологию Spec-Driven Development (SDD) в работе и управляю AI-агентами, которые пишут код. При этом я не считаю себя вайбкодером, потому что мой подход к работе более комплексный, чем просто «общение с AI».  

Это первая статья из цикла об оборудовании рабочего места SDD-кодера. Я расскажу о базовой настройке AI-агента Claude Code: что делать, если вы хотите оперативно и без перезагрузки переключать используемые модели и делать это для каждого проекта отдельно.

Я разрабатываю PWA для голосовой практики английского. Несколько раз пытался опубликовать его в RuStore через Trusted Web Activity (TWA) — Google-обёртку, которая упаковывает PWA в подписанный Android AAB. После четырёх отказов модерации я понял, что для моего класса приложений TWA в RuStore не работает, и за день переключился на Telegram Mini App.

Эта статья — не история стартапа, а разбор технических решений:

"Эта статья о том, как я n0x из просто болталки сделал агента который научился открывать браузер, делать скриншоты и выполнять команды

Вы когда-нибудь разговаривали с AI, и он в ответ на просьбу «открой Яндекс» писал вам: «Вот ссылка: https://yandex.ru»?

Я — да. И каждый раз мне хотелось сказать: «Спасибо, капитан Очевидность, я и сам это знаю».

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

В этой статье я расскажу, как добавил в проект n0x поддержку MCP (Model Context Protocol) — и научил AI-агента открывать сайты по команде «открой …».

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

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

В статье о глобальной области видимости в JavaScript, мы коротко коснулись темы затенений (бурж. variable shadowing), в данной статье мы рассмотрим это явление подробнее.

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

WebAssembly находится в разработке уже более 8 лет. Технология прошла долгий путь развития и недавно разработчики из Bytecode Alliance выкатили версию 3.0.

О WebAssembly уже много материалов, но сегодня нам важна сама суть. У нас есть возможность, воспользовавшись любым из доступных языков программирования, написать модуль с необходимой нам логикой и запустить в исполняемой среде браузера. Разработчики обещают: модули будут быстрее и безопаснее, чем JavaScript, а также созданные ранее технологии, наподобие asm.js.

На связи Борис Мещеряков, frontend-разработчик в ПСБ и чаще всего мне приходится работать с javascript-фреймворками - React, Angular и прочими. Узнав о WebAssembly, я какое-то время наблюдал за его развитием. Мне стало интересно, может ли новая технология помочь мне уже сейчас? Какие ее возможности существуют на данный момент и какие реальны в будущем?

Разберёмся вместе?

Привет!

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

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

📺 Vue на развилке роста: разбираем State of Vue 2026, чтобы понять, куда вложить время сегодня и не чинить стек завтра.

🤖 AI без иллюзий, но с результатом: от генеративных UI и reasoning-RAG до правил, которые уменьшают «переписывание ради переписывания» в код-ассистентах.

🛡️ Безопасность как конкурентное преимущество: сверяем npm-практики по OWASP, кейс Context.ai и экономику фейковых звезд, чтобы не привезти риск в прод.

🎨 Новый CSS вместо старых костылей: sizes="auto" и HTML в <canvas> показывают, как делать богаче интерфейсы и проще поддержку.

⚡ JS/TS и фреймворки под давлением масштаба: читаемость кода, ускорение Angular и обновления React/Vue как ориентиры для технических решений.

🧪 Инструменты, которые сокращают путь до релиза: автогенерация E2E, Excel через WebAssembly и процедурный звук для живого интерфейса.

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

Разбираем выгрузку Excel-отчетов в VK API через n8n v2.11.3. Лечим каскад ошибок: ERR_UPLOAD_BAD_SIGNATURE, потерю метаданных filename и баги узла HTTP Request v4.4. Внедряем паттерн «Absolute Context Hooking» через узел Code для стабильной передачи бинарных данных. Внутри — рабочая «таблетка» кода и настройки «без авторизации».

Привет, коллеги! 

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

Исходный код доступен по ссылке: https://github.com/Codesrc-public-ru/ralf-datapicker

За основу мы возьмем два реальных кейса. Первый - «AI-драфтинг», отлично описанный нашей статье "Создаем WCAG-доступный DatePicker на React: как Claude пишет основу, а мы доводим до ума". Идея: получить 80% кода от нейросети, а остальное довести вручную. Это путь быстрых итераций и реактивного решения проблем.

Второй - «Системный инжиниринг», подход описан в этой документации к инструменту https://github.com/snarktank/ralph. Идея: сначала детальное проектирование, потом итеративная работа модели. Это путь проактивного управления сложностью.

Оба приводят к результату. Но какой ценой? И что скрывается под капотом каждого из них? Давайте разберем.

Большинство UI-тестов флакают, медленно работают и в итоге отключаются в CI. Показываю альтернативу — изоляционные UI-тесты без стендов, таймингов и боли.

У меня был проект, где один Next.js сайт обслуживал несколько доменов, и возникла задача — эффективно кешировать страницы, чтобы не пересоздавать их каждый раз. Сначала я попробовал внедрить кеширование через Redis: я написал хендлер, подключил его, но вскоре обнаружил, что Redis потребляет колоссальный объём оперативной памяти — порядка 100 ГБ, и это при том, что ещё не все запросы были закешированы. Тогда я решил поискать другой подход и обратил внимание на PVC — общее хранилище, которое могли бы использовать все поды. Я начал изучать варианты работы с PVC и довольно быстро пришёл к идее общего кеш‑хранилища для всех подов. Я попробовал просто писать данные в PVC, но столкнулся с проблемой: каждый раз, когда под поднимался, он перезаписывал кеш. До тех пор, пока не подняты все поды, данные постоянно перезаписывались, а мне нужно было, чтобы первый под записал данные, а последующие только читали их. Я начал искать, как сделать кастомный кеш‑хендлер, но готовых решений не нашёл.

Привет, Хабр. Я b0w9r.

Полтора года назад мои знания в разработке находились на отметке 0.00. Кто‑то из вас, возможно, помнит мою историю: я начинал учить HTML и CSS, выписывая теги ручкой в тетрадь, потому что у меня не было не ноутбука не компьютера.

Я всё ещё иду по следам программирования, но недавно я сделал важный шаг — всего за 1 месяц я собрал и выкатил свой первый продукт: FocusMind (локальный рабочий хаб с Pomodoro, задачами и заметками).

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

Генератор GLSL-кода для WebGL, позволяющий писать шейдеры буквально на JavaScript с некоторыми условностями, используя все удобства IDE, такие как рефакторинг, подсветка синтаксиса, автокомплит и проверка на ошибки, а в математических выражениях использовать обычные JS операторы: +, -, *, /, =, +=, -=, *=, /=, ++, --.