Разработчик под именем GoFrame опубликовал экспериментальный фреймворк, который позволяет писать интерактивные браузерные приложения на Go через WebAssembly - без JavaScript в качестве основы. Не манифест и не стартап. Просто честный эксперимент, который неожиданно вырос до компилятора, маршрутизатора и собственного синтаксиса разметки.
Что за зверь и откуда взялся
Всё началось с простого раздражения. Go - предсказуемый, типизированный, лаконичный. Но стоит добраться до браузерного интерфейса, и ты уже в другой вселенной: Node.js, бандлеры, плагины, отдельная экосистема. Разработчик решил проверить: можно ли перенести компонентную модель, состояния и обработчики событий в браузер, оставшись при этом в Go?
Так появился GoFrame. Его ядро - маленький WebAssembly-рантайм и формат .gox, напоминающий JSX из мира React. Разметка компилируется в обычные Go-вызовы утилитой goxc. Никакой магии - только трансформация синтаксиса в функции рантайма вроде gf.El, gf.Text и gf.Fragment.
Почему не просто вызовы функций
Формально интерфейс можно описывать и без .gox - вложенными вызовами Go. Счётчик с кнопкой пишется буквально в десяток строк. Но как только компонентов становится больше одного, читать такой код - всё равно что разбирать абстрактное синтаксическое дерево вместо страницы. Скобки побеждают смысл.
Именно поэтому появился .gox. Теги с маленькой буквы превращаются в HTML-элементы, атрибуты уходят в Props, события обрабатываются рантаймом. Снаружи - почти JSX. Внутри - чистый Go после компиляции. Казалось бы, просто сахар. Но за ним сразу встали лексер, парсер, генератор кода и диагностика ошибок.
Чем отличается от уже существующего
Автор честно изучил конкурентов перед стартом. Vecty - архивирован. Templ и htmx решают другую задачу: сервер отдаёт HTML, клиент обновляет фрагменты. Это работающие, зрелые подходы. Но GoFrame смотрит в сторону полноценного клиентского приложения - с локальным состоянием, эффектами, контекстом и файловой маршрутизацией.
- Компонентная модель с UseState и UseEffect - как в React, но на Go
- Файловая маршрутизация, вдохновлённая Next.js
- Сборка через goxc - от исходников до статического набора файлов
- Контроль размера WebAssembly-бандла как отдельная задача проекта
Что дальше и зачем это важно
GoFrame не претендует на продакшен. Автор прямо говорит: нет стабильного API, нет SSR, нет гидратации, нет LSP. Это исследование, а не релиз. Но именно такие эксперименты обычно двигают экосистему вперёд - медленно, через ошибки и переписанные концепции.
WebAssembly как платформа для Go в браузере перестаёт быть экзотикой. Размер бандла сжимается, рантаймы становятся легче, инструментарий взрослеет. Если GoFrame или что-то подобное найдёт ответы на открытые вопросы - компонентную идентичность, эффективный диффинг, нормальный DX - граница между Go-бэкендом и Go-фронтендом может стать заметно тоньше. Не завтра. Но направление понятно.
