Cтрого типизированная надстройка для JavaScript
Привет, Хабр. Расскажу, как устроен мой сайд-проект — пиксельная аркада Прикольня, где у каждой компании друзей своя 3D-квартира с мебелью, аватарами и контентом на стенах. Под капотом — Next.js 16, Three.js через React Three Fiber, WebSocket-мультиплеер и PWA. Без единого .glTF файла — вся мебель процедурная.
Когда разработчик начинает писать на Next.js с TypeScript, первая реакция часто довольно холодная. Вместо того чтобы двигаться быстрее, он начинает чаще видеть ошибки. Где-то не совпал shape объекта, где-то строка не подходит в более узкий тип, где-то TypeScript напоминает, что значение может быть undefined. На этом месте легко сделать неправильный вывод. Кажется, что TS просто добавляет трение и требует больше служебного кода.
Обычно проблема не в TypeScript, а в способе мышления. Если использовать его как набор аннотаций поверх уже написанного кода, пользы действительно немного. Но если смотреть на типы как на систему контрактов между слоями приложения, картина меняется. Особенно в Next.js App Router, где у нас постоянно есть границы server и client, внешний ввод из URL, формы, мутации и разные состояния интерфейса.
В этот момент TypeScript перестаёт быть типизацией ради типизации. Он начинает отвечать на более важный вопрос: какие состояния в проекте вообще допустимы, а какие не должны пройти дальше границы. По такой модели я выстроил один из своих проектов Workbench. Не начинать с мысли давайте везде поставим типы, а начинать с мысли где у нас проходит граница, что в неё входит и что из неё может выйти. После этого многие решения в коде становятся почти очевидными.
Одностраничный сайт с навигацией по якорям на Next.js: как синхронизировать скролл и URL без лишнего кода.
✨ Самоадаптирующаяся ИИ-система, актуализирующая критерии каскада ликвидаций
В 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 такая же история была. Мы пробовали: