TypeScript *

✨ Самоадаптирующаяся ИИ-система, актуализирующая критерии каскада ликвидаций

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

BIP39 вместо номера телефона, ECDH P-256 + AES-256-GCM, non-extractable CryptoKey, трафик неотличимый от HTTPS. Как это устроено, что сломалось в процессе и почему некоторые решения были болезненными.

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

Парсер‑комбинаторы и синтаксический анализ в целом — очень интересные темы. Однако материалов со сравнительно низким порогом входа маловато, а в существующих статьях на читателя сразу обрушивается поток терминов и формальностей.

Эту статью я позиционирую как введение в парсер‑комбинаторы «для чайников» (или «для самых маленьких» — как вам больше нравится). Цель: попытаться рассказать простым языком и с примерами так, чтобы Вы могли после прочтения написать свой парсер без какого‑либо предварительного опыта и знаний в области синтаксического анализа.

Приятного чтения!

TypeScript прочно закрепился в роли основного языка для типизированной разработки на JavaScript. Его система типов предоставляет множество мощных инструментов: дженерики, условные типы, продвинутый вывод типов – всё это позволяет строить надёжные и масштабируемые приложения. Однако даже в таком гибком языке есть ограничения. Одно из них – отсутствие нативной поддержки типов высшего рода (Higher-Kinded Types, HKT). Эта концепция, хорошо знакомая разработчикам на Haskell или Scala, позволяет абстрагироваться не только от конкретного типа (например, string или number), но и от типа-конструктора (например, Array, Promise, Set). Несмотря на то, что запрос на добавление HKT в TypeScript остаётся открытым уже много лет (issue #1213), сообщество научилось эмулировать эту возможность с помощью существующих средств. В этой статье мы разберём, что такое HKT, зачем они нужны в реальных проектах, и как их можно реализовать в TypeScript уже сегодня.

Привет!

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

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

📺 TanStack AI генерирует картинки, а не только чат-ботов.

🤖 Почему ИИ выдаёт глупый код — и трёхуровневая архитектура, которая это исправляет.

🎨 Математическая модель masonry-раскладки на Flexbox — с алгеброй, а не «работающим примером».

⚡ TypeScript 6.0, обновления безопасности Node.js, петиция против AI-кода в ядре Node.js и Kafka из Node.js по-взрослому.

⚛️ TanStack улучшил пропускную способность SSR в 5 раз, а Strawberry Browser переписал 130 000 строк с React на Svelte за две недели.

🅰️ Angular выпустила официальные скиллы для AI-агентов.

💚 Компоненты визуализации звука для Vue.js на Web Audio API.

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

Привет. Делаю расширение для VS Code, которое даёт OpenCode CLI полноценный графический интерфейс. Называется PrimeCode.

Суть простая: OpenCode — мощный CLI-агент, но работать с ним в терминале на длинных сессиях не всегда удобно. Хотелось нормально видеть, что происходит — tool calls, изменения файлов, контекст, токены. Не форк, не отдельный продукт — именно UI-слой поверх OpenCode, который общается с ним через SDK и SSE-стриминг.

Если вы уже работаете с OpenCode и у вас есть существующие сессии — можно продолжить работу с ними прямо через расширение. Вся история, контекст, tool calls — всё подхватывается.

Мне нравится направление, в котором движутся React и Next.js: нативные формы, Server Actions, меньше клиентского JavaScript, больше progressive enhancement.

На уровне идеи это очень красиво.

Но как только форма становится сложнее, чем одно поле email, выясняется, что вокруг нее снова появляется много однотипного glue code.

Как вырваться из замкнутого круга навязываемых акулами BigTech сомнительных технологий на простор устойчивого развития? Как сделать так, чтобы код внедряемой сейчас Дизайн‑системы — через пару лет опять не превратился в очередную, никому не нужную и максимально не удобную, «тыкву‑легаси»? Как выйти из дурного холивара с модными фреймворками на фронтенде и сделать библиотеку переиспользуемых компонент подходящую сразу для всех технологий и «на века»?)))

Ваша команда работает с большим количеством различных недокументированных проектов, основанном на одном визуальном языке? У вашей корпорации есть строгий брендбук и огромное количество клиентских веб‑сервисов написанных на разных фреймворках, которые по факту выглядят немного по‑разному в «одних и тех же мелочах»? Ваши фронты «пишут каждый свой фреймворк для дизайна заново каждый раз на каждом проекте»? Знакомо? UUI спешит к вам на помощь!

Мода на технологии все стремительней меняется, а браузер и простой интерфейс в нем остается. Вышел новый модный фреймворк и заказчику хочется проект именно на нем? Да пожалуйста! Легко! Так мы становимся максимально независимы от капризной и накаченной лоббированием индустрии реализуя основную задачу. Поставляя единый гайдлайн повсюду.

PSA (Project Specific Autocomplete) — плагин для продуктов IntelliJ

Хочу представить Вашему вниманию плагин для продуктов IntelliJ, который позволяет создавать:

Автокомплит на основе кода Вашего проекта

Переходы к определению элемента синтаксического дерева (на основе кода Вашего проекта)

Шаблоны кода, состоящие из одного файла (на основе кода Вашего проекта)

Шаблоны кода. состоящие из нескольких файлов (на основе кода Вашего проекта)//

Ссылка на репорзиторий здесь. Для подробностей, прошу под кат.

Шутка в тему по памяти не помню откуда:

- Слушай, а можно как-нибудь дома накачать интернет, а потом по дороге его использовать?

Да, заголовок желтушный. Но какие времена, такие и потребности.

Если отвечать на вопрос в общем виде, то для людей технически подкованных ответ очевиден. Никак, на то это глобальная сеть.

Но есть та часть ресурсов в Интернет, которые можно предварительно скачать и использовать также как и оригинал.

Эта 4 по счету статья является рефакторингом моей старой статьи про обновления бандлов приложения в capacitor. В этой обновленной статье мы еще раз рассмотрим механизм обновлений и ознакомимся с новой более структурированной реализацией.

Мы создали парсер openui‑lang на Rust и скомпилировали его в WASM. Логика была здравой: Rust быстрый, WASM в браузере даёт скорость, близкую к нативной, а наш парсер — разумно сложный, многоэтапный конвейер. Почему бы не захотеть его на Rust?

Но оказалось, мы оптимизировали не то, что нужно.

Почти три года я в одиночку строил бэкенд-фреймворк поверх Next.js App Router. По дороге мой ишью закрыл создатель C#, синтаксис подсказал Copilot, а три пакета-адаптера пришлось убить. Рассказываю, что вышло и какие грабли собрал.

Привет!

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

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

📺 Разговор с Машей Кондрашиной из Авито о том, что в IT больше не спорят из-за технологий.

🤖 VS Code переходит на еженедельные релизы благодаря AI-агентам, Chrome объясняет разницу между MCP и WebMCP, а Эдди Османи вводит термин «comprehension debt».

⚛️ React получает shadcn/cli v4 с режимом для агентов, SvelteKit ловит FOWL, Astro v6 подтягивает данные из API прямо в content collections.

🌎 Chrome 146, Mozilla за анонимность в вебе.

🎨 Брэд Фрост о дизайне в эпоху AI.

📦 Эмпирическое исследование утечек памяти на 500 репозиториях.

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

Vibe coding — это одновременно и мем, и реальность 2025-2026 года. Кто-то называет это будущим разработки. Другие считают, что это способ генерировать технический долг со скоростью света.

Мы решили попробовать создать коммерческий проект с нуля полностью с помощью вайбкодинга. В результате: 46 000 строк кода, полтора месяца, два человека. Проект работает, клиент пользуется.

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

В первой части я рассказал, что такое капсула, откуда берётся эта идея и зачем вообще упаковывать опыт. Если вы её не читали — советую начать оттуда, иначе дальнейшее может быть непонятным.

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

Знаете это чувство, когда сидишь на очередном спринт-планировании, команда пытается оценить таски, а планинг покер тормозит так, что успеваешь кофе сварить, пока карточка загрузится?

Вот у меня в AGG TEAM такая же история была. Мы пробовали:

Чувак, уже есть Pinia, Pinia Colada, TanStack Query для Vue, зачем ещё один способ управлять состоянием во Vue?

Меня просто задолбало писать везде флаги отслеживания состояния для действий и делать store через фабричную функцию, как это делали наши праотцы в начале 2000-х. Запоминать зоопарк из разных composable-функций и хуков. Изучать какую-то другую систему реактивности, типа MobX, тоже не хочу. Это какой-то зашквар.

Я хочу использовать то, что есть: реактивность Vue везде, классы, методы. Хочу использовать классические шаблоны: SOLID, DDD и т.п. Хочу, чтобы Действие или запрос сами отслеживали и сообщали своё состояние. Хочу сконцентрироваться на бизнес-логике и писать меньше шаблонного кода.

И это возможно, покажу, как это работает на примере.

Я не OpenSource разработчик, но за пару десятков лет написал под сотню enterprise-level библиотек, которые остаются в рабочем контуре, дорабатываются под каждый проект и адаптируются к новым технологиям. Большого смысла выходить в OSS не было, кроме как для упрощения обучения коллег и единого места хранения документации.

Но и желание помогать другим и делиться выстраданными подходами, экспертизой и конкретным кодом мне не чуждо - сегодня поможешь ты, завтра - тебе. Через полгода подготовки и адаптации к OpenSource (сам использую и дорабатываю около 8 лет) в свет выходит одна из библиотек моего рабочего контура - Reactive Route.

Так как я работаю с проектами на разных стеках, стараюсь писать код максимально framework-agnostic - независимыми слоями, которые можно заменить или переписать, не трогая остальной код проекта. А к фреймворкам и библиотекам для работы с состоянием они подключаются с помощью легковесных адаптеров, сохраняя синтаксис работы. Конкретно для Reactive Route выложил набор готовых адаптеров в комбинациях, которые сейчас чаще всего использую:

• React + MobX / Observable

• Preact (no compat) + MobX / Observable

• Solid.js + нативная реактивность / MobX / Observable

• Vue + нативная реактивность

В одном npm-пакете - строгая TS-типизация, SSR / MPA / no-JS / Widget режимы и тщательно протестированная отказоустойчивость. В статье не буду пересказывать документацию на русском и английском, а поговорю скорее про общие принципы качества, использование ИИ в разработке и почему многие библиотеки раздуваются, не успев даже стабилизировать ядро.

Сравнил полнотекстовый поиск PostgreSQL (tsvector/tsquery + GIN-индекс) с семантическим поиском через pgvector (cosine distance) на датасете из 10 019 товарных категорий Ozon.

Три embedding-модели:

GigaChat EmbeddingsGigaR (Сбер, 2560-мерные векторы, API)

Qwen3-Embedding-0.6B (Alibaba, 1024-мерные, локальный инференс через HF Text Embeddings Inference на GPU)

text-embedding-3-small (OpenAI, 1536-мерные, API)

Прогнал 18 запросов в пяти категориях: синонимы и сленг, intent-запросы в свободной форме, подарочная тематика, cross-lingual (EN-запросы к RU-данным), абстрактные формулировки. Замерил латентность и top-5 с cosine similarity score.

Разбор каждого запроса, таблицы и код — под катом.