Что такое Wails?
Wails - это легковесный фреймворк, предназначенный для создания кросс-платформенных GUI приложений рабочего стола на golang и стандартных веб технологиях (Svelte, React, Preact, Vue, Lit, Vanilla JS). Ближайшие аналоги это естественно Electron (JS), Tauri (Rust), хочется добавить Qt (С++), но это уже другой уровень. Сразу скажу, что Wails не идеален, имеет множество ограничений и в целом не подойдёт для чего-то крупного, Tauri к примеру более зрелый проект, больше функций, быстрее развивается, больше и живее сообщество, но это уже на rust, а это не наш стэк.
Ключевое отличие Wails и Tauri от Electron, в том, что последний таскает с собой chromium, тогда как Wails и Tauri используют встроенный в систему нативный браузер. В Windows - движок Edge, Webview2 (по сути chromium). В macOS - это движок Safari, WebKit. В Linux - WebKitGTK. Исходя из этого есть ограничения, к примеру поддерживается только Windows 10+, а в Linux вы устанете на этапе сборки и дистрибуции, так как зоопарк дистрибутивов и библиотеки с зависимостями (webkitgtk2) везде называются по разному.
Но у нас не было требований к какой-то огромной функциональности, почти всё базовое есть в текущей версии, не хватает пожалуй поддержки трея, нотификаций и открытия дочерних окон, но для первой версии мы решили, что это не критично. Да и вроде как медленно но верно развивается 3я версия фреймворка где функций станет больше и всё это появится!
И да, мы говорим о Wails v2.
Инициализация проекта
Чтобы вы понимали насколько легко начать, я покажу:
Устанавливаем Wails:
go install github.com/wailsapp/wails/v2/cmd/wails@latestУстанавливаем node.js:
nvm install --ltsnvm use --ltsЗапустите
wails doctor, он просканирует систему и подскажет что ещё установить:
Пример вывода wails doctor
$ wails doctor
Wails Doctor
# Wails
Version | v2.10.1
Package Manager | zypper
# System
WARNING: failed to read int from file: open /sys/devices/system/cpu/cpu0/online: no such file or directory
┌───────────────────────────────────────────────────────────────────────────────────────┐
| OS | openSUSE Tumbleweed |
| Version | 20250531 |
| ID | opensuse-tumbleweed |
| Go Version | go1.23.8 |
| Platform | linux |
| Architecture | amd64 |
| CPU | 12th Gen Intel(R) Core(TM) i7-1260P |
| GPU 1 | TU117GLM [T550 Laptop GPU] (NVIDIA Corporation) - Driver: nvidia |
| GPU 2 | Alder Lake-P GT2 [Iris Xe Graphics] (Intel Corporation) - Driver: i915 |
| Memory | 47GB |
└───────────────────────────────────────────────────────────────────────────────────────┘
# Dependencies
┌───────────────────────────────────────────────────────────────────┐
| Dependency | Package Name | Status | Version |
| *docker | docker | Installed | 28.2.2_ce-17.1 |
| gcc | gcc-c++ | Installed | 14-3.1 |
| libgtk-3 | gtk3-devel | Installed | 3.24.49+14-1.1 |
| libwebkit | webkit2gtk3-soup2-devel | Available | 2.48.3-1.1 |
| npm | Unknown | Not Found | 10.9.2 |
| pkg-config | pkgconf-pkg-config | Installed | 2.2.0-1.3 |
| |
└───────────────────── * - Optional Dependency ─────────────────────┘
# Diagnosis
Required package(s) installation details:
- libwebkit: sudo zypper in webkit2gtk3-soup2-devel
WARNING Your system has missing dependencies!
Fatal:
Required dependencies missing: npm
Please read this article on how to resolve this: https://wails.io/guides/resolving-missing-packages
♥ If Wails is useful to you or your company, please consider sponsoring the project:
https://github.com/sponsors/leaanthony
Инициализируйте проект:
$ wails init -n desktop -t vue
Wails CLI v2.10.1
# Initialising Project 'desktop'
Project Name | desktop
Project Directory | /tmp/tmp.hX2eO7pGKq/desktop
Template | Vue + Vite
Template Source | https://wails.io
Initialised project 'desktop' in 53ms.
♥ If Wails is useful to you or your company, please consider sponsoring the project:
https://github.com/sponsors/leaanthony
Запустите проект в DEV режиме
wails dev
Структура проекта будет выглядеть примерно так:
$ tree -L 2 .
.
├── app.go
├── build
│ ├── appicon.png
│ ├── bin
│ ├── darwin
│ ├── README.md
│ └── windows
├── frontend
│ ├── dist
│ ├── index.html
│ ├── node_modules
│ ├── package.json
│ ├── package.json.md5
│ ├── package-lock.json
│ ├── README.md
│ ├── src
│ ├── vite.config.js
│ └── wailsjs
├── go.mod
├── go.sum
├── main.go
├── README.md
└── wails.json
В корне у вас есть файл wails.json, в нём информация о проекте, многое придётся переопределить для дистрибуции, имена и прочее. В каталоге frontend - как ни странно UI часть приложения. В каталоге build OS специфичные файлы нужные для последующей сборки артефактов и дистрибуции, тут же иконка и так далее. Я не хочу расписывать всё подробно, так как всё это есть в документации и issues на GH.
Архитектура и разработка
После запуска wails dev, у вас откроется окно приложения, с заданными параметрами из main.go, а интерфейс вы разрабатываете в каталоге frontend. Но кажется нужно немного пояснить, у вас не будет привычного REST API, вместо этого будет RPC взаимодействие между фронтендом (JavaScript/TypeScript) и бэкендом (Go). Это позволяет фронтенду вызывать методы, которые реализованы на Go, так, будто они локальные JavaScript-функции.
Более подробно про то, как это работает можно почитать тут. Так что если сразу уложить это в голове, то всё становится просто.
Tuna Desktop
Перейдём к нашему приложению. Основной наш продукт - это реверс прокси туннели из интернета в локальную сеть, т.е. аналог Ngrok. И да у нас есть консольный клиент - tuna, и так как мы сами активно пользуемся своим продуктом, в какой-то момент мы подумали - Было бы классно сделать десктопное приложение!
?♂️ Зачем?
При локальной разработке часто бывает так, что есть какой-то туннель с статичным адресом, который должен быть доступен всегда. Например, когда мы тестируем наши платежи в ЮКасса, у нас есть тестовый магазин для каждого разработчика, где прописан статический адрес HTTP уведомления. Открывать каждый раз отдельный терминал и писать tuna http -l ru -s test-yookassa-1 8080 становится утомительно, я каждый раз забываю сделать это заранее и приходится создавать несколько счетов или ждать когда платёжная система отправит повторное уведомление.
Также мы знаем, что порой открыть доступ к локальному ресурсу нужно не только разработчикам или системным администраторам, а командная строка не самый дружелюбный интерфейс.
Сложив несколько факторов мы решили сделать GUI приложение с максимально простым интерфейсом, чтобы пользоваться было комфортно даже бухгалтерке.
? Ключевые возможности
Исходя из требований - приложение должно быть супер простым, а также ограничение самого фреймворка, сейчас на момент первого релиза, приложение имеет минимум возможностей:
При этом даже этот функционал сильно ограничен относительно консольной версии. В будущем мы всё таки планируем расширить функционал, к примеру добавить файловый сервер и базовую авторизацию.
?? Поддерживаемые платформы
У нас примерно равное количество клиентов на всех OS, поэтому вопрос о кроссплатформенности не стоял, это было обязательное требование. Так, что сегодня вы можете установить наше десктопное приложение на любой современной ОС.
? Так почему мы всё таки выбрали Wails?
Действительно, если есть пробелы в функционале, то почему мы просто не взяли Tauri или проверенный годами Electron или QT?
Главный аргумент - Wails это наш стэк! ??
Проект уже полностью написан на Go, есть полноценный консольный клиент и мы можем на основе единой кодовой базы использовать один и тот же конструктор. Именно поэтому мы смогли всё сделать так быстро ну и как нам кажется качественно. В случае Electron - пришлось бы тянуть клиент tuna cli и запускать туннели с помощью exec, следить, что они не упали, синхронизировать всё это. С Tauri скорее всего пришлось бы заново написать логику клиента на Rust, а с QT на C++, ну такое ?.
Ну и Tuna Desktop - это не Slack или Spotify, мы преследовали другие цели.
Когда мы начали разрабатывать приложение, мы хотели не просто завернуть наш личный кабинет в обёртку WebView. Мы отказались от этого самого простого и часто используемого пути, по которому идут многие десктопные приложения.
Нам хотелось создать новый пользовательский опыт — особенно для тех, кому неудобно работать с консолью. Есть пользователи, которым просто неприятно взаимодействовать с терминалом, кому-то не нравится формат CLI, а кто-то просто предпочитает привычный интерфейс с кнопками и понятной навигацией. Мы хотели, чтобы у этих людей был выбор — пользоваться десктопным, нативным на вид приложением.
Конечно, по сути мы использовали те же самые компоненты, которые уже были реализованы в личном кабинете и клиенте: тот же UI, та же GOшная кодовая база. Но мы подошли к дизайну по-другому, чтобы это действительно ощущалось как самостоятельное приложение, а не просто оболочка вокруг веба.
В результате за буквально один-два дня мы собрали рабочий прототип. Это было быстро и просто, потому что мы использовали уже готовые элементы — нам не пришлось тратить время на долгие исследования или продумывать всё с нуля. Мы сразу сделали то, что можно было бы уже распространять.
Сложности при сборке и дистрибуции
Если вы вдруг подумали, что всё так просто и радужно, то - НЕТ!
Выше я упомянул, что приложение было готово за 1-2 дня, так вот на сборку и настройку дистрибуции ушло около 3-х недель ?.
Во первых так как есть глубокие интеграции с OS - это зависимость от CGO, а так как проект кросс-платформенный - добро пожаловать в мир кросс-компиляции c CGO в golang. Но я сэкономлю вам неделю исследований и скажу так - вы не сможете собрать проект из Linux для macOS ?♂️. Вот тут я описал проблематику, если коротко, то в macOS SDK есть заглушки которые не позволят вам собрать GUI приложение не на Mac. Всё сломается на этапе линковки и не важно что у вас там zig или osxcross, ограничение именно SDK. Поэтому для сборки под macOS вам нужен Mac! Мы поставили gitlab-runner на наш macmini и теперь собираем на нём, но были варианты и с всякими хостингами, так что не тупиковая ситуация.
Кстати у нас есть проект для сборки golang образа с всем нужным тулкитом для кросс-компиляции под разные OS и архитектуры, пользуйтесь.
Во вторых, сборка под Linux...
Ну начнём с того, что есть разные версии библиотек webkit2gtk-4.0 и webkit2gtk-4.1. И например в Ubuntu 24.04 есть уже только последняя и собирать надо с флагом -tags webkit2_41, а в RHEL 9 (и все клоны) есть только webkit2gtk-4.0, в SUSE, Fedora и ArchLinux есть обе версии. И получается уже на этапе сборки у вас будет 2 артефакта. Но было бы слишком просто если бы этим всё ограничилось. Собрать весь нужный тулкит с нужным окружением и версиями для компиляции под linux arm64 + webkit2gtk-4.1 оказалось дольше и сложнее, чем арендовать linux arm64 сервер и запустить там gitlab-runner, так что мы пошли по простому пути и для Linux arm64 тоже собираем нативно, как и под macOS ?.
Далее я думал, что смогу собрать AppImage, но там тоже возникли сложности, потратив несколько дней я понял, что проще собрать классические deb/rpm пакеты и указать зависимости. Опять же, чтобы вы не страдали, я поработал за вас и составил вот такую табличку:
Таблица зависимостей для Wails / WebKitGTK-приложения
Зависимости для сборки под разные дистрибутивы:
Дистрибутив |
GTK3 |
WebKit2GTK |
ABI |
Пример установки |
|---|---|---|---|---|
Debian 12 / Ubuntu 22.04 (и старше) |
libgtk-3-0 |
libwebkit2gtk-4.1-0 |
4.1 |
|
Debian 11 / Ubuntu 20.04 (и младше) |
libgtk-3-0 |
libwebkit2gtk-4.0-37 |
4.0 |
|
openSUSE Leap / Tumbleweed |
libgtk-3-0 |
libwebkit2gtk-4_1-0 |
4.1 |
|
RHEL / CentOS / AlmaLinux / Rocky (до 9) |
gtk3 |
webkit2gtk3 |
4.0 |
|
Fedora 40+ |
gtk3 |
webkit2gtk4.1 |
4.1 |
|
Arch Linux / Manjaro |
gtk3 |
webkit2gtk-4.1 |
4.1 |
|
Примечания:
В openSUSE Leap доступны обе версии WebKitGTK (4.0 и 4.1), но мы берём
libwebkit2gtk-4_1-0В Fedora до версии 39 включительно был только webkit2gtk4.0, начиная с Fedora 40 появился webkit2gtk4.1.
В RHEL/Alma/Rocky/CentOS (8 и 9) webkit2gtk3 — это 4.0 ABI, 4.1 пока нет.
В Arch есть оба пакета (
webkit2gtkиwebkit2gtk-4.1), но для нового ABI используем второй.
Получается с флагом -tags webkit2_40 собираем только для RHEL, остальные уже имеют современную версию и для них -tags webkit2_41.
Эта таблица максимально отражает современное состояние репозиториев и пакетов (на май 2025 года).
Как итог теперь у нас есть 3 разных rpm пакета 1 deb и 1 pacman, все под amd64 и arm64.
Удивительно, но меньше всего проблем оказалось при сборке для Windows, но мы пока не стали собирать для arm64, так как в репозиториях debian нет готового тулкита Mingw-w64 для этой архитектуры, а я устал ещё на этапе с Linux ?. К слову в Wails есть поддержка NSIS инсталлятора из коробки, так что и тут всё решено и вашему приложению не обязательно быть portable.
Публикация в Store
Мы находимся здесь ?
Для Linux все обновления автоматические через репозиторий, не зря мы всё таки решили собирать стандартные пакеты. А вот для macOS мы пока пакуем DMG и распространяем через сайт, в Windows таже ситуация но с EXE установщиком. И получается ни там ни там, нет нормальной системы доставки. Поэтому сейчас мы на этапе публикации приложения в официальные магазины Apple App Store и Microsoft Windows Store. Так, что если вам интересен этот опыт, то напишите об этом в комментариях и позже я постараюсь подготовить статью об этом опыте.
Итоги
Мы однозначно довольны выбором Wails, конечно, если бы изначально были реализованы такие вещи, как трей, уведомления и дочерние окна, это был бы почти идеальный проект — слишком хороший, чтобы быть доступным просто так и бесплатно. Но мы потратили не так много ресурсов, а наши пользователи остались довольны.
Если вы хотите начать делать своё GUI приложение подойдите к выбору основательно, не забывайте про правило 20/80 и не бойтесь чем то жертвовать. Лучше НЕ идеальное приложение сегодня, чем идеальное никогда.
На этом у меня всё, спасибо что дочитали до конца ?
Если вы мечтали о десктопной версии аналога Ngrok, то - используйте Tuna Desktop.
Тут я хочу напомнить, что Tuna - это платформа для разработчиков и их команд, нацеленная на ускорение разработки, упрощение командного взаимодействия и безопасность.
Контакты
Если возникли вопросы, можете задать их нам по почте info@tuna.am, тут в коментариях или нашем чате в telegram.
Комментарии (28)
dpvpro
04.06.2025 18:15Есть ли проверенные нативные варианты кроссплатформенного GUI на golang? Без JS, Electron и другого.
Есть же Fyne. Он позиционируется как кроссплатформенный. Почему не использовали его?
jidckii Автор
04.06.2025 18:15Ну GUI приложения без современного веба выгледят как приложения для windows xp в 2004м) Это просто не приемлемо, ну по крайней мере в комерческом продукте.
Fyne - это как QT до QML, т.е. на виджетах.
Посмотрите на их примеры
https://apps.fyne.io/all.html
https://apps.fyne.io/apps/com.edgevpn.html
https://apps.fyne.io/apps/com.tqdev.fyne-authenticator.html
Ну если чисто для себя или для внутреннего использования в компании, для сисадминов там, это ещё годно, т.е. просто кнопки и формы если нужны. Но на рынке засмеют же во первых, а во вторых ну просто не будут пользоваться.
Никому не важно, что приложение спотифая тащит пол гига, главное как оно выглядит. Пользователю особо без разницы что там под капотом.
sonikku
04.06.2025 18:15Ну GUI приложения без современного веба выгледят как приложения для windows xp в 2004м
Чтобы они выглядели как приложения для Windows XP, нужно запустить их на Windows XP или принудительно их так стилизовать. В противном случае их отрисует тулкит с той темой, что используется в системе. Не нравится — пишите свои стили, это нынче в GUI-фреймворках для десктопа делается безо всякого веба.
Это просто не приемлемо, ну по крайней мере в комерческом продукте.
Но на рынке засмеют же во первых, а во вторых ну просто не будут пользоваться.От таких мыслей несёт, как бы так помягче выразиться, потребительской культурой. Приложение не вписывается в общую тему и жрёт тонны ресурсов для свистоперделок? Пофиг, зато не засмеют... а кто не засмеёт, кстати? Мне сложно себе представить, чтоб кто-то реально смеялся над тем, что разработчики предпочли обычный вид приложения бешеному потреблению ресурсов.
TerrorDroid
04.06.2025 18:15Дело не плохих стилях, а в том, что нативные десктопные инструенты (в плане фреймворков) для дизайна нетипового/кастомного UI, который всем так нравиться, это в 8 из 10 случаев лютая трешанина, на фоне которой даже упоротая комбинация HTML+CSS выглядит волшебно. Это вдвойне проблема когда заходит про кросс-платформенные инструменты.
jidckii Автор
04.06.2025 18:15От таких мыслей несёт, как бы так помягче выразиться, потребительской культурой.
Ну так мы и живём в этом мире потребительской культуры.
Мне сложно себе представить, чтоб кто-то реально смеялся над тем, что разработчики предпочли обычный вид приложения бешеному потреблению ресурсов.
Думаю от части вы правы и моё вчерашнее высказыванее резковато, сегодня с утра я бы так уже не написал, но как говориться что написано пером ... ))
В целом идея в том, что веб технологии по части визуала ушли далеко вперёд, а ещё это низкий порог входа, и много специалистов. По этому наверное пожертвовать 350 мегабайт опративки проще, чем искать хорошего спеца на Delphi / QT. Т.е. использование веба на дестктопе просто открывает двери большему количеству разработчиков. Ну в общем не буду расписывать то, что и так ниже в комментариях уже обсудили.
itstranger
04.06.2025 18:15Я это называю "солидностью стека". Когда есть отличные инструменты для решения задач, но видите ли они не солидны и за них засмеют... И правда, кто засмеёт? Клиенты? Если им вечно не говорить, что солидно, а что нет, то им пофиг на техническую реализацию им важен функционал и поддержка. Большая часть энтерпрайза сидит на java erp/crm, состоящих целиком и полностью из легаси решений.
Засмеют другие программисты? Если программист смеётся над использованием релевантного стека, для быстрого и эффективного решения задачи, то стоит усомниться в его компетентности.
Причём, в контексте темы, это иронично слышать, учитывая отношение многих программистов, пишущих под desktop, к фронтенд фреймворкам.
jidckii Автор
04.06.2025 18:15Да что вы прицепились к этому "засмеют"? Понятно же, что образно.
И правда, кто засмеёт? Клиенты?
Наши основные клиенты - это разработчики.
Причём, в контексте темы, это иронично слышать, учитывая отношение многих программистов, пишущих под desktop, к фронтенд фреймворкам.
Значит они нас засмеют) получается не важно что выбирать, засмеют в любом случае)))
HemulGM
04.06.2025 18:15Ну GUI приложения без современного веба выгледят как приложения для windows xp в 2004м
Это заблуждение.
Приложение без веба. Кроссплатформенное. 1
Приложение без веба. Кроссплатформенное. 2
Приложение без веба. Кроссплатформенное. 3
Приложение без веба. Кроссплатформенное. 4
Приложение без веба. Кроссплатформенное. 5
Приложение без веба. Кроссплатформенное. 6
И это только мои примеры.
Здесь всё векторное, что означает, что качество картинки будет только улучшаться с увеличением DPI. Все примеры кроссплатформенные. В примерах нет никакого WebView или даже намека на HTML/CSS или QML. И всё это (визуал) создается буквально за день
leoismyname
04.06.2025 18:15Ну если за день, то готов посмотреть исходники этих проектов, выглядит интересно)
Мое мнение – в небольших командах лучше стараться придерживаться одного стека, сейчас компонентная база, используемая в этом приложении на 25 мб, используется на лендинге, в личном кабинете, в инспекторе запросов для http, в инспекторе сессий для redis/postgres.
Много что можно сделать за день, если у тебя есть в этом экспертиза. А если ее нет, нужно ли тратить время на изучение того, что может быть бесполезно для конечного пользователя? Мы уже много всего изучили пока собирали это и ничем не ограничены, как и в смене фреймворка в дальнейшем, если на то будут причины и если будут какие-то отличные примеры реализации для изучения, по типу твоих.
Наверное, fyne нужно задуматься о размещении более вдохновляющих примеров использования в своей галерее)
HemulGM
04.06.2025 18:15Главная мысль была всё же именно в том, что выглядеть красиво могут приложения и без веба. Но я отвечу и на ваши вопросы.
готов посмотреть исходники этих проектов
А собственно в этом и есть скорость создания UI. Тут нет исходников, точнее есть разметка, которая получена в результате дизайна, но генерируемая автоматически. Т.е. в примере приложения Strato (это музыкальный плеер, который организует и воспроизводит музыку с вашего Google Drive, при чем не требует ввода пароля, а использует внешний пользовательский браузер для OAuth2), я не написал ни строчки кода связанного с GUI.
Кода нет
Ссылка на коммит этого приложения, UI которого выглядит как на скрине в прошлом комментарии.
нужно ли тратить время на изучение того, что может быть бесполезно для конечного пользователя?
Тратить время нужно на любой инструмент, в особенности на новый. Т.к. я владею языком, где этот фреймворк идет по умолчанию, мне не составило большого труда его изучить. Я не буду вам втюхивать Delphi, т.к. мой комментарий всё же был именно о конечном результате, а вы вряд ли будете рассматривать его использование. Но если в кратце, то здесь используется кроссплатформенный фреймворк FMX, который имеет дизайнер окна и дизайнер стиля (что-то вроде CSS). И алгоритм такой:
1. Создаем окно
2. Добавляем элемент (например кнопку)
3. Открываем дизайнер стилей и создаем представление этой кнопки (с помощью примитивов (фигуры, svg, path, картинки), шейдеры, анимации, триггеры или другие контролы)
4. Назначаем кнопке созданный стиль
Готово. Всё это визуально, в реалтайме. В стиле могут быть другие контролы со своим стилем. Функционал контрола остается за самим контролом. Набор стилей может быть общим между окнами, между проектами и вообще может быть загружен/заменен/изменен динамически.Ещё есть пример плавной смены стиля на другой.
leoismyname
04.06.2025 18:15Ну это хорошо и прекрасно, только кодовая база на Go, поэтому мы рассматривали варианты фреймворков на этом языке, а не на любом другом. Использование другого языка потребовало бы переписывать библиотеки и сетевой стек. Я думал именно о Go и возможности фреймворков использующих его, про Delphi то мы в курсе.
Fyne все же не такого уровня инструмент как Delphi – без такой богатой и долгой истории, а еще чистый open source на энтузиазме.
leoismyname
04.06.2025 18:15Кода по верстке у тебя нет, но его надо писать в решениях для Go, потому что это все же не из коробки решение. В Delphi можно программно расставлять и создавать элементы (как у нас могло бы быть – https://github.com/romanitalian/GHOSTman/blob/main/main.go#L53), а можно в редакторе (как у тебя) и кажется, что кодом верстать адаптивно и без нормального тулинга не очень удобно (но опыта в этом не имею).
jidckii Автор
04.06.2025 18:15В примерах нет никакого WebView или даже намека на HTML/CSS или QML. И всё это (визуал) создается буквально за день
Мне кажется или то, что вы привели в пример это прямой аналог той же самой верстки как в HTML/CSS и QML, только нечно своё в Delphi FMX?
Ну и в видео с калькулятором ну ооочень IDE похоже на QT Creator, только код в стиле Pascal а не C ))
HemulGM
04.06.2025 18:15Нет, стили в FMX это не аналог CSS, просто приведен как быстрый способ понять, что такое стили и что стили - это не "шкурки". В FMX просто применяется принцип разделения данных от представления. Работают иначе, возможности другие. Например, стили НЕ влияют на поведение контрола и НЕ виляют на его положение, они влияют лишь на его вид. В CSS/HTML всё в перемешку. Где-то там задано расположение, где-то там.
Ну и эта IDE и её возможности появились задолго до Qt Creator, в том числе дизайнер фреймворка FMX. Так что это не RAD Studio похожа на Qt Creator, а Qt Creator ооочень похож на RAD Studio
И как я уже сказал, стили в FMX создаются тоже через дизайнер, а не кодом. Статью даже недавно писал. https://habr.com/ru/articles/833804/
leoismyname
04.06.2025 18:15Да не, там со времен первых версий Delphi был визуальный редактор, все, что ты накидал складывается в отдельный файл описания текущей формы, рядом могут жить файлы с кодом, которые эту форму обрабатывают, а еще там великое множество разных компонент, так что настроить можно что угодно. Но опять же, это если рассматривать языки другие, не Go
itstranger
04.06.2025 18:15Если говорить про Рад Студио, то решения, что показал HemulGL можно и правда собрать быстро, потому что у Ембракадеро есть огромное количество готовых компонентов на все случаи жизни. Правда есть несколько минусов, удовольствие это не бесплатное (насколько помню, но может что-то поменялось) и готовые компоненты не всегда могут закрыть потребность в имеющимся дизайне, поэтому приходиться их переписывать.
Я бы посоветовал смотреть в сторону WPF, там xaml, тоже есть огромное количество компонентов, C# довольно простой в освоении ЯП и мне кажется любой фронтендер довольно быстро освоится в WPF, а главное всё бесплатно.
HemulGM
04.06.2025 18:15Всё что я показал на скринах, сделано штатными средствами. Без каких-либо сторонних компонентов. И без переписывания чего-либо.
Среда разработки платная как и VS, и такая же бесплатная как и VS. Т.е. для коммерческой и не коммерческой разработки есть версии.
dpvpro
04.06.2025 18:15Fyne возможно и не блещет в прмерах, но огромнейший плюс этого фреймоворка в том что не нужно устраивать пляски со сборками на разных хостах, как вы описали в статье.
Ваш продукт не плохой, возможно воспользуюсь в будущем.
jidckii Автор
04.06.2025 18:15Нет, в Fyne тоже есть зависимости от системных компонентов и тоже сборка с CGO, так что было бы всё тоже самое.
itstranger
04.06.2025 18:15Сильное заявление. Сейчас на том же WPF, можно собирать вполне себе красивые решения для бизнеса. Даже на древних, но быстрых вин формах можно, при помощи готовых компонентов, но это муторнее.
Есть QT, который позволяет тоже делать красоту для энтерпрайза. Если честно не понимаю зачем писать десктоп приложения на фронтенд фреймворках, которые всё-равно не будут настолько же быстро и эффективно работать, как приложения на C# и C++. Недавно была новость, что меню пуск в win11, написана на React Native, из-за чего в моменте открытия нагружает пк.
jidckii Автор
04.06.2025 18:15Это всё не наш стэк, об этом написано в статье и тут в комментариях уже, по этому не рассматривали.
Siemargl
04.06.2025 18:15Потому что логично.
Есть бэкенд на Го, предназначенном для бэкэнда.
Почему бы не сделать к нему фронт на решении для фронтэнда.
Sazonov
04.06.2025 18:15Сейчас есть определенная тенденция, что для разработки на qml не нужно знание плюсов. В идеале достаточно чтобы был биндинг qt под нужный вам язык - и тогда на чистом qml можно хоть в webassembly собирать. Посмотрите их демку, достаточно эффектно выглядит: https://try.qt.io (оно напишет что желательно десктоп/планшет, но у меня на мобилке тоже отлично работает, если запросить десктоп версию).
Metotron0
04.06.2025 18:15командная строка не самый дружелюбный интерфейс.
Ну, дожили
Классика
Однажды вечером Мастер Фу и Ньюби посетили собрание программистов, которые встретились, чтобы поучиться друг у друга. Один из программистов спросил у Ньюби, к какой школе принадлежит он и его учитель. Когда Ньюби сказал ему, что он и его учитель - последователи Великого Пути UNIX, программист презрительно усмехнулся.
"Средства командной строки UNIX грубые и отсталые, - насмешливо сказал он. - Современные, правильно спроектированные операционные системы делаю всё через графический интерфейс пользователя".
Мастер Фу не проронил ни слова, но указал на Луну. Находившийся поблизости пёс залаял на руку учителя.
"Я не понимаю вас", - сказал программист.
Мастер Фу молчал и показал на образ Будды. Потом он указал на окно.
"Что вы хотите мне этим сказать?" - спросил программист.
Мастер Фу указал на голову программиста. Потом он указал на камень.
"Почему вы не можете сказать яснее?"- потребовал программист.
Мастер Фу задумчиво нахмурился, дважды щёлкнул программиста по носу и бросил его в находившийся рядом мусорный контейнер.
Пока программист пытался выбраться из горы мусора, пёс ходил рядом и лаял на него.
В этот момент программист достиг просветления.
jidckii Автор
04.06.2025 18:15Ну, дожили
Ну так
Сложив несколько факторов мы решили сделать GUI приложение с максимально простым интерфейсом, чтобы пользоваться было комфортно даже бухгалтерке.
kouznedm
Сам активно использую Wails для небольших десктопных проектов в связке с React.js, связка Golang с JS действительно отличный вариант для быстрого прототипирования, и да Tauri хоть и более активный в плане коммюнити, но Rust не для всех ) Если кому то будет интересно - сделал небольшой Template чтобы могли попробовать.