Выбор технологического стека перестал быть делом только команды разработчиков. ИИ-ассистент, который берет на себя все больше кода, негласно стал еще одним участником проекта: чем строже типизирована система, тем точнее он работает.
На этом фоне интерес к Т3-стеку, созданному еще в 2022 году, вырос не случайно. Он хорошо ложится на новую логику разработки: один язык, сквозные типы, меньше ручных договоренностей между клиентом и сервером. Для человека это удобство, для ИИ — понятные правила, по которым проще писать код и реже ошибаться.
В Work Solutions мы ведем TypeScript-проекты, поэтому видим эту закономерность на практике. В статье разберем, как устроен T3 Stack, чем он отличается от MERN, почему стал заметнее в эпоху ИИ-разработки и каким командам действительно подходит.
Веб-приложение почти всегда состоит из двух частей: клиентской и серверной. Фронтенд десятилетиями пишут на JavaScript, потому что браузер другого языка просто не понимает. Бэкенд выбирают свободно, например: PHP, Python, Go, Java. В итоге над одним продуктом работают две команды на разных языках, с разными инструментами и разным взглядом на данные.
Проблема не в самих языках, а в границе между ними. Фронтенд отправляет запрос, бэкенд отвечает, и на этом стыке типы данных приходится согласовывать вручную. Поле переименовали на сервере, забыли поправить на клиенте, и ошибка всплывает уже у пользователя.
Так появилась давняя идея: писать весь проект на одном языке. Раз фронтенд все равно на JavaScript, логично применить тот же язык и на сервере — через Node.js. Тогда одна команда закрывает весь цикл, а типы данных не теряются на переходе.
До T3 единый JavaScript-стек уже пробовали собрать. Самый известный пример — MERN: MongoDB, Express, React и Node.js. Весь проект, от базы до интерфейса, работает на одном языке. Про этот подход у нас есть отдельный разбор в блоге.
У MERN есть спорное место — выбор базы данных. MongoDB хранит записи как документы и не требует жесткой схемы. Это удобно, когда структура данных заранее неизвестна и постоянно меняется. Но большинство бизнес-приложений работает со связанными данными: заказы, клиенты, товары, платежи. Для них реляционные базы PostgreSQL и MySQL подходят лучше.
MongoDB стал выбором в MERN во многом благодаря популярности NoSQL-инструментов в тот период, а не потому, что подходит под любую задачу. Документная база — инструмент для своего класса проектов, и навязывать ее каждому стартапу было бы неправильно. Эту претензию новый стек учел.
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 — рисковать с новыми технологиями только там, где цена ошибки невелика. Молодую библиотеку tRPC они берут охотно: это просто функции, отказаться от них легко. А базу данных оставляют на проверенном SQL и не ставят на экспериментальные решения.
Это правило отвечает на главную претензию к MERN. База в T3 — это PostgreSQL или MySQL через Prisma, а не документная MongoDB по умолчанию. Связанные данные хранятся в реляционной базе, как и нужно большинству проектов.
Оба стека держат проект на одном языке, но решают разные болевые точки. Удобнее всего видеть это в сравнении по ключевым параметрам.
Популярность стека легко измерить: репозиторий create-t3-app собрал более 28 тысяч звезд на GitHub и стал стандартной точкой старта для типобезопасных проектов на TypeScript. А подтолкнул интерес другой тренд.
Рост T3 совпал с бумом ИИ-разработки и так называемого «вайб-кодинга», когда код все чаще пишет ИИ-ассистент, а человек только направляет. Для такого режима строгая типизация оказалась не формальностью, а опорой.
Когда весь проект на TypeScript, ассистент видит типы данных на всех уровнях и генерирует код точнее: реже придумывает несуществующие поля, ошибается на границе клиента и сервера. Ту ошибку, что модель все же допустит, компилятор поймает сразу, а не на продакшене. Единый язык вдобавок сокращает число зависимостей и установок, то есть в нем меньше точек отказа.
Максим Соколовский
Руководитель проектного офиса
Мы давно смотрим в сторону полностью типизированных проектов на одном языке. T3 для нас не догма, по которой мы обязаны работать, а подтверждение направления: к тем же выводам про единый стек и строгие типы мы пришли своим путем.
Единый стек — это не только удобство разработчиков. Для бизнеса это означает несколько вещей:
Стек не универсален, как любые другие решения. Разберем, для каких задач он подходит лучше всего, и где выигрывают другие подходы.
Подходит:
Стоит подумать дважды:
Выбор стека всегда отражает взгляд команды на сложность. T3 отвечает на вопрос, который прежде решали организационными мерами — договоренностями, ревью, документацией: как сделать, чтобы клиент и сервер не расходились сами по себе.
Именно этот вопрос оказался важным для ИИ-ассистентов: они работают точнее, когда контракты между слоями явные и машиночитаемые. T3 дает это из коробки, в этом смысле стек отражает не только нынешнее состояние разработки, но и ее направление.
Если вы выбираете стек для нового продукта, MVP или внутренней системы, важно смотреть не только на популярность инструментов, но и на архитектуру, команду, нагрузку и будущую поддержку. В WS DEV мы помогаем оценить эти вводные и подобрать технологический подход под задачу, а не под тренды.
