JavaScript *

В этой уже 5 по счету статье мы поговорим про актуальность локального AI в мобильных приложениях а также займемся интеграцией плагина для локальных LLM в Capacitor приложение.

Привет. Недавно пришлось повозиться с @tanstack/vue-table. Задача была стандартная: нужна таблица с сортировкой, фильтрами и редактированием ячеек. Казалось бы - идеальное время подключить готовое решение. Но не всё так гладко. Делюсь мыслями, граблями и тем, как я в итоге выкрутился.

Полностью браузерный терминал для работы с последовательными портами (COM-портами). Приложение не требует установки, работает прямо в Chrome или Edge, и при этом поддерживает все необходимые фичи для отладки микроконтроллеров, общения с сетевым железом или просто мониторинга UART-трафика.

https://github.com/GidroByte/web-serial-terminal-ru

Весь код одним файлом. Не требует компиляции и сборки, леко править обычным блокнотом — открыл и работаешь.

Привет!

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

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

📺 Если Next.js кажется слишком «магическим»: интервью с создателем TanStack — про client-first, type inference и честный выбор стека без маркетингового тумана.

🤖 Когда ИИ уже в проде, а контроля нет: от джунов без Copilot до паттерна «архитектор + разработчик», ревью агентских PR, «В поисках Мемо» (одна таблица в ClickHouse вместо Qdrant и Chroma) и on-premise на 4× RTX 4090 с водянкой — чтобы внедрять AI дисциплинированно.

🛡️ Один пропуск в npm — и секреты в CI утекают: атака на 84 пакета @tanstack, чеклист безопасности React (XSS, HttpOnly, CSP, Zod) и инициатива Mozilla WAICT — чтобы не узнавать об инциденте из новостей.

🎨 CSS и анимации без лишнего JS: safe-area-inset на реальных устройствах, забытые HTML/CSS-фичи, scrollytelling на scroll-state queries и портфолио на GSAP + шейдерах — чтобы интерфейс выглядел дороже, а код оставался прозрачным.

⚡ JavaScript и Node.js 26 без сюрпризов при миграции: orval из OpenAPI, когда цепочки .filter().map() вредят читаемости, Temporal и ломающие изменения в релизе от 5 мая — чтобы меньше гадать и быстрее обновлять рантайм.

⚛️ React-стек 2026 без ставки вслепую: патчи Next.js, local-first как data architecture, карта 60+ библиотек, Ant Design 6.4 и whisper.rn on-device — чтобы выбрать инструменты осознанно, а не по инерции.

🅰️ Angular и инфраструктура вокруг него: Taiga UI MCP для агентов.

📦 GitHub в России, интерактивная карта HistoryPrint на 13 000 событий, критика FSD, Safari TP 243, дизайн-система в DESIGN.md без дизайнера и сводка апдейтов Deno, Vite, Next.js, Vue и Tailwind — …и многое другое.

Как перестать копировать формы и построить масштабируемую архитектуру

В enterprise-приложениях формы множатся быстро: create, edit, import, create-from-lead, duplicate — и вот у вас уже шесть копий одной формы, а внутри условный ад из if (mode === …).

Почему mode prop и giant form component не масштабируются, как разделить форму на четыре слоя: presentation, orchestration, context, data source. Что такое capabilities и почему они лучше условной логики. Как адаптеры отвязывают форму от source entities. Куда прятать submit, валидацию и внешний store. Как тестировать такую архитектуру изолированно.

Да, я победил спам! Не «в основном», а «полностью и окончательно». Без всяких «почти». По крайней мере, на 99.9% победил. Причем этот 0.1% — не спам, прорвавшийся через фильтры, а false positives, которые не «вытащил» обратно в Inbox.

Программы и методы этой статьи могут быть адаптированны к любому из трех типов почтовых сервисов:

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

Покажу, как навести порядок – собрать линт-инфраструктуру в один пакет и выстроить систему контроля кода для всех репозиториев.

Если описать NestJS-архитектуру как граф — вершины это модули и классы, рёбра — зависимости между ними, — утверждение «архитектура не деградирует» перестаёт быть оценочным. Формально доказывается, при каких условиях циклы между модулями топологически невозможны, при каких размер публичного API не растёт с каждой новой ручкой, и при каких стоимость добавления фичи остаётся константой, а не растёт с числом существующих потребителей. Три измеримых структурных свойства, а не ощущение. Для типовой feature-based-структуры, которую сегодня продвигают как стандарт, ни одно из них не выполняется.

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 5 — финал серии. Архитектурный подход, при котором эти три свойства соблюдаются (Feature-Based Clean Architecture), нагружается тем же сценарием годового роста, под весом которого деградирует обычный feature-based: партнёрка, анти-фрод, рефералки, расширенная аналитика, утроение модуля пользователей. Без художественности: реальный код, граф зависимостей «до» и «после», и формальное доказательство трёх свойств — DAG-инвариант, граница связности, O(1)-стоимость инкремента — на языке теории графов. Точка, в которой «архитектура не деградирует» становится не похвалой, а конкретным структурным утверждением.

После трёх частей разбора деградации остаётся один вопрос: как написать NestJS-проект так, чтобы god-сервис и циклические зависимости были невозможны. «Писать аккуратнее», «лучше ревьюить», «выделять день в спринте на рефакторинг» — варианты, которые не работают: дисциплина не масштабируется на пятьдесят спринтов и пять команд. Работает другое — наложить на модуль структурные ограничения, которые TypeScript и NestJS DI просто не дадут нарушить. Слои, однонаправленные зависимости, изоляция домена от инфраструктуры — не папки ради порядка, а барьер, который физически не пропускает сценарии деградации из частей 1–3.

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 4 — конкретная имплементация подхода на том же сквозном Twitter-подобном бэкенде. Как модуль режется на четыре слоя (domain / use-case / infrastructure / presentation), как раздутый сервис заменяется набором use-case’ов, куда уезжает работа с базой и почему оркестратор перестаёт быть god-функцией. Без художественности: реальный код, что именно изменилось по сравнению с feature-based-структурой из частей 1–3, и точка, в которой видно — прежние сценарии деградации теперь не запускаются не потому, что «все стали аккуратнее», а потому что нечем.

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял.

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

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

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

Разбираю проблемы cross-platform onboarding между Telegram Mini Apps и native apps. Почему Android, iOS, Windows и Linux по-разному ведут себя при deeplink handoff внутри Telegram WebView.

Привет! Меня зовут Костя, я разработчик интерфейсов в ЮMoney. В этой статье разбираю, почему вкладка после возврата из фона начинает вести себя странно: интерфейс подвисает, таймеры съезжают, события приходят пачкой.

Материал особенно пригодится тем, кто делает сложные SPA с realtime‑обновлениями, WebSocket и насыщенным UI — CRM, дашборды, платёжные сценарии.

В статье разберём:

— как устроены Page Visibility API и Page Lifecycle API,
— зачем браузеры ограничивают фоновые процессы,
— что происходит при заморозке вкладок, системном сне и возврате страницы из BFCache,
— чем отличаются Chrome, Safari и Firefox,
— какие API уже устарели,
— а какие подходы помогают делать интерфейсы стабильнее в реальных пользовательских сценариях.

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации.

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

В прошлой статье я рассказывал, каково в одиночку тащить фуллстек-проект, который разросся до кино-соцсети. В комментариях несколько раз спросили про конкретику — «покажи код», «как сделал, что не выглядит как очередной пет-проект». Логично: дизайн — это то, по чему встречают. Поэтому держите вторую часть, уже техническую и с кодом. Без маркетинга, только решения, которые реально сделали интерфейс «дорогим», и пара бэкенд-хитростей в довесок.

Сразу дисклеймер: я не дизайнер. Всё нажито методом «смотрю на референсы (Letterboxd, Mubi, KinoPoisk HD) и пытаюсь повторить ощущение». Оказалось, премиальность — это не про дорогие шрифты, а про несколько повторяющихся приёмов. Разберём пять.

1. Акцентный цвет из постера фильма — фича, которая дороже всего «продаёт»

Самое заметное решение. Раньше у меня на всех страницах был один статичный фиолетовый акцент — и это выглядело дёшево и одинаково. Идея: пусть каждая страница фильма подсвечивается доминантным цветом его постера. Заходишь на мрачный нуар — интерфейс уходит в холодный синий, открываешь комедию — тёплый янтарь. Страница будто «сделана под этот фильм».

Делается без всяких ML, прямо в браузере через canvas: рисуем постер в крошечный буфер 32×48, усредняем цвета (выкидывая чёрные рамки и серость), переводим в HSL и принудительно «насыщаем», потому что постеры часто тусклые. Результат кладём в CSS-переменную — и весь интерфейс подхватывает её.

Привет, я Игорь Аникин, Frontend разработчик RUTUBE TECH. Медиадизайнер, специализируюсь на компьютерной графике. Увлекаюсь программированием более 15 лет.

Это небольшой мастер-класс, как визуализировать звук двумя способами. Текст подойдёт любому читателю, которому интересна выразительная часть цифрового мира.

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

Получится ли сделать полноценную 3D-игру на Qt Quick3D?

Именно такой вопрос у меня возник, когда я начал изучать Quick3D. Казалось бы, рендер и партиклы есть, базовая физика в лице Quick3D Physics тоже присутствует. Пример CharacterController из Qt указывал на то, что проблем быть не должно.

Но хотелось проверить это самому на чём-то реальном.

Поскольку моделлер и художник из меня никакой, да и в геймдеве опыта у меня меньше нуля, я решил переписать Quake — любимую игру своего детства. В ней я провёл сотни (тысячи?) часов, играя в мультиплеер на бесплатных серверах МТУ-Информ через модем US Robotics 33600.

В итоге получился проект Kwayk — попытка переписать Quake на Quick3D.

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

Мы разрабатываем продуктовый сайт на Angular 17 с микрофронтендовой архитектурой на Module Federation. Нам нужно было и хорошее SEO, и привычный CSR для пользователей. В итоге мы выбрали гибридный подход: для людей — клиентский рендеринг, для поисковых ботов — пререндеринг через доработанный сервис MTS botview.

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

Недавно я увидел видео, где маленький мальчик собирает кубик Рубика за 2,76 секунды (вот оно), и мне тоже захотелось научиться его собирать. Конечно, не за такое время, но главное — суметь сложить хотя бы за 10 минут. Главная проблема в том, что кубика у меня нет; можно купить, но это как-то скучно, на троечку. Поэтому я подумал: а почему бы не написать за выходные простой код, чтобы побыстрее посмотреть и покрутить кубик, а потом уже можно и купить. Заодно и разберусь, где что находится у кубика.