Что случилось с легковесными десктопными приложениями? История Electron

Electron ^[1] — это один из самых известных инструментов современного разработчика. Если присмотреться, то это родственник Reactive Native, манящий лозунгом «пиши один раз, запускай везде!», но с гораздо меньшими издержками по сборке и релизу, чем в случае мобильной разработки. Его уникальное преимущество заключается в комбинации Node.js и Chromium, создающей мощную десктопную среду для веб-технологий. Официальный блог Electron не так давно отметил своё десятилетие, что весьма удивляет с учётом того, насколько глубоко этот инструмент успел проникнуть в культуру разработки.

К середине 2020-х мы достигли точки, когда новое ПО чаще всего начинается в виде сайта (с использованием типичного стека HTML/JS) и позже для повышения эргономики расширяется на десктопные системы — будь то в виде значка панели Dock, упрощённой интеграции в ОС или просто более специализированного рабочего пространства. Этому паттерну следовали ChatGPT и Perplexity, даже если не переходили на использование Electron. И всё же для многих команд, желающих собрать приложение в кратчайшие сроки, Electron позволяет практически мгновенно получить кроссплатформенную поддержку и обеспечивает столь желанные преимущества веб-среды вроде автоматических обновлений и беспроблемных релизов.

Когда нашим инженерам в Graphite потребовалось легковесное десктопное расширение, мы тоже без раздумий обратились к Electron — особенно, когда увидели возможность авто-обновления. Но я часто задавался вопросом: откуда конкретно взялся столь влиятельный фреймворк? И ответ меня немного удивил — его создали разработчики GitHub.

▍ Эпоха до Electron

История Electron началась не так давно — всего лишь в 2013 году. Ещё до распространения техники поставки веб-приложений в десктопных обёртках разработчики, как правило, писали полностью отдельные нативные решения для каждой платформы. Нужна поддержка Mac? Пишите на Objective-C или Swift и разбирайтесь с Cocoa. Хотите поддержку Windows? Готовьтесь попотеть над C++, C# или .NET. Linux? Ещё веселее. У каждой платформы свои парадигмы UI, идиомы кода и пайплайны сборки, так что согласованное обслуживание мультиплатформенных приложений было болью. Многим командам в итоге приходилось обслуживать по две, а то и три базы кода, каждая из которых имела свои тонкие отличия.

Некоторые кроссплатформенные наборы инструментов вроде Qt или JavaFX предлагали частичное решение этой проблемы, но зачастую вносили сложные уровни интеграции, несогласованную работу UI, а порой и нестабильное быстродействие. Тем временем язык Java посредством своей JVM обеспечивал широкие возможности, но для клиентских десктопных приложений являлся довольно сложным решением. Да, он позволял вам «писать один раз и запускать везде», но не все горели желанием осваивать Swing или JavaFX для создания современного UI. А если вам требовалось написать приложение конкретно для веб-среды, то JVM уже не годилась.

Так что, если вернуться год так в 2010, то создание кроссплатформенного десктопного приложения зачастую было сравнимо с карабканьем в гору по колено в снегу.

▍ Как появился Electron

Но вернёмся в 2013. Создал Electron один из инженеров GitHub, Ченг Жао, и изначально назвал его «Atom Shell». Причём создавал он его не в качестве альтруистического порыва на благо опенсорса, а конкретно для редактора Atom, нового «настраиваемого» редактора GitHub, который опирался на веб-технологии (HTML, CSS и JS), но должен был также работать на десктопе.

Платформа GitHub спонсировала и взращивала этот фреймворк с самого его рождения, поэтому он быстро окреп за счёт тестирования в реальных условиях, обратной связи от разработчиков и обширной базы пользователей — по сути, сообщества Atom.

Иронично, что хоть Atom в итоге и оказался в тени Visual Studio Code, его фреймворк становился всё более зрелым и универсальным. Всего через пару лет «Atom Shell» был переименован в Electron и в 2016 году достиг своего первого устойчивого релиза 1.0. После этого произошло переломное событие: Microsoft начали поставлять VSCode на базе этого фреймворка, чего оказалось достаточно, чтобы сделать его популярным среди многих корпоративных команд разработки.

▍ Взгляд изнутри: ключевые технические решения

Реальным прорывом Electron стало совмещение Node.js и Chromium. Это решение позволило JavaScript взаимодействовать напрямую с нативными возможностями ОС, в то же время отрисовывая браузерный UI, тем самым обеспечив крайне желанную для многих веб-разработчиков комбинацию. Такую многоцелевую архитектуру удалось смоделировать на базе следующей функциональности Chromium:

1. Основной процесс: обрабатывает задачи уровня приложения, такие как создание окон, подключение к API операционной системы и управление общим жизненным циклом. По-сути, это «мозги» вашего приложения Electron.
2. Процессы отрисовки: каждое окно или «представление» выполняется в собственном процессе, отрисовывая HTML, CSS и JavaScript. Такая изоляция повышает стабильность, поскольку сбой отрисовщика не обязательно приведёт к сбою всего приложения.
3. Автоматические обновления: Electron имеет встроенный модуль autoUpdater. Легко забыть, что автоматические обновления в нативном ПО традиционно были диковинкой. В случае же Electron вы получаете их с минимумом хлопот, что является значительным преимуществом при частом развёртывании патчей или инкрементальных релизах новой функциональности.

И такая структура сильно облегчает для нагруженной команды фронтенда релиз десктопной версии веб-приложения. Именно поэтому многие стартапы склоняются к Electron, ведь зачастую быстрый вывод продукта на рынок важнее экономии памяти.

▍ Хлопоты разработчиков: раздутие и избыточность

Electron нередко критикуют — особенно по части раздутия. Каждое приложение Electron содержит собственный экземпляр Chromium, так что, если у вас запущены Slack, VSCode и Discord, то одновременно также запущено три копии Chrome. Подобная ситуация ведёт к массивному потреблению памяти и большому размеру двоичных файлов приложений. Типичная программа «Hello, world» на Electron может весить более 100 МБ, что некоторые пуристы считают чудовищным.

Ещё на заре своего становления у Electron были некоторые проблемы со стабильностью. В случае сбоя отрисовки пользователи иногда наблюдали «белые экраны смерти». В конечном итоге сообщество исправило эту проблему, и современный Electron уже намного надёжнее. Тем не менее сопутствующие издержки могут стать решающими для команд, ставящих акцент на производительности и экономии ресурсов.

Если смотреть с точки зрения безопасности, то приложения Electron, в отличие от современных браузерных вкладок, обычно не изолируются. Одна опрометчивая зависимость или небезопасно загруженный скрипт может предоставить злоумышленнику углублённый доступ в ОС. По этой причине очень важно относиться к разработке на Electron с той же серьёзностью, с какой вы бы отнеслись к безопасности нативных приложений: включайте contextIsolation, ограничивайте возможность удалённого выполнения кода, тщательно подбирайте сторонние пакеты и так далее. Здесь не требуется сверхъестественных усилий — достаточно немного дисциплины.

Интересно, что разработчики некоторых хорошо спонсируемых приложений намеренно избегают Electron. Лучшим из актуальных примеров является ChatGPT: несмотря на то, что OpenAI располагает хорошими производственными мощностями, они создают именно нативные клиенты для Windows, macOS, iOS и прочих платформ. Некоторые считают, что они хотят добиться более глубокой интеграции или быстродействия (хотя, согласитесь, если в названии вашего приложения присутствует «AI», вы наверняка постараетесь не тратить вычислительные ресурсы впустую). Тем не менее для небольшой команды такая задача может стать неподъёмной.

Большинство из нас не имеют достаточно ресурсов для создания и обслуживания нативных реализаций, в связи с чем Electron продолжает оставаться популярным.

▍ Tauri и будущее

В процессе своего развития Electron значительно снизил барьер для входа в сферу разработки десктопного ПО. Разработчики, которые когда-то были ограничены возможностями веб-технологий, теперь могут упаковывать свою работу под вид нативного приложения, не прибегая к созданию отдельной базы кода.

Этот подход привёл к появлению новых идей и прототипов, привнёс свежее веяние в область десктопного ПО и породил серию инструментов вроде Atom, Slack и VSCode, которые было бы слишком затратно создавать нативно под все три платформы. На мой взгляд, реальный успех Electron в том, что он превратил «создание десктопного клиента» из пугающей, узкоспециализированной задачи просто в очередной проект выходного дня.

Естественно, не все согласны на сопутствующие издержки памяти или затраты на комплектацию каждого приложения полноценным Chromium. И в результате появились такие фреймворки, как Tauri, нацеленные на решение конкретно этих проблем. Например, тот же Tauri вместо включения в пакет собственного движка браузера, опирается на нативное веб-представление ОС. Одно только это в некоторых случаях может сократить размер базового приложения со 100 и более МБ до 1 МБ. Бэкенд этого фреймворка написан на Rust, что обеспечивает более высокую производительность и безопасность памяти. Кроме того, это определяет более явные границы функциональности ОС, к которой у приложения есть доступ.

Такое решение привлекательно для команд, которые ценят безопасность или просто не могут позволить себе большие расходы памяти. Tauri по-прежнему развивается, но уже предрекает интригующее будущее, в котором удобство использования «веб-технологий на десктопной системе» может сочетаться с небольшими двоичными файлами и более рациональным потреблением ресурсов.

Как человека, который знаком с Electron ещё со времён «Atom Shell», меня поражает его устойчивое доминирование вопреки всей описанной критике. Для большинства организаций скорость вывода продукта на рынок продолжает являться более важным аспектом, нежели его эффективность. Так что в ближайшем будущем Electron наверняка сохранит свою популярность. Тем не менее взгляд сообщества в целом постепенно меняется. Разработчики всё глубже осознают компромиссы между удобством и производительностью, а на рынке уже развиваются альтернативы вроде Tauri, готовые ощутимо изменить текущее положение дел.

Независимо от того, сохранит ли Electron свою корону, или же в ближайшие годы сдаст позиции, он уже изменил наше восприятие десктопных приложений. Благодаря ему, кроссплатформенная разработка стала интуитивной — и даже интересной — а это уже немалая заслуга.