Что такое вообще платформы, что такое мультиплатформенные приложения?
Платформы - база, на которых работают наши приложения. Это может быть компьютер, телефон, планшет или даже часы. Каждая из этих "баз" имеет свою операционную систему, такую как Windows на компьютерах или iOS на iPhone.
Когда разработчики хотят создать приложение, которое будет работать на всех этих устройствах и операционных системах, они создают то, что называется мультиплатформенным приложением. Это приложение, которое можно установить и запустить на разных устройствах, не создавая новую отдельную версию для каждого из них.
Основные платформы, на которые разработчики обычно ориентируются:
PC: это включает в себя операционные системы, такие как Windows, macOS и Linux.
Мобильные устройства: это включает в себя Android (на большинстве смартфонов и планшетов) и iOS (на iPhone, iPad).
Веб: это интернет-браузеры, такие как Chrome, Firefox, Safari и другие.
Носимые устройства: такие как умные часы на базе Wear OS (от Google) или watchOS (от Apple).
Телевизоры и приставки: например, Android TV или Apple TV.
Чтобы создать мультиплатформенное приложение, разработчики используют специальные инструменты и технологии, которые позволяют им писать код один раз, а затем адаптировать его для разных платформ.
Зачем это вообще нужно?
Долгое время я, как разработчик, следовал простому правилу: работаю там, где платят. Но однажды понял, что слишком завяз на Apple. Пришло время расширить горизонты.
Многие системы, такие как Blackberry и Symbian, ушли в прошлое. Linux пока держится на плаву благодаря корпорациям, а BSD продолжает жить благодаря энтузиастам. Plan9? Это скорее для гиков. А активно развиваются платформы от Google, Apple и Microsoft.
А почему так произошло? Главная причина – деньги. Программисты писали свои приложения для тех платформ где платят, а остальные великолепные платформы все это время были в стороне, в результате какие-то платформы выжили, какие-то нет.
Что бы этого избежать, я для себя принял решение изменить принцип. Работаю где платят, но не забываю про остальные платформы. Т.е. на словах это безболезненное дополнение изначально принципа, к которому я призываю и всех остальных разработчиков.
Окей, с чего начать, с Golang?
Я активно программировал на Go и решил исследовать возможности создания GUI на этом языке. Одно из преимуществ Go — его мультиплатформенность. Он отлично компилируется под любые платформы прямо с целевой машины, без необходимости заморачиваться с контейнерами или кросс-компиляцией, как в случае с C/C++. Это позволяет мне с минимальными усилиями создавать приложения для любой платформы, прямо из командной строки. Такая себе простота и удобство...
При поиске инструментов для создания GUI на golang я столкнулся с рядом библиотек: вроде бы неплохие GXUI и shiny, но они больше не поддерживаются. NanoGUI-Go, переписанная с C++, всё равно требует исходного C++ и кросс-компиляции. Есть и go-astilectron — адаптация Electron, но снова не без C++. Можно использовать связку с QT, но кроссплатформенная сборка представляет сложности. Среди активно развивающихся библиотек есть Fyne и Gia, но и они имеют ограничения по платформам и предоставляют несистемный интерфейс.
Итак, удивительно, что для такого гибкого кроссплатформенного языка, как Go, создать универсальный GUI оказалось непростой задачей.
Что вообще удалось выяснить?
Когда речь идет о GUI, есть несколько ключевых моментов:
Системные библиотеки: GUI часто создается на основе системных библиотек. Это может быть напрямую через OpenGL или через специфические библиотеки операционной системы, предоставляющие элементы интерфейса.
Зависимость от C/C++: Большинство библиотек для создания GUI, к сожалению, требует использования C/C++. Это может создавать дополнительные сложности по кросс компилляции так и другие проблемы связанные с зависимостями от других библиотек, которые в свою очередь могут ограничить круг ОС/платформ за счет платфром спецефических инструкций и т.д.
Ограничения по платформам: Некоторые библиотеки ориентированы исключительно на десктопные или мобильные платформы, не предоставляя гибкости в выборе.
Нативность интерфейса: При использовании OpenGL интерфейс может не выглядеть "родным" для конкретной операционной системы. Такие приложения либо полагаются на свой уникальный дизайн элементов, либо пытаются эмулировать стандартные элементы ОС. С другой стороны, библиотеки, стремящиеся к нативному отображению, чаще всего базируются на C/C++.
Отсутствие IDE для создания интерфейсов: Не все но многие не имеют такой возможности. Т.е. создавать интерфейс придется кодом.
С учетом всего вышеуказанного, создание GUI на Golang может стать довольно сложной задачей, особенно если вы ищете кроссплатформенное решение без использования C/C++.
Что дальше, попробуем Rust?
После того как я столкнулся с проблемой отсутствия удобной GUI-библиотеки для Go, я решил пойти дальше. Моя мысль была такова: если необходимо использовать C/C++, почему бы не обратить внимание на что-то более безопасное, например C# или Rust, но при этом эффективное. Выбор пал на Rust, я даже приобрел книгу по этому языку.
Однако при изучении возможностей Rust в области GUI я столкнулся со следующим:
Druid - устаревшая библиотека.
egui - интересный вариант, но использует собственные виджеты.
orbtk - также полагается на свои виджеты и устарел.
iced - опять-таки свои виджеты и ограниченная кроссплатформенность.
dioxus - имеет большую кроссплатформенность, но, к сожалению, виджеты не системные.
tauri - по сути, легковесный аналог Electron с сопутствующими проблемами.
К тому же, я понял, что Rust не освобождает от проблем с кросс-компиляцией. Многие библиотеки включают в себя элементы на C/C++, что усложняет процесс сборки приложения.
В целом, задача создания кроссплатформенного GUI оказалась не такой уж и простой, даже с учетом многих современных инструментов.
Хмхм, что же, посмотрим на C# и .NET?
После разочарования в возможностях Rust, я решил обратить внимание на C# и экосистему .NET. И здесь был небольшой просвет!
C# с .NET оказался довольно перспективным вариантом, хотя и не лишен некоторых проблем, особенно касающихся поддержки различных платформ и архитектур процессоров. Однако, среди доступных GUI-библиотек для .NET я обнаружил Avalonia UI. Это действительно интересный и мощный инструмент, позволяющий создавать кроссплатформенные приложения. Но, как и у многих других решений, у Avalonia свои виджеты, которые, к сожалению, не выглядят нативно на всех платформах.
Кстати, для меня удивительным оказалось что .NET действительно хорошо развивается и движется в направлении кроссплатфореммности, однако на данный момент, проблемы всё те же.
Итак, взглянем на Python?
После всех моих путешествий по миру быстрых языков программирования, я решил остановить свой взгляд на чем-то менее быстродействующем. Почему бы не Python? Этот язык известен своим огромным количеством библиотек и универсальностью.
Да, я не новичок в Python. И я знал, что с его помощью можно "упаковать" код в самостоятельный исполняемый файл. Инструменты типа PyInstaller или cx_Freeze позволяют создавать так называемые "бинарники", которые можно запускать, не имея Python на компьютере.
И почему это так важно? Потому что, например, для AppStore на iOS приложения могут быть представлены только в виде бинарников. Так что язык, не способный предоставить такую возможность, не может рассматриваться как истинно мультиплатформенный.
Теперь к главной части: GUI на Python. Оказывается, создать GUI приложение на Python действительно возможно. Но здесь я столкнулся с уже знакомой мне проблемой: большинство библиотек для создания GUI снова полагается на C/C++. Некоторые из них используют OpenGL для отрисовки, другие полагаются на C/C++ на разных этапах разработки.
Окей, а что там с java?
С Java моё путешествие стало особенно увлекательным. Я знаком с Java еще со времен создания игрового сервера для Red5. Немного погуглив, быстро наткнулся на фреймворк SWT для GUI, и мгновенно собрал приложение с действительно нативным интерфейсом. SWT под капотом имеет статические библиотеки для работы с элементами операционных систем, что дает возможность его расширения для нестандартных ОС.
Кстати Java можно с помощью GraalVM собрать в бинарник.
Скажу сразу, что каждый раз погружаясь в очередной язык для выяснения как на нем сделать GUI, я шел в чаты в телеге по конкретному языку и спрашивал у профи, что они думают, чем помогут, что подскажут.
И в чате по Java мне подсказали, что Java уже по сути скорее мёртв, чем жив. Ибо после скандала компании Оракл с Гуглом появился Kotlin. Язык совместимый с Java и имеющий Kotlin/Native технологию по преобразованию кода в бинарный вид. Плюс есть и GUI Compose Multiplatform, который однако имеет свой набор витжетов не похожих на системные, именно похожих. Также увы, но не все платформы поддерживаются.
Что дальше, Flutter, react native, haxe?
Когда то давно, когда я еще писал чат на ActionScript в Badoo, и смерть ActionScript уже маячила на горизонте, появился Haxe, как универсальный язык про который я тоже вспомнил. Xamarin/Flutter/ReactNative я решил тоже посмотреть и проверить заодно. Если посмотреть на них и почитать спецификации они покрывают лишь часть платфром, либо только мобильные, либо только декстопные, либо немного тех немного других.
Flutter:
Создан Google и в основном используется для мобильной разработки.
Имеет собственную систему виджетов, которая выглядит одинаково хорошо на различных платформах.
Поддерживает десктопные и веб-приложения, хотя это все еще в бета-версии (на момент последнего обновления моих знаний в 2021 году).
Основан на Dart — языке, созданном Google.
React Native:
Создан Facebook для создания мобильных приложений на iOS и Android с помощью JavaScript и React.
Отлично подходит для разработчиков, знакомых с React.
В отличие от Flutter, React Native использует системные компоненты, что делает его приложения ближе к нативному внешнему виду и ощущению.
Есть возможность встраивания нативного кода, что увеличивает гибкость.
Haxe:
Это высокоуровневый язык программирования с возможностью кросскомпиляции в множество различных языков и платформ, включая JavaScript, C++, C#, Java и другие.
Имеет ряд фреймворков для разработки GUI, таких как OpenFL и Kha.
Особенно популярен среди разработчиков игр.
А xamarin по факту это уже рассмотренный ранее C# .NET от микрософт.
Может быть все таки Electron и аналоги?
Сам электрон считается универсальным средством для разработки приложений, более того имеются и более легковесные аналоги:
NW.js (ранее node-webkit): Подобно Electron, позволяет разрабатывать настольные приложения на основе веб-технологий.
Tauri: Легковесная альтернатива Electron. Использует Rust в качестве бэкенда и значительно сокращает размер исходного файла приложения.
Proton Native: Предлагает создавать настольные приложения с помощью компонентов React, но без использования веб-технологий.
Да, по сути электрон это браузер который пытается прикинуться приложением. Проблем у такого подхода хватает. более того, как бы не хотелось многим, но electron и аналоги закрывают лишь базовые платформы, и так же как остальные решения интерфейс в таких приложениях не является нативным без специальных оптимизаций, под каждую платформу. И тут встает вопрос, зачем тогда все это может просто использовать web?
Так может просто web, PWA (Progressive Web Apps), Webassembly??
PWA, это тренд направленный на будущее, представляющий истинную кросплатфроменность, НО, не дающий нативного интерфейса системы, не дающий доступа к файловой системе, имеющий достаточное количество ограничений для того что бы не использовать его в своих проектах, покрайней мере пока.
Производительность: Нативные приложения могут предоставлять лучшую производительность, особенно для графически интенсивных задач.
Доступ к API: Хотя браузеры предоставляют все больше и больше API для доступа к аппаратному обеспечению, некоторые вещи все еще доступны только для нативных приложений.
Магазины приложений: Если ваша цель - распространить приложение через App Store или Google Play, вам все равно потребуется нативная оболочка или решение вроде Cordova/PhoneGap.
Конечно, первый пункт можно побороть и повысить производительность создав webassembly код, но получить доступ к системным API всё равно пока не выйдет.
Что в итоге, Lazarus?
В итоге я совсем отчаялся найти хоть что то действительно мультиплатформенное, легко собираемое, не требующее C/C++, имеющее IDE для отрисовки нитрефейса, как вдруг здесь же на хабре мне посоветовали посмотреть на некий Lazarus.
Как оказалось, Lazarus — это интегрированная среда разработки (IDE) для языка программирования Free Pascal. Он предоставляет визуальное проектирование форм и компонентов, что делает его похожим на старые версии Delphi. Основное преимущество Lazarus — его кроссплатформенность. С его помощью можно создавать приложения для различных операционных систем, таких как Windows, macOS, Linux, и даже для мобильных платформ.
Основные особенности и преимущества Lazarus:
Нативные приложения: Lazarus компилирует код в нативные исполняемые файлы для каждой поддерживаемой платформы.
Визуальный дизайнер: Позволяет легко создавать интерфейсы перетаскиванием компонентов.
Богатый набор компонентов: Включает в себя большое количество стандартных и дополнительных компонентов.
Открытый исходный код: Это свободное программное обеспечение, и его исходный код доступен всем.
На паскале я писал еще во времена обучения в МИРЭА. Ну и в школьные годы балуясь турбоси, я погладывал и на паскаль.
Первое с чем пришлось столкнуться с тем что среда никак не хотела видеть путь к Xcode билиотекам, я позадавал вопросы в профильном чате но результат в итоге пришлось гуглить. Второй проблемой оказалось то что для некоторых вещей пришлось пересобирать IDE их исходников.
В остальных вопросах это оказалась довольно дружелюбная среда разработки, на которой я в данный момент и остановился.
Читать далее: Побег из экосистем в 2023
