TypeScript *

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

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

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

Когда мы говорим о сборщике мусора, мы часто ограничиваемся фразой «он удаляет неиспользуемые объекты», однако в реальности GC — это сложнейшая система, которая взаимодействует с виртуальной памятью, потоками, стеком, регистрами и графом ссылок, и без понимания этих взаимодействий невозможно осознанно писать высоконагруженные приложения. В этом материале мы сосредоточимся именно на GC, рассматривая его не как магию runtime, а как конкретный набор алгоритмов и инженерных компромиссов. За каждой строкой new, за каждой локальной переменной и за каждым вызовом функции стоит конкретная архитектура процессора, виртуальная память операционной системы и довольно агрессивная инженерная математика сборщика мусора. Чтобы действительно понимать GC, необходимо начать не с него, а с того, на чём он стоит — с регистров, стека и кучи, поскольку именно они формируют корневую модель, на которую опирается любой современный runtime.

Перед тем как мы начнем давайте разберемся в типах хранилищ памяти и как они работают:

Привет, Хабр! Последние несколько месяцев я пишу на фреймворке $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.

Сервис‑воркеры сегодня — не экзотика, а рабочий инструмент: offline‑режим, агрессивное кэширование, «живые» обновления и всё такое. Под это уже давно есть отличный, проверенный Workbox, и я сам с ним работал.

Но по мере того, как я таскал SW из проекта в проект, у меня всё чаще возникало ощущение, что мне нужен инструмент с другим профилем: поменьше магии и слоёв абстракции, попроще вход в код и в «как тут всё устроено», конструктор из маленьких плагинов, которые легко прочитать глазами и отладить.

Поэтому я написал @budarin/pluggable-serviceworker — не вместо Workbox, а как более лёгкий, типизированный и прозрачный рантайм для тех случаев, когда хочется полной управляемости и минимально возможной когнитивной нагрузки.

Привет, Хабр! Меня зовут Сергей, я фронтенд-инженер в Банки.ру.

В этой статье расскажу, как Zod помог нам перестать писать валидацию на уровне полей, подружился с React Hook Form и стал единым источником правды о структуре данных.

К Zod мы пришли не сразу. Долгое время типы и валидация у нас жили в разных слоях приложения: TypeScript определял структуру данных во время разработки, а отдельные функции или библиотеки (вроде Yup) проверяли входящие значения в рантайме.

Это классическая проблема: дублирование логики и рассинхрон. Типы в interface поменялись, а валидация осталась прежней (или наоборот). Мы пробовали Yup, но он казался громоздким в связке с TS: типы приходилось выводить вручную или мириться с тем, что схемы выглядят непрозрачно. В какой-то момент стало непонятно: зачем тащить отдельную библиотеку, если проще написать if (typeof x === 'string')?

С переходом на Zod всё стало значительно проще: одна схема одновременно является и валидатором, и источником типа данных.

В прошлой статье "Ваш отчет никто не читает: Как мы научили разработчиков понимать падения тестов за 30 секунд?" мы разбирали, как слой Flows и декораторы позволяют разрабам не тратить время на дебаг отчетов. Статья вызвала большой отклик, и сегодня я хочу раскрыть «фундамент», на котором строится этот подход.

Многие годы нам продают BDD (Behavior-Driven Development) как "серебряную пулю" для коммуникации...

Давайте честно, это чушь. Никогда не понимал, зачем мы кормим этого монстра по имени Cucumber. Тратим до 50% времени на поддержку регулярок («клея»), возимся с хрупкими .feature файлами и боимся переименовать шаг, потому что все развалится. При этом ни один менеджер в здравом уме не заходит в ваш репозиторий читать эти файлы. Они все смотрят только отчеты.

Так зачем нам Gherkin на этапе написания кода? Представляю вам новую методологию BDR (Business-Driven Reporting).

Почему классический BDD (Gherkin) — это ошибка?

Gherkin заставляет инженера работать внутри IDE, как в текстовом блокноте. Это абсурд.

📉🐻 Как ИИ получил руки для торговли на бирже

Claude Code уже разбирается в техническом анализе, умеет искать в интернете для фундаментального, может быть запущен удаленно на сервере с iPad через Claude Code on the web, умеет анализировать файлы логов сам программируя python скрипты.

Осталось ли собрать всё это в кучу...

Встав утром и посмотрев в профиль, отметил: на Хабре много лет, писал статьи, писал код. И ни разу не писал о коде на Хабре. А вообще‑то разработчик. Поззорище! Пора исправляться.

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

Ну и ещё слегка вспомним «Звездные войны»:-)

У нас случилась классика: бэкенд уже отдает данные, бизнес ждет экран «вчера», а фронтендера в команде нет и ближайшие фронты заняты.

Мы рискнули и собрали MVP‑интерфейс за неделю — без выделенного фронта, но на корпоративном стеке (Vue/TypeScript) и с дизайн‑системой.

Это не история «AI все сделал». Это история про то, как правила + дизайн‑система + ревью как для джуна могут делать из AI‑ассистента нормальный инструмент, а не генератор мусора.