Post by Руслан Касимов

Бунтари без причины. Как проект погубила страсть к технологиям Три года назад наше стремление к инновациям можно было описать одной фразой: «инженерный утопический сон». Мы были молодые и дерзкие, поэтому сразу нырнули на дно – просто чтобы проверить, как там дела. Это одна из историй, о которых я давно хотел рассказать. План был простой и сложный одновременно: связать Templ и HTMX и сделать полноценный фронтенд на Golang, а SPA просто прикрутить рядом. И, казалось бы, газ – делаем, бандл 15 Кб, летим в космос, доставай ракету и открывай шампанское. Не всё было так плохо: решение хорошее, но для огромной компании с почти бесконечными бюджетами. Технология надёжная, проще не придумать. Был выигрыш по скорости работы. Меньше зависимости от внешних JS-фреймворков и их дыр в безопасности с бесконечными обновлениями – в браузер уезжает минимум логики, значит и меньше поверхность для атаки. Плюс полная независимость от Vercel. Сказка? Сказка. И реализовать можно всё что угодно. Но: – Это было новаторство, которое мы не потянули: готовых компонентов под Templ и HTMX тогда просто не существовало – ни одной библиотеки, ни одного готового решения, всё приходилось писать и придумывать с нуля. (Сейчас, кстати, уже появились готовые UI-киты. Мы просто попали на самый старт, когда экосистемы ещё не было) – Логика сильно отличается: пришлось воевать с паттернами и мышлением, к которым мы все привыкли – На разработку простых вещей уходили недели. Экраны с элементарной логикой и фильтрацией, каждый стилизованный кастомный компонент – дропдаун, селект, инпут, кнопку, обновление данных мы реализовывали вручную – Подобное крупное изменение неизбежно тянуло за собой переделку архитектуры и вечный R&D – Разработка в рантайме Go нас просто добивала: никакого единого dev-сервера с HMR, как мы привыкли, нужно было поднимать и синхронизировать несколько процессов watcher'ов одновременно – Время на реализацию простой логики росло, а бизнесу был нужен продукт – не потом, а сейчас – Сотрудников под эту технологию просто нет. Есть несколько ключевых, кто начинал и разбирается, остальных нужно точечно набирать и переучивать. Возвращаемся ко второму пункту – Продукт до MVP всегда в текучем, незавершённом состоянии. На новой технологии каждый разворот ощущался болезненнее – каждый компонент, каждую строчку мы писали сами, без права опереться на готовое решение Какие выводы? При нескромных бюджетах и с чёткой целью – можно развивать. Технология быстрая и безопасная, но не нужна бизнесу, который запускает MVP. Путь точно не для маленьких команд, которым нужен продукт, а не технология. Прикольно, но больше так не делаем. Сначала продукт – потом всё остальное. Только если будет время и бюджет. Важная деталь! Это был наш внутренний проект-эксперимент. С клиентами мы всегда работали по классическим, проверенным паттернам. Мы попробовали, не справились и спокойно закрыли направление: не было ни ресурса, ни времени тащить его дальше