Теперь Electron готов к работе

Настольные приложения Электрон создаются с использованием технологий, знакомых миллионам разработчиков программного обеспечения. Это создает низкий входной барьер и во многом объясняет его привлекательность.

Начать легко. Любой, кто знаком с Node.js, может загрузить настольное приложение Hello World! с минимальными усилиями.

Конечно, есть и другой большой плюс: одну и ту же кодовую базу можно использовать для одновременной работы с Windows, Mac и Linux. Все это составляет убедительный аргумент для более внимательного изучения.

Но создание настоящего приложения Electron не для слабонервных. Чтобы превратить первоначальный Hello World! во что-то быстрое и безопасное, нужно приложить усилия. К счастью, безопасность - главная новость для Electron в 2020 году.

2019 - год переворотов

За последний год произошло несколько значительных событий, ставших поворотным моментом в проекте. Прошлогодний путь прошел следующие важные вехи:

  • Регулярные выпуски начались всерьез: с нового года начинается версия 4.0, версия 5.0 - в апреле, версия 6.0 - в июле, а версия 7.0 - в октябре.
  • В марте Electron принял структуру управления, чтобы официально изложить правила поведения и облегчить достижение прогресса.
  • В ноябре Чарльз Керр и его команда представили новый процесс сборки, который значительно сокращает время, необходимое для восстановления Electron при изменении его зависимостей (Node.js, V8 и Chromium).
  • В декабре Electron был добавлен в OpenJS Foundation в качестве инкубационного проекта, сигнализируя сообществу JavaScript в целом, что этот проект никуда не денется.

Начинает чувствовать, что радостная поездка 2014 года перешла в более постепенный долгий путь.

Улучшения безопасности

Некоторые знают, что недавно выпущенный браузер Brave начал свою жизнь как экспериментальный проект Electron.

После серьезной попытки команда Brave в конце концов осознала, что никакое количество кода блокировки не позволит им безопасно получить доступ к произвольным URL-адресам, которые потенциально могут содержать вредоносный код.

Урок для остальной части сообщества Electron был ясен: используйте встроенные в Electron окна браузера Chromium для отображения только локальных страниц.

Для тех разработчиков, которые просто не могли устоять перед соблазном получить доступ к удаленным URL-адресам, совет был немного сложнее: убедитесь, что веб-страницы имеют политику безопасности контента HTTP, которая ограничивает получение JavaScript через небезопасные каналы.

Политики безопасности контента не входят в компетенцию каждого разработчика, поэтому всем, кто хочет делать это правильно, предстоит кое-чему научиться.

Самое страшное во всем этом заключается в том, что встроенная библиотека Electron Node.js дает разработчикам полный доступ к файловой системе и сетевому стеку рабочего стола. Это то, что отличает настольные приложения Electron от простых браузерных приложений.

Таким образом, чтобы снизить риск выхода вредоносного кода из-под контроля, разработчики могут включить параметр sandbox для любого окна браузера, для которого не требуется Node.js. Песочница работает на уровне операционной системы хоста. Это кувалдный подход к блокировке.

Разработчики, которым нужен Node.js и которые решили не использовать параметр sandbox, могут по-прежнему действовать осторожно, правильно установив параметр nodeIntegration.

  • При создании окна браузера, которое обращается к локально размещенным документам, использующим только локально размещенные ресурсы (скрипты, таблицы стилей, изображения или шрифты), nodeIntegration можно безопасно установить в true, разрешая вызовы библиотеки Node.js.
  • С другой стороны, при создании окна браузера, которое может обращаться к произвольным удаленным URL-адресам, nodeIntegration всегда должно быть установлено в false, что блокирует вызовы библиотеки Node.js.

Когда выборочный доступ к Node.js по-прежнему необходим в окне браузера с выключенным nodeIntegration, разработчики могут использовать preload script. В этом типе архитектуры отдельный модуль JavaScript выполняется непосредственно перед созданием окна браузера.

Этот модуль имеет доступ к Node.js на протяжении всего времени существования окна браузера и может выступать в качестве настраиваемого прокси-API. Пока прокси передает только простые значения, а не объекты Node.js, preload script может безопасно получать и устанавливать значения файловой системы и операционной системы от имени окна браузера.

Для еще большей безопасности при доступе к удаленному контенту параметр contextIsolation может быть установлен на true. Эта опция заставит создавать отдельный мир JavaScript для каждого окна браузера.

Изоляция контекста не дает злоумышленникам возиться с цепочкой прототипов JavaScript в ненадежном окне браузера, чтобы тайком получить контроль над надежным кодом в окне браузера-брата.

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

Чтобы помочь с этим, Лука Кареттони из Doyensec создал инструмент с открытым исходным кодом с каламбурным названием Электроотрицательность. Думайте об этом как об инструменте аудита безопасности. Он работает путем сканирования HTML DOM проекта и JavaScript AST для поиска потенциальных уязвимостей.

Любопытное предложение отказаться от «удаленного»

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

К счастью, одна из этих потребностей - повышение производительности. С этой целью на недавней конференции Covalence Conference 2020 было объявлено, что часто используемый модуль remote будет устаревшим в версии Electron 9.0 и полностью удален в версии 10.0.

Это стало неожиданностью. Как-то я пропустил опубликованную ранее статью Джереми Апторпа Дистанционный модуль Electron считается вредным.

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

С одной стороны - основной процесс приложения, который отвечает за запуск всего. С другой стороны, есть процессы средства визуализации приложения. Эти два взаимодействуют с помощью межпроцессного взаимодействия (IPC).

Ключ к освоению разработки Electron - это понимание того, как использовать ipcMain и ipcRenderer для координации всего. Вот здесь и пригодится удаленный модуль. Он делает вызовы IPC от процесса рендеринга к основному процессу очень простыми, позволяя простым смертным делать больше.

Во всех приложениях Electron, с которыми я работаю, remote.getGlobal() используется стратегически и эффективно. Каждый раз он работает так, как ожидалось.

Причины очернения remote и моих собственных контраргументов таковы:

  • Аргумент: требуется 0,1 мс на вызов IPC. Контрапункт: Это арахис. В мгновение ока (при частоте кадров 16 мс на обновление экрана) можно было сделать 160 вызовов IPC.
  • Аргумент: неправильное использование может привести к гонке. Контрапункт: настройка прослушивателей обратных вызовов перед выполнением устраняет этот класс проблем.
  • Аргумент: удаленные объекты передаются через прокси и теряют свою цепочку прототипов. Контрапункт: Правильная десериализация и приведение к правильному типу объекта позволяют использовать результат без сюрпризов.
  • Аргумент: уязвимость системы безопасности ждет своего часа. Контрапункт: это неуместный аргумент. Изображения PNG, поступающие из основного процесса, могли развернуть свои вредоносные полезные нагрузки независимо от любого вызова IPC.

Я лично считаю, что это заходит слишком далеко, и надеюсь, что план по прекращению поддержки модуля remote не выполняется. Тем не менее, я ценю внимание к деталям. Приятно знать, что настройка производительности Electron достигла уровня, когда 0,1 мс считается важным.

Готовность к работе

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

На фоне всей шумихи вокруг кроссплатформенных возможностей Electron было упущено то обстоятельство, что необязательно использовать все три таргетинга.

Я разговаривал с множеством людей на конференции, которые специально ограничивали свои усилия по разработке для оптимизации для аудитории Windows. Терри Торсен из ChartIQ хорошо представил этот случай.

Тот факт, что программистов на C ++ становится мало, не секрет. Столь же очевиден рост числа разработчиков, ориентированных на JavaScript. Так что неудивительно, что Electron готов дать Microsoft шанс заработать свои деньги.

Старые приложения MFC, которым требуется свежее лицо с великолепным стилем, являются особенно хорошими кандидатами для переписывания с помощью Electron. И мои деньги тоже идут на C # и Visual Basic.

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

Дорожная карта на 2020 год

Я не видел дорожной карты на 2020 год и последующий период, но если темп выпуска релизов в прошлом году сохранится, мы можем ожидать появления версий 8, 9, 10 и 11 в течение следующих двенадцати месяцев.

Мой личный список желаний включает:

  • Лучшая поддержка на уровне приложений для межпроцессного взаимодействия (IPC). Поскольку мы не можем использовать события или обратные вызовы для пересечения границы main / renderer, большая часть каждого приложения Electron обрабатывает строительные леса для передачи данных. В настоящее время каждый должен кататься самостоятельно.
  • Лучшая поддержка переменных уровня приложения. Поскольку средствам визуализации необходимо получать и устанавливать состояние приложения, имеет смысл иметь некоторый выделенный объект состояния, к которому могут получить доступ как основной процесс, так и отдельные средства визуализации. В настоящее время все это делается с помощью remote.getGlobal(). Он примитивен и выполняет свою работу, но я бы проголосовал за что-то более сложное.
  • Встряхивание деревьев. Приложения Electron переполнены кодом, который никогда не вызывается. Приятным дополнением к финальному процессу сборки asar будет этап, на котором анализируется, какие файлы можно удалить. Я понимаю, что это может занять много времени, но я бы, например, воспользовался им без ропота.
  • Инструмент для удаления ворса Electron. По мере роста проекта будут обнаруживаться более эффективные способы решения задач, а старые способы будут считаться устаревшими. Наличие инструмента для сканирования нашего приложения и предложения способов его улучшения с помощью этих новых функций сделало бы любое приложение более быстрым и безопасным.