19 июня 2026 года в alpha вышел TSRX — альтернатива JSX на базе TypeScript, которая обещает редкую для фронтенда вещь: один и тот же синтаксис для нескольких UI-рантаймов. Для русскоязычных команд это не просто еще один способ писать компоненты, а попытка вынести шаблонный слой над React, Preact, Solid, Vue и другими системами, не переписывая продукт под очередную модную идею.
О проекте сообщает InfoQ. TSRX создал Доминик Гэннэуэй — бывший инженер core-команд React и Svelte, известный по Inferno, Lexical и Ripple. Сам автор называет TSRX «духовным наследником JSX»: язык вырос из Ripple, а затем был отделен от конкретного фреймворка. На практике это означает, что компонент в одном файле с расширением .tsrx компилируется в код для разных целей через плагины вроде @tsrx/react, @tsrx/preact, @tsrx/solid, @tsrx/vue и @tsrx/ripple.
Идея здесь чуть интереснее, чем очередной синтаксический сахар. JSX давно живет не только в React, но почти везде остается компромиссом: логика управления рендерингом, стили, обработка ошибок и асинхронность часто решаются смесью соглашений, оберток и фреймворк-специфичных паттернов. TSRX пытается забрать часть этой рутины в сам язык. В шаблонах появляются конструкции уровня операторов: @if, @for, @switch и @try. Тело компонента заворачивается в контейнер @{ ... }, который заканчивается одним итоговым выводом. Есть сокращения для пропсов, отложенная деструктуризация и scoped CSS, который компилятор переписывает с уникальным хешем для селекторов.
Отдельно авторы делают ставку на то, что у UI-кода должны быть нормальные встроенные примитивы для ошибок и асинхронности. Вместо того чтобы навешивать на дерево компонентов специальные обертки, TSRX предлагает декларативные блоки @try, @catch и @pending. Для разработчика это выглядит как попытка привести фронтенд ближе к обычному языку программирования, где контроль потока не расползается по хукам, boundary-компонентам и кастомным соглашениям команды. Если идея приживется, часть споров о «правильном» способе писать компонент в React-подобных стеках просто потеряет смысл: язык задаст правила сам.
Почему вокруг проекта сразу поднялся шум
Причина не только в громком тезисе про замену JSX. У Гэннэуэя есть репутация инженера, который регулярно приходит с неочевидными, но технически сильными идеями. Плюс TSRX не пытается продавать еще один рантайм или «убийцу React». По своей роли он ближе именно к JSX: это авторский слой описания интерфейса, который дальше может потреблять разная экосистема. Такой заход сильно отличается и от Solid или Vue, у которых свои модели выполнения, и от Svelte, где синтаксис жестко связан с конкретным компилятором. Здесь ставка сделана на общий AST и плагины-генераторы, которые выдают идиоматичный код под целевую платформу.
Рынок отреагировал предсказуемо бурно. В анонсе на X у публикации набралось около 130 ответов и 1,6 тысячи лайков — для нишевого разговора о синтаксисе компонентов цифра показательная. На Hacker News мнения сразу разошлись. Один читатель написал, что ему нравится буквально все и не хватает только плагина для форматирования через oxfmt. Другой, наоборот, посчитал проект шагом не туда и заявил, что веб-разработке пора уходить от XML-подобного синтаксиса внутри JavaScript, двигаясь скорее к билдер-подходам в духе Kotlin или вычислительным выражениям из F#. То есть спор начался ровно там, где и должен был начаться: не о скорости бенчмарков, а о том, каким вообще должен быть язык для сборки интерфейсов.
Дополнительный вес обсуждению придал Райан Карниато, создатель SolidJS. Он отдельно разобрал, что TSRX может означать для разработчиков на Vue, Svelte, React, Solid и Mitosis. В пересказе InfoQ один из его тезисов звучит особенно болезненно для React-аудитории: новый подход потенциально позволяет уйти от части утомительных ограничений вокруг хуков. Для Solid, наоборот, картина менее однозначная: язык может конфликтовать с той прозрачностью вычислений, на которой держится философия фреймворка. Это важный момент: альтернатива JSX в лице TSRX не обещает одинаково удобную жизнь всем сразу. Где-то она снимает старые боли, а где-то привносит новые компромиссы.
Что это значит для команд и почему спешить не стоит
С практической стороны у TSRX есть сильный козырь: внедрение пофайловое. По данным InfoQ, файл .tsrx компилируется в эквивалентный .tsx-компонент, так что проект можно пробовать точечно, не переворачивая весь кодовой базой вверх дном. Для команд это редкая роскошь. Не нужно устраивать многомесячную миграцию, спорить о полном отказе от текущего стека и объяснять бизнесу, почему ради эксперимента внезапно встали все roadmap-задачи. Можно взять один сложный экран, где больно с условным рендерингом, ошибками и локальными стилями, и проверить, действительно ли новый синтаксис дает выигрыш.
Еще один плюс в том, что экосистема вокруг проекта на старте выглядит не декоративно, а вполне инженерно. В гайде по запуску упомянуты Vite, Rspack, Turbopack и Bun, а также Prettier, ESLint и отдельная утилита tsrx-tsc для проверки типов в CI. То есть авторы понимают, что фронтенд-инструмент в 2026 году оценивают не по красоте демо, а по тому, насколько быстро он встраивается в реальную сборку, линтинг и пайплайн. Если у новой технологии нет ответа на вопрос «что мне делать с этим в CI/CD», разговор обычно заканчивается раньше, чем начинается.
Но здесь же лежит и главное ограничение: TSRX пока находится в статусе alpha. Это не формальность и не кокетство автора перед релизом. Проект только вышел в открытый доступ под лицензией MIT, а дополнительные compiler target'ы еще обещаны, но не поставлены как завершенный набор. В той же публикации, на которую ссылается InfoQ, звучит вполне трезвый совет: экспериментировать можно, мигрировать продукт — нет. Для CTO, staff-инженеров и тимлидов это самая полезная строка во всей истории. Пока технология не прожила хотя бы несколько циклов доработки, не обзавелась зрелыми форматтерами, дебаг-историями и понятным поведением на больших кодовых базах, относиться к ней нужно как к лаборатории, а не как к корпоративному стандарту.
При этом сам сигнал для рынка важнее статуса alpha. Фронтенд явно устал от ситуации, где один фреймворк приносит удобный шаблон, второй — красивую реактивность, третий — приятную сборку, а собрать все вместе без vendor lock-in не выходит. Альтернатива JSX в виде TSRX бьет ровно в эту усталость. Если проект не провалится на этапе взросления, он может сместить дискуссию с выбора «какой фреймворк победит» к более скучному, но полезному вопросу: какой язык описания интерфейса переживет очередную смену моды в рантаймах. И вот это для отрасли может оказаться важнее самого анонса.