Comments 14
а зачем вы клиентский код пишете на серверной стороне ? зачем у вас вообще фронтенд код смешан с бэкендом, почему бы просто не писать на ts ? в чем мотив этого php-like подхода ?
Привет. Тут не серверный рендер и не пхп-like подход.
.gox компилируется в обычный Go, потом собирается в WASM и выполняется уже в браузере. Сервер в базовом варианте просто отдаёт html/wasm/статику. Если рядом есть Go-бэк, то это обычный API, а не место, где исполняется фронт.
Почему не ts - вопрос очевидный. Для продакшена ts сейчас несомненно практичнее. Мотивация проекта иная: проверить, можно ли писать ui с компонентами, состоянием и эффектами на Go, не доказывая при этом, что js/ts плохой.
Грубо говоря: фронт и бэк не смешиваются, просто экосистема одна.
Можно было не проверять, это можно сделать хоть на C.
Да, выполнить код в браузере через WASM можно хоть на Си, спору нет.
Но статья не про саму техническую возможность, а про эргономику: можно ли сделать поверх Go нормальный компонентный слой, разметку, состояние, эффекты, диагностику и сборку так, чтобы этим было удобно пользоваться.
"Можно запустить" и "удобно разрабатывать" - это разные задачи.
Сделать можно на чем угодно, вопрос в стоимости поддержки такого кода. Автор как раз пытается нащупать баланс между типизацией го и удобством разработки гуя
а, понятно, типа идея писать бизнеслогику фронта на Go, тогда всё понятно, например чтобы либы с бэкенда дешевле портировать было.
Чувак просто путает серверный рендеринг и сборку wasm под клиент. Бэкенда тут вообще нет, гошный код тупо крутится в браузере вместо js
Прогоняли ли вы свой проект через js-framework-benchmark ?
Было бы интересно увидеть сравнение с leptos.
Пока нет, через js-framework-benchmark ещё не прогонял.
Сейчас у проекта есть свои smoke/perf-проверки на dashboard, virtualized table, DOM/listener stability и размер wasm бандла, но это не то же самое, что нормальный сравнительный бенчмарк.
Сравнение с Leptos было бы интересным, да. Я не ожидаю, что Go с WASM на текущей стадии будет быстрее зрелых решений, особенно в сценариях с частыми DOM-операциями. Но как честная точка отсчёта - идея хорошая. Запишу себе в список.
Сравнение было бы интересно в контексте вечного холивара Rust vs Golang. Также интересно было бы понять, даёт ли GC какой-то эффект на перфоманс в WASM. Ну и у всех решений для WASM, на мой взгляд, ахиллесова пята - это потребление памяти. Я, конечно, не питаю иллюзий, но вдруг у Гошки получится что-то с памятью сделать.
Да, вот эта часть мне и самому интересена.
Стандартный Go прогнать можно, но, скорее всего, это будет больше точка отсчета: бандл на стандартном компиляторе получается заметно тяжелее. Для браузера основной практичный вариант, как мне кажется, всё равно будет оставаться TinyGo
Поэтому GC/паники тоже надо смотреть аккуратно: у стандартного Go и TinyGo там разный профиль рантайма, и сравнивать "Go вообще" одной цифрой будет нечестно
А вот Leptos как ориентир - да, очень хороший кандидат. Я не жду чуда по памяти, но было бы полезно увидеть честные цифры: размер, старт, память, DOM-операции и деградацию на табличных сценариях.
В wasm пока нет прямой интеграции со сборщиком мусора браузера, так что го тянет свой gc внутрь бандла. На частых изменениях дома это точно будет фризить интерфейс сильнее, чем нативный джс
Идея интересная, но некоторые архитектурные моменты могут послужить препятствием для adoption:
1. Custom JSX. Я бы рассматривал это как основной шоу-стоппер.
2. WASM - Зачастую пользователям нужно легковесное стендалон решение в одном файле.
Конструктивная критика:
1. я бы не отходил от JSX стандарта.
2. Рассмотрите вариант Standalone JSX Viewer. Размер файла особой роли не играет до тех пор, пока концепция 1 JSX viewer и multiple JSX configurations работает.
Со своей стороны: также создал JSX Viewer и тестирую последние полгода.
Формат JSX не менял, но пользовательский интерфейс строю на UI Framework, то есть из высокоуровневых UI компонентов.
Прямо в JSX Viewer встроил MCP-сервер, к которому можно подключиться из любой среды разработки, типа Cursor, и сказать AI Agent: customize the JSX configuration.
Получилось прикольно - один экзешник и куча конфигураций. Вовнутрь JSX Viewer интегрированы поддержки соединений с разными базами данных, RBAC, Mermaid и другая фигня, которая бывает полезна при быстром прототипировании.
Удачи.
Сборка через тайниго конечно спасает от мегабайтных бинарей, но там отваливается половина стандартной либы. А тащить обычный гошный рантайм с его gc в браузер - ну такое себе удовольствие для юзера
JSX для Go: как маленькая разметка потянула за собой рантайм, компилятор и кучу компромиссов