TypeScript *

По мере роста продукта регрессионное тестирование быстро становится узким местом: количество сценариев растет, время проверки увеличивается, а цена ошибки перед релизом становится выше. В нашем случае переход к E2E-автотестам стал способом ускорить регресс и основой стабильных, предсказуемых релизов. В статье делимся тем, как мы выстроили покрытие регресса автотестами и встроили его в рабочие процессы команды.

Немного о проекте

Проект представляет собой распределенную систему, состоящую из двух web-порталов на React, порядка двадцати микросервисов на .NET и нескольких интеграций со сторонними системами. Все компоненты участвуют в одном сквозном бизнес-процессе, а релизы выходят регулярно — в среднем раз в две недели.

QA-инженер подключился к проекту уже после начала активной разработки. В этот момент мы осознанно отказались от наращивания объемной ручной тестовой документации и сделали ставку на E2E-автотесты.

Почему Е2Е?

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

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

Привет!

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

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

Медиа · TanStack Router и маршрутизация в React · Pinia и будущее Vue (Эдуардо Сан Мартин)

AI · Агентное будущее Next.js · AGENTS.md по-новому (Эдди Османи) · Вайб-кодинг и ценность кода (Маттео Коллина) · Таймлайн LLM за 10 лет

Безопасность и браузеры · OWASP для агентных приложений (Auth0) · Firefox 148 setHTML() вместо innerHTML · CSS corner-shape в Blink (Chrome)

CSS · Псевдокласс :near() · Смерть скролл-фейду (Крис Койер) · x86 на чистом CSS/HTML

JS/TS · Зелёный дизайн интерфейсов (Смэшинг) · Полифил switch · TypeScript v6 beta · TSSLint v3 · Асинхронные паттерны

A11y · .visually-hidden в 2026 (Дэвид Бушелл)

Фреймворки · React: React Doctor, SVAR Gantt, когда RSC тормозит · Angular: PrimeNG 19→21, Taiga UI CDK v4.72 · Vue: Nuxt на русском, VueUse

Разное и 3D · Ностальгия по вебу 90-х · Штраф Amazon 2,5 млрд за тёмные паттерны · WebGL composite (Three.js) · voxCSS и Mahjong

Представим ситуацию: идет тяжёлый спринт, вы выполнили кучу задач, написали тонну нового функционала, готовитесь к релизу и вдруг обнаруживайте, что часть фич перестала работать! Идёте разбираться и обнаруживайте, что оказывается бэкендер Вася в последний момент решил переименовать поля в json-е, а вам об этом не сказал!

Ситуация образная, но позволяет быстро обрисовать одну из болей во время разработки. В этой статье я бы хотел рассказать об одном из вариантов её решения в коде с помощью подхода Единого источника истины(Single source of truth).

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

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

B4 - инструмент обхода DPI на Go с веб-интерфейсом.

Хотелось сделать инструмент, который можно поставить на роутер или любой другой linux-девайс, открыть в браузере и получить работающий результат без возни с десятками аргументов командной строки.

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

Обычно мы разрабатываем продукт, проверяем соответствие рынку (Product-Market Fit) и только спустя месяцы или годы решаем: «Пора выходить на глобальный уровень».

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

Как же с этим справиться? Заморозить разработку на неделю и рефакторить каждый компонент?

В последнее время я вижу много решений, основанных на compiler-driven подходе. Обещание заманчивое: добавьте пару строк кода, и приложение «само» станет мультиязычным.

Однако есть существенные недостатки.

Вкладки браузера разрастались до 5 ГБ. Причина — эффекты в реактивной системе, которые продолжали жить после удаления компонентов из DOM: подписки на сигналы не очищались, замыкания удерживали ссылки на мёртвые узлы, а каждый переход по SPA множил «призрачные» обновления. Разбираем, как иерархия parent-child эффектов, привязка к disconnectedCallback через effectSet и WeakRef полностью решили проблему — без ручного управления подписками

Стек: React, TypeScript, ESLint 9, IDE: VS Code.

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

Хорошо, когда эта «шапка» имеет единый порядок: мы быстро можем увидеть, например, какие типы использует файл, много ли компонентов он содержит и т.п. Короче говоря – это ускоряет и точечный, и общий анализ файла. Ну и просто приятно, когда код содержится в порядке и подчиняется единым правилам.

Привет, Хабр! Последние несколько месяцев я пишу на фреймворке $mol. $mol очень крутая штука, но для иишки слишком мало информации в датасетах.

Агент постоянно что то да путал, и даже не смотря на типизацию в моле ( даже в css ) это всё очень долго кругами ходило.

Агент:

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

В прошлой статье я также упоминал, что у Сергея получилось запустить мой проект на Tauri в режиме разработки на Arch. Он поделился со мной информацией в issue на GitHub и тем самым внёс вклад в проект. Поэтому я решил попробовать исправить проблему на основе его issue. Заодно расскажу, что такое issue и как оно выглядит.

Заваривайте чай, доставайте вкусняшки — пора «снимать первый урожай помидор»! 🍅

Привет! Меня зовут Незар, я фронтенд-разработчик из Т-Банка. В 21 релизе Angular команда разработчиков представила экспериментальное API для построения реактивных форм с помощью сигналов. В статье подробно его разберем. 

Тому, кто знаком с классическими Reactive Forms в Angular, новый Signal Forms API покажется эволюционным шагом: те же мощные возможности, но с сигналами — а значит, с автоматической реактивностью, полной типизацией и меньшим количеством шаблонного кода. 

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

В современном мире веб-разработки выбор стратегии рендеринга сайта является одним из ключевых решений, определяющих его производительность, оптимизацию для поисковых систем (SEO) и пользовательский опыт. От того, как и где генерируется HTML-код вашего приложения, зависит скорость загрузки, интерактивность и даже стоимость инфраструктуры. В этой статье мы подробно рассмотрим основные типы рендеринга — Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR) и набирающие популярность React Server Components (RSC) — их преимущества, недостатки, влияние на SEO и производительность, а также приведем примеры технологических стеков для каждого подхода.

Статья будет полезна для всех кто занимается разработкой сайта(вайбкодеры, веб-разработчки итп.)

Привет, Хабр! 👋

Меня зовут Карлен, я Lead Fullstack разработчик в ITFB Group. Хочу поговорить о том, как превратить нейросеть из «игрушки» в настоящего компаньона, который усиливает ваши навыки 😎 Речь пойдет не об обзоре AI-инструментов (выбор оставим за вами), а об искусстве составления промптов — «разговорном интерфейсе» между вами и вашим digital-напарником.

Привет!

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

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

Медиа: Mastra Workspaces (свой «Claude Code»), Рич Харрис про RSC, безопасность фреймворков.

AI: безопасность агентов, пост-обучение LLM (Netflix), Brave Search API.

A11y: Axe MCP в DevTools, чеклист Shopify, role="presentation".

Браузеры: Interop 2026, WebMCP и ранний доступ в Chrome.

3D: 3D-труба на R3F, procedural snake на Three.js.

CSS: эластичный текст, pie chart, параллакс, пирамиды, вихрь, Ambient, освещение.

JS/TS: sql.js, Perspective BI, TS-дженерики.

React: State of React 2025, shadcn vs MUI, HighTable, FrankenTUI, Ant Design 6.3, оптимизация.

UX/UI: фоновые задачи, интерфейсы для агентов, семантические токены.

Тестирование: JIT Tests от Meta (тесты от LLM).

Разное: Electrobun, учебник математика/CS/AI, WarCraft 3 UI, npmx, Stockfish 18.

В этой, уже 3 по счету статье мы переходим к самому важному месту во всей архитектуре Capacitor — к плагинам.

Именно плагины делают из WebView полноценное мобильное приложение. С ними у Вас появляется доступ к камере, файловой системе, push-уведомлениям, Bluetooth и т.д.

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

как устанавливаются официальные плагины;

как работать с community-плагинами;

как мигрировать с Cordova;

и главное — как написать собственный плагин с нуля на реальном примере отправки SMS.

Google и Microsoft представили в ограниченном превью новую технологию — WebMCP. Это стандарт, который обещает кардинально изменить взаимодействие ИИ-агентов с веб-приложениями. Если вы уже знакомы с Model Context Protocol (MCP) от Anthropic, то WebMCP — это его идеологический наследник, перенесенный непосредственно на сторону клиента (в браузер).

⛔ Почему цена на рынке падает одной свечой

В 2026 году «купил и держал» это ставка на то, что выдержишь -40…-70% просадку без эмоционального или маржинального выхода. Рынок стал хрупким: каскады ликвидаций случаются несколько раз в год. Статичный холд больше не работает.

Разбираю математику падения

Когда тестов становится больше сотни, любая «красивая обертка» превращается в тыкву, если за ней нет архитектуры. Именно поэтому BDR - это не просто "красивая обертка".

Я никогда не был фанатом Cucumber. Да им даже толком не пользовался. Мне хватило просто посмотреть со стороны, сколько сил уходит у людей на поддержку всей этой магии с регулярками и текстовыми файлами. Это дорого. И технически, и по времени.

BDR (Business-Driven Reporting) — это не попытка «сделать как в Cucumber, только на TS». Это попытка выжить и не превратить 1000 тестов в ад поддержки. Сегодня разберем «железо»: слои, композицию и то, почему это работает без костылей.

1. Когда «просто оберток» мало

Скептики правы, если просто оборачивать каждый клик в BDR.step, вы получите тот же мусор, только в профиль. Масштабируемость — это про разделение ответственности.

Достаточно все поделить на три уровня абстракции. И это не «бумажные» правила, а способ не сойти с ума при рефакторинге.

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

Поэтому некоторые популярные сервисы вообще запрещают звонки из мобильного браузера и просто отправляют пользователя устанавливать нативное приложение.

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

Привет!

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

JS/TS: Evan You — Vite, Rust, VoidZero; State of JS 2025 и новый интерфейс npm (npmx).

AI: Transformers.js v4 в NPM; тест «заменит ли ИИ опытного дебаггера».

Фреймворки: React — ViewTransition, SSG-сравнение, календарь DayFlow; Angular — обзор v22 и демо проект на Genkit.

CSS и браузеры: гистограммы и подсветка поиска без JS; предпочтения размера шрифта из системы в Chrome.

Доступность и интерфейсы: когнитивная доступность (W3C), combobox vs multiselect, якоря и UX.

Разное: ограничения и вдохновение, «искусство неправильного взаимодействия», репортаж с t-sync.