JSX для Go: как маленькая разметка потянула за собой рантайм, компилятор и кучу компромиссов

[Opaspap]

а зачем вы клиентский код пишете на серверной стороне ? зачем у вас вообще фронтенд код смешан с бэкендом, почему бы просто не писать на ts ? в чем мотив этого php-like подхода ?

[graybuton]

Привет. Тут не серверный рендер и не пхп-like подход.

.gox компилируется в обычный Go, потом собирается в WASM и выполняется уже в браузере. Сервер в базовом варианте просто отдаёт html/wasm/статику. Если рядом есть Go-бэк, то это обычный API, а не место, где исполняется фронт.

Почему не ts - вопрос очевидный. Для продакшена ts сейчас несомненно практичнее. Мотивация проекта иная: проверить, можно ли писать ui с компонентами, состоянием и эффектами на Go, не доказывая при этом, что js/ts плохой.

Грубо говоря: фронт и бэк не смешиваются, просто экосистема одна.

[900k]

Можно было не проверять, это можно сделать хоть на C.

[graybuton]

Да, выполнить код в браузере через WASM можно хоть на Си, спору нет.

Но статья не про саму техническую возможность, а про эргономику: можно ли сделать поверх Go нормальный компонентный слой, разметку, состояние, эффекты, диагностику и сборку так, чтобы этим было удобно пользоваться.

"Можно запустить" и "удобно разрабатывать" - это разные задачи.

[Opaspap]

а, понятно, типа идея писать бизнеслогику фронта на Go, тогда всё понятно, например чтобы либы с бэкенда дешевле портировать было.

[jarick]

Прогоняли ли вы свой проект через js-framework-benchmark ?

Было бы интересно увидеть сравнение с leptos.