Предыстория
Мы небольшая команда разработчиков, занимаемся созданием нового инструмента для работы с API Testmace. По факту это продвинутый rest клиент с возможностью создавать автоматизированные тесты API с помощью графического интерфейса, оснащенный такими приятными штуками как продвинутый механизм переменных, автокомплит во всех полях ввода и тотальная подсветка синтаксиса.
Хочу вам рассказать о том, как мы пришли к Electron как технологии для написания нашего приложения.
Почему десктоп
В последние 10-15 лет web пережил взрывной рост и продолжает активно развиваться. Постоянно появляются все новые и новые инструменты для создания все более функциональных и сложных web-приложений. Создаются даже целые языки программирования, заточенные для написания web-приложений и практически не имеющие готовых решений вне этой области. Да и в нашей повседневной жизни мы уже частично заменили microsoft office и thunderbird на google docs и интерфейс gmail-а.
Однако веб не может пока полностью вытеснить десктопные приложения, и вот по каким причинам:
- Недостаточная отзывчивость web-приложений. Где-то всему виной клиент-серверная синхронизация и медленный интернет, где-то однопоточная природа javascript-а, а где-то и просто прожорливость браузера на вашей не очень мощной машине. Стоит заметить, что решение вышеперечисленных проблем лишь вопрос времени. В частности, web worker-ы уже поддерживаются всеми современными браузерами, что частично решает проблему отсутствия многопоточности, а возможности типа SharedArrayBuffer позволяют уменьшить накладные расходы на копирование памяти между основным потоком и воркерами.
- Доступ к локальным ресурсам системы. Есть целые классы приложений (файловые менеджеры, tweaker-ы, демоны и сервисы) которые не могут быть реализованы как web-приложения (по крайней мере на данном этапе развития).
- Ограничения возможностей самого браузера. К примеру, сетевое взаимодействие ограничивается только отправкой http запроса и соединения по web-socket-ам. Более низкоуровневые вещи (tcp, upd сокеты), увы, недоступны.
- Искусственные ограничения браузеров в целях безопасности. CORS, работа с cookies, ограничения на отсылаемые заголовки.
- Ограниченный набор языков и подходов. В отличие от web-приложений, где единственным языком для написания приложений остается javascript, десктопные приложения позволяют использовать любые языки программирования вплоть до ассемблеров, эффективно использовать ресурсы системы, применяя многопоточное программирование и низкоуровневые инструкции. Стоит отметить, что по данному вопросу ситуация улучшается — появляются транспилеры из некоторых языков в javascript. Более того, компиляция в webassembly позволяет перенести наработки из других языков (C++, C#, rust и т.д.), зачастую получая неплохой прирост производительности.
Рассматривая причины, перечисленные выше, мы можем прийти к выводу, что TestMace должен быть типичным десктопным приложением:
- Нам необходим доступ к файловой системе для работы с проектом.
- Ограничения fetch не позволяют получить полный контроль над конфигурированием и выполнением запроса.
- В будущем нам могут потребоваться низкоуровневые оптимизации для улучшения производительности приложения.
Выбор технологии
Мы определились, что наше приложение будет десктопным, однако, пока не определились с языком и технологиями, на которых будем это реализовывать. Что касается языков программирования, то к ним нами предъявляются следующие требования:
- Это должен быть язык со статической типизацией.
- Язык должен иметь большую и зрелую инфраструктуру — должны быть как проверенные библиотеки так и поддержка со стороны IDE и других инструментов.
- Язык должен быть знаком большинству членов команды.
Последний пункт также немаловажен. Мы как стартап заинтересованы в скорейшем (в течении полугода) выводе продукта на рынок, максимально используя внутренние ресурсы команды. Изучение нового языка и инфраструктуры уменьшает предсказуемость планирования и чревато ошибками в принятии тех или иных решений.
Как бы то ни было, список требований не кажется уж слишком жестким, и ему удовлетворяют такие языки как C#, TypeScript, Go. Дальнейший выбор технологий будем проводить с учетом наличия реализаций необходимых компонентов для данных языков.
Гораздо более интересно обстоят дела с выбором решений для разработки пользовательского интерфейса. Требования к ним следующие:
- Кроссплатформенность (Windows, Linux, MacOS)
- Богатый набор как встроенных так и сторонних компонентов
- Кастомизируемость компонентов
- Наличие языка разметки для описания интерфейса
- Хорошая поддержка
Рассмотрим, какие решения подходят под данные требования.
Qt (Qml)
Qt — это мощный тулкит для написания кроссплатформенных приложений. В последних версиях данного фреймворка появился компонент Qt Quick для написания приложений с использованием декларативного языка описания разметки QML. Qt в общем и QML в частности — это проверенные в боях решения, нашедшие свое применение практически во всех сферах — от embedded до программных оболочек операционных систем.
Основным языком программирования в Qt является C++ (в QML можно использовать javascript). Однако для Qt и QML есть биндинги для других языков программирования (вот например для C#). Однако официально поддерживается только интеграция с питоном. Все остальное — сторонние реализации. Согласитесь, не хотелось бы доверять самую базовую часть приложения библиотеке, которую разрабатывает как хобби небольшая группа энтузиастов.
Еще есть проект Brig. Это NodeJS биндинги для QML. Отличительной особенностью данного проекта является впечатляющая демка. Однако, как оно часто бывает в open source проектах, авторы не уделяют должного внимания проекту и поэтому он также сходит с дистанции.
GTK
Библиотека для построения пользовательского интерфейса, которая начиналась как часть проекта GIMP и впоследствии была выделена в отдельный проект. Имеется инструмент Glade для быстрой разработки пользовательского интерфейса. Основным языком для разработки GTK является C, однако есть биндинги для многих популярных языков программирования. Более того, с использованием C# биндингов создавалась MonoDevelop — одна из самых мощных IDE для разработки под C#. Однако после более внимательного изучения мы понимаем, что проект GTK# находится в полузаброшенном состоянии — последний коммит был в феврале 2018, следующий в январе 2017 и далее 2016. По коммиту в год. Негусто, учитывая, что основной репозиторий gtk активно развивается. А счастье было так близко…
Electron
В последнее время очень много шума связано с данным фреймворком. Кто-то хвалит его за возможность перенести наработки веб-приложений на десктоп, кто-то ненавидит за чрезмерную прожорливость. И тех и других можно понять. Electron под капотом использует node.js и библиотеку рендеринга из Chromium. По сути создается обычное web-приложение и заворачивается в исполняемый файл. Причем каждое приложение поставляется с собственной версией Node.js и Chrome.
Минус по сути только один, но достаточно серьезный — это большое (по сравнению с другими технологиями) потребление памяти: пустой проект занимает в памяти 100-200 мегабайт. Для некоторых это причина отказаться от использования таких приложений (привет, Skype). Однако давайте проанализируем ситуацию на рынке. На данный момент многие популярные приложения написаны на Electron (Slack, Skype, Discord, VSCode, Atom, Postman, Insomnia и т.д.). Многие из них являются стандартами в своей сфере или стремительно завоевывают сердца пользователей (как, например, те же VSCode и Insomnia). Люди просто используют инструменты, которые хорошо решают их повседневные задачи, невзирая на некоторые побочные эффекты. С другой стороны, компьютеры становятся все мощнее (как минимум, рост RAM не прекратился), и все меньше приходится слышать отзывы недовольных клиентов, что «ваш хром съел всю мою память». Резюмируя, мы считаем, что повышенное потребление оперативной памяти не будет играть большой роли в случае, если продукт будет действительно хорош в своей сфере.
Плюсы же данной технологии очевидны:
- Возможность использования наработок из web.
- Проще найти специалистов в данной сфере.
- Отработанный воркфлоу «дизайнер» — «верстальщик» — «программист», изобилующий удобными инструментами на каждом этапе.
Также к плюсу мы относим тот факт, что команда имеет большой опыт создания front-end приложений.
В итоге, мы остановились на Electron как на основном инструменте для разработки нашего проекта. Автоматически, в качестве языка для разработки приложения мы выбрали TypeScript.
Заключение
Одна из основных задач стартапа — это скорейший вывод продукта на рынок. Круто, если получится это сделать с минимальными затратами. Целью данного анализа и было найти такой инструмент, который позволил бы нам решить эти задачи. На наш взгляд, Electron прекрасно нам подходит. Спустя три месяца после начала разработки, он до сих пор вне конкуренции, и, похоже, у нас все серьезно.
