Выбор технологического стека перестал быть делом только команды разработчиков. ИИ-ассистент, который берет на себя все больше кода, негласно стал еще одним участником проекта: чем строже типизирована система, тем точнее он работает.
На этом фоне интерес к Т3-стеку, созданному еще в 2022 году, вырос не случайно. Он хорошо ложится на новую логику разработки: один язык, сквозные типы, меньше ручных договоренностей между клиентом и сервером. Для человека это удобство, для ИИ — понятные правила, по которым проще писать код и реже ошибаться.
В Work Solutions мы ведем TypeScript-проекты, поэтому видим эту закономерность на практике. В статье разберем, как устроен T3 Stack, чем он отличается от MERN, почему стал заметнее в эпоху ИИ-разработки и каким командам действительно подходит.
Два языка на одном проекте
Веб-приложение почти всегда состоит из двух частей: клиентской и серверной. Фронтенд десятилетиями пишут на JavaScript, потому что браузер другого языка просто не понимает. Бэкенд выбирают свободно, например: PHP, Python, Go, Java. В итоге над одним продуктом работают две команды на разных языках, с разными инструментами и разным взглядом на данные.
Проблема не в самих языках, а в границе между ними. Фронтенд отправляет запрос, бэкенд отвечает, и на этом стыке типы данных приходится согласовывать вручную. Поле переименовали на сервере, забыли поправить на клиенте, и ошибка всплывает уже у пользователя.
Так появилась давняя идея: писать весь проект на одном языке. Раз фронтенд все равно на JavaScript, логично применить тот же язык и на сервере — через Node.js. Тогда одна команда закрывает весь цикл, а типы данных не теряются на переходе.
MERN: первая попытка единого языка
До T3 единый JavaScript-стек уже пробовали собрать. Самый известный пример — MERN: MongoDB, Express, React и Node.js. Весь проект, от базы до интерфейса, работает на одном языке. Про этот подход у нас есть отдельный разбор в блоге.
У MERN есть спорное место — выбор базы данных. MongoDB хранит записи как документы и не требует жесткой схемы. Это удобно, когда структура данных заранее неизвестна и постоянно меняется. Но большинство бизнес-приложений работает со связанными данными: заказы, клиенты, товары, платежи. Для них реляционные базы PostgreSQL и MySQL подходят лучше.
MongoDB стал выбором в MERN во многом благодаря популярности NoSQL-инструментов в тот период, а не потому, что подходит под любую задачу. Документная база — инструмент для своего класса проектов, и навязывать ее каждому стартапу было бы неправильно. Эту претензию новый стек учел.
Что такое T3-стек
T3-стек — это опенсорсный стартовый шаблон для сборки фулстек-приложений на TypeScript, где клиент и сервер работают на одном языке со сквозной типизацией от базы данных до браузера.
Стек создал американский разработчик Тео Браун (Theo Browne); в международном сообществе он известен как T3 Stack. Сначала это был просто список его рекомендаций на сайте init.tips, а в 2022 году сообщество оформило идею в утилиту create-t3-app. Сейчас проект значится на сайте автора t3.gg.
Название идет от сетевого псевдонима автора — t3dotgg. Это прием из сетевого сленга leetspeak, где цифры заменяют похожие буквы: «T» и цифра «3» вместе читаются как Theo — первая буква имени и еще три знака. Когда вокруг идей Брауна собралось сообщество, стек назвали в его честь — T3. А расхожая расшифровка «TypeScript, Tailwind, tRPC» — лишь удобное совпадение, официальным акронимом она никогда не была.
Цифра «3» удачно срослась с устройством стека. В его основе три уровня, которые TypeScript связывает в одно целое: база данных (Prisma или Drizzle), серверная логика (Next.js и tRPC) и клиентский интерфейс (React и Tailwind). Сам Браун формулирует три принципа: типобезопасность не опция; экспериментировать с инструментами только там, где от них легко отказаться; не использовать технологию без конкретной причины.
В основе стека два обязательных элемента: фреймворк Next.js и язык TypeScript. Next.js — это React, который умеет работать и на клиенте, и на сервере, поэтому отдельный бэкенд-фреймворк вроде Express уже не нужен. TypeScript добавляет к JavaScript строгие типы, поэтому ловит часть ошибок еще до запуска.
Остальные части подключают по желанию: Tailwind для верстки, Prisma или Drizzle для работы с базой, NextAuth для авторизации. Все это собирается через один установщик create-t3-app, где каждый кусок можно включить или выключить.
Главную проблему стыка решает связующее звено — tRPC. Библиотека позволяет вызывать серверные функции прямо с клиента, как обычные функции, и типы данных проходят сквозь всю цепочку без ручного согласования. Кодогенерация при этом не нужна, в отличие от GraphQL.
Пример показывает, как tRPC связывает серверную процедуру и клиентский вызов: входные данные проверяются через Zod, а TypeScript заранее знает тип ответа.
На схеме ниже та же логика в обобщенном виде: тип, объявленный в серверной процедуре, автоматически доступен клиенту — TypeScript не дает ему исчезнуть на границе.
Сквозная типизация через tRPC: Клиент и сервер работают с одними типами — без ручного согласования
Принцип «bleed responsibly»
У авторов стека есть правило, которое они называют bleed responsibly — рисковать с новыми технологиями только там, где цена ошибки невелика. Молодую библиотеку tRPC они берут охотно: это просто функции, отказаться от них легко. А базу данных оставляют на проверенном SQL и не ставят на экспериментальные решения.
Это правило отвечает на главную претензию к MERN. База в T3 — это PostgreSQL или MySQL через Prisma, а не документная MongoDB по умолчанию. Связанные данные хранятся в реляционной базе, как и нужно большинству проектов.
Чем T3 отличается от MERN
Оба стека держат проект на одном языке, но решают разные болевые точки. Удобнее всего видеть это в сравнении по ключевым параметрам.
| Параметр | MERN | T3-стек |
|---|---|---|
| Язык | JavaScript на фронтенде и бэкенде | TypeScript на фронтенде и бэкенде |
| Фронтенд | React | React внутри Next.js |
| Бэкенд | Express и Node.js | Next.js и tRPC |
| База данных | MongoDB, документная | PostgreSQL или MySQL через Prisma или Drizzle |
| Типы на стыке клиента и сервера | Согласуются вручную | Сквозные, без ручного согласования |
| Авторизация | Подключается отдельно | NextAuth в комплекте |
| Старт проекта | Сборка вручную | Установщик create-t3-app |
Почему интерес к T3 Stack вырос в эпоху ИИ-разработки
Популярность стека легко измерить: репозиторий create-t3-app собрал более 28 тысяч звезд на GitHub и стал стандартной точкой старта для типобезопасных проектов на TypeScript. А подтолкнул интерес другой тренд.
Рост T3 совпал с бумом ИИ-разработки и так называемого «вайб-кодинга», когда код все чаще пишет ИИ-ассистент, а человек только направляет. Для такого режима строгая типизация оказалась не формальностью, а опорой.
Когда весь проект на TypeScript, ассистент видит типы данных на всех уровнях и генерирует код точнее: реже придумывает несуществующие поля, ошибается на границе клиента и сервера. Ту ошибку, что модель все же допустит, компилятор поймает сразу, а не на продакшене. Единый язык вдобавок сокращает число зависимостей и установок, то есть в нем меньше точек отказа.
Мы давно смотрим в сторону полностью типизированных проектов на одном языке. T3 для нас не догма, по которой мы обязаны работать, а подтверждение направления: к тем же выводам про единый стек и строгие типы мы пришли своим путем.
Что это дает бизнесу
Единый стек — это не только удобство разработчиков. Для бизнеса это означает несколько вещей:
- Одна команда вместо двух. Фуллстек-разработчик на TypeScript закрывает и клиент, и сервер; а это значит, что не нужно держать отдельные фронтенд- и бэкенд-группы, а также синхронизировать их между собой;
- Проще найм и адаптация. Новый человек учит один язык, одну экосистему, а не два разных мира, поэтому быстрее начинает приносить пользу на проекте;
- Меньше ошибок на интеграции. Сквозная типизация убирает целый класс багов на стыке клиента и сервера, которые могли бы всплыть уже после релиза;
- Богатая экосистема и поддержка ИИ. Готовые решения для типовых задач ставятся одной командой, а ассистент уверенно ориентируется в популярном стеке.
Кому подходит T3, а кому нет
Стек не универсален, как любые другие решения. Разберем, для каких задач он подходит лучше всего, и где выигрывают другие подходы.
Подходит:
- Продуктовым командам, которым нужен быстрый старт фулстек-приложения на одном языке;
- Проектам с активной ИИ-ассистированной разработкой. Сквозные типы повышают точность генерации;
- SaaS-сервисам, внутренним порталам, MVP и стартапам, где важны скорость и предсказуемость.
Стоит подумать дважды:
- Сервисам с экстремальной нагрузкой, жесткими требованиями к задержкам. Там выигрывает специализированный бэкенд, например на Go или Rust;
- Командам с сильной экспертизой и легаси в другом стеке — Java, Python, PHP: переход ради единого языка не окупится;
- Проектам, где основная ценность в тяжелой серверной логике, а не в интерфейсе. В таких случаях профильный монолит бывает уместнее.
Вывод
Выбор стека всегда отражает взгляд команды на сложность. T3 отвечает на вопрос, который прежде решали организационными мерами — договоренностями, ревью, документацией: как сделать, чтобы клиент и сервер не расходились сами по себе.
Именно этот вопрос оказался важным для ИИ-ассистентов: они работают точнее, когда контракты между слоями явные и машиночитаемые. T3 дает это из коробки, в этом смысле стек отражает не только нынешнее состояние разработки, но и ее направление.
Если вы выбираете стек для нового продукта, MVP или внутренней системы, важно смотреть не только на популярность инструментов, но и на архитектуру, команду, нагрузку и будущую поддержку. В Work Solutions мы помогаем оценить эти вводные и подобрать технологический подход под задачу, а не под тренды.
