Стандартный Go прогнать можно, но, скорее всего, это будет больше точка отсчета: бандл на стандартном компиляторе получается заметно тяжелее. Для браузера основной практичный вариант, как мне кажется, всё равно будет оставаться TinyGo
Поэтому GC/паники тоже надо смотреть аккуратно: у стандартного Go и TinyGo там разный профиль рантайма, и сравнивать "Go вообще" одной цифрой будет нечестно
А вот Leptos как ориентир - да, очень хороший кандидат. Я не жду чуда по памяти, но было бы полезно увидеть честные цифры: размер, старт, память, DOM-операции и деградацию на табличных сценариях.
Пока нет, через js-framework-benchmark ещё не прогонял.
Сейчас у проекта есть свои smoke/perf-проверки на dashboard, virtualized table, DOM/listener stability и размер wasm бандла, но это не то же самое, что нормальный сравнительный бенчмарк.
Сравнение с Leptos было бы интересным, да. Я не ожидаю, что Go с WASM на текущей стадии будет быстрее зрелых решений, особенно в сценариях с частыми DOM-операциями. Но как честная точка отсчёта - идея хорошая. Запишу себе в список.
Да, выполнить код в браузере через WASM можно хоть на Си, спору нет.
Но статья не про саму техническую возможность, а про эргономику: можно ли сделать поверх Go нормальный компонентный слой, разметку, состояние, эффекты, диагностику и сборку так, чтобы этим было удобно пользоваться.
"Можно запустить" и "удобно разрабатывать" - это разные задачи.
Привет. Тут не серверный рендер и не пхп-like подход.
.gox компилируется в обычный Go, потом собирается в WASM и выполняется уже в браузере. Сервер в базовом варианте просто отдаёт html/wasm/статику. Если рядом есть Go-бэк, то это обычный API, а не место, где исполняется фронт.
Почему не ts - вопрос очевидный. Для продакшена ts сейчас несомненно практичнее. Мотивация проекта иная: проверить, можно ли писать ui с компонентами, состоянием и эффектами на Go, не доказывая при этом, что js/ts плохой.
Грубо говоря: фронт и бэк не смешиваются, просто экосистема одна.
Да, вот эта часть мне и самому интересена.
Стандартный Go прогнать можно, но, скорее всего, это будет больше точка отсчета: бандл на стандартном компиляторе получается заметно тяжелее. Для браузера основной практичный вариант, как мне кажется, всё равно будет оставаться TinyGo
Поэтому GC/паники тоже надо смотреть аккуратно: у стандартного Go и TinyGo там разный профиль рантайма, и сравнивать "Go вообще" одной цифрой будет нечестно
А вот Leptos как ориентир - да, очень хороший кандидат. Я не жду чуда по памяти, но было бы полезно увидеть честные цифры: размер, старт, память, DOM-операции и деградацию на табличных сценариях.
Пока нет, через js-framework-benchmark ещё не прогонял.
Сейчас у проекта есть свои smoke/perf-проверки на dashboard, virtualized table, DOM/listener stability и размер wasm бандла, но это не то же самое, что нормальный сравнительный бенчмарк.
Сравнение с Leptos было бы интересным, да. Я не ожидаю, что Go с WASM на текущей стадии будет быстрее зрелых решений, особенно в сценариях с частыми DOM-операциями. Но как честная точка отсчёта - идея хорошая. Запишу себе в список.
Да, выполнить код в браузере через WASM можно хоть на Си, спору нет.
Но статья не про саму техническую возможность, а про эргономику: можно ли сделать поверх Go нормальный компонентный слой, разметку, состояние, эффекты, диагностику и сборку так, чтобы этим было удобно пользоваться.
"Можно запустить" и "удобно разрабатывать" - это разные задачи.
Привет. Тут не серверный рендер и не пхп-like подход.
.goxкомпилируется в обычный Go, потом собирается в WASM и выполняется уже в браузере. Сервер в базовом варианте просто отдаёт html/wasm/статику. Если рядом есть Go-бэк, то это обычный API, а не место, где исполняется фронт.Почему не ts - вопрос очевидный. Для продакшена ts сейчас несомненно практичнее. Мотивация проекта иная: проверить, можно ли писать ui с компонентами, состоянием и эффектами на Go, не доказывая при этом, что js/ts плохой.
Грубо говоря: фронт и бэк не смешиваются, просто экосистема одна.