JavaScript *

Я фронтенд-разработчик, и в одном из своих пет-проектов на 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 операторы: +, -, *, /, =, +=, -=, *=, /=, ++, --.

Однажды разработчики NEXT.JS решили сделать сервис для хостинга и получился Vercel. Они смогли предложить рынку облачную архитектуру, определяемую фреймворком, что дало великолепный пользовательский опыт.

Но в ряде случаев нужны аналоги Vercel. Особенно в России, где сайты на Vercel недоступны для многих пользователей с мобильного интернета из-за региональных ограничений. Да и не у всех есть возможность оплачивать платные тарифы долларовой картой.

Чтобы лучше представить альтернативы Vercel и их сильные и слабые стороны, я рассмотрю архитектуру самого сервиса и его конкурентов.

Сегодня посмотрим на вымышленный пример, как не надо делать стор. Любые совпадения - случайность. Все истории выдуманы.

Представьте: есть у нас герой Алекс. Перекидывают его на проект - «поправить пару простых багов, делов на пять минут». Открывает Алекс код, а там… У него сердце замирает. Подумаешь, с кем не бывает. Но внутри начинается дилема: просто пофиксить баги и забыть этот ужас как страшный сон, либо как настоящий богатырь проектов взять и отрефакторить весь этот бардак. Сделать по-человечески, заложить нормальную основу. Да, потом спросят за новые баги - ну и что. Зато внутри тепло разольётся, что не забил на плохой код и навёл порядок.

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

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

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

В этой части речь пойдет именно про сбор данных: как я сделал небольшой bridge-слой между банками и Obsidian. Во второй части можно будет уже перейти к тому, как эти данные встраиваются в vault.

Онлайн доска DGRM.net хранит данные в PNG-картинках. Вместе с вложениями файлы получаются большие. Рассказываю как сделано хранение данных в PNG-файлах.

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

Смотреть на то, как твой вылизанный бандл грузится рывками из-за отваливающихся узлов связи, больше нет сил. Все эти бесконечные битвы за 100/100 в Google PageSpeed, микро-оптимизации LCP и внедрение Edge-кэширования теряют смысл, когда пакеты просто не доходят до адресата.

И в какой-то момент я осознал простую истину: если ты не можешь остановить глобальную деградацию веба — возглавь её.

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

Встречайте: Шакализатор сайтов 3000.

Intl API широко доступен (за исключением Intl.DurationFormat, который работает во всех современных браузерах, но существует недостаточно долго, чтобы считаться «широко доступным») и может удовлетворить почти все требования к форматированию непосредственно в браузере, без загрузки кода и без необходимости его парсинга. Он также учитывает языковые предпочтения пользователей, поэтому даты и числа можно форматировать так, как им удобно, без дополнительных усилий.

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

Разработчики сталкиваются с выбором: использовать CSS Modules или CSS-in-JS решения. Эти подходы дают изоляцию стилей и интеграцию с компонентами, но различаются по реализации и ограничениям.

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

Данная статья не ставит цель назвать одного победителя. Вместо этого мы сравним основные подходы - CSS Modules и CSS-in-JS. 

Telegraph API обещает принимать content до 64 КБ, но на практике CONTENT_TOO_BIG прилетает уже на 17-20 КБ. Разбираю, как измерял реальный лимит, при чём тут UTF-8 vs UTF-16 для кириллицы, и каким обходным путём чинил молчаливую деградацию RU-канала.

Прошлой зимой я писал тут про «Мастерок» — строительный калькулятор на Flutter для RuStore. Приложение поехало в прод, набрало 4.9 звезды, и в какой-то момент пришло осознание: аудитория смартфонных приложений — это аудитория смартфонных приложений. А человек, который в обед нагуглил «сколько мешков ротбанда на 20 квадратов», в магазин приложений не полезет. Он хочет страницу в браузере. Желательно без куки-баннера на полэкрана, без интерфейса из 2012-го и без того, чтобы перед ответом на вопрос ему предлагали посмотреть пять реклам.

Так появился getmasterok.ru — веб-половина той же экосистемы. Сайт на Next.js 15, шестьдесят один калькулятор, ИИ-прораб, SEO, блог, всё как положено. И с одним неочевидным вызовом, который стал главным сюжетом этой статьи.

А вызов я нашёл не сам. Его нашёл пользователь.

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

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