Я пришел в Electron, имея опыт работы с несколькими кроссплатформенными платформами с графическим интерфейсом на протяжении многих лет. Более 20 лет назад я разработал пользовательский агент электронной почты, используя Xvt, набор инструментов графического интерфейса C / C ++ начала 1990-х годов, затем я работал в Mainsoft над набором инструментов MainWin, который позволил перекомпилировать приложения Windows WIN32 / MFC на Unix / X11, и после этого я проработал более 10 лет в команде Java SE в Sun Microsystems. Последние несколько лет я изучал платформу Node.js и написал несколько книг о написании программного обеспечения с использованием Node.js. Совсем недавно я научился реализовывать приложения с помощью Electron и обнаружил, что это самая приятная платформа с графическим интерфейсом, которую я когда-либо использовал.

Видеть, что Electron называют неповоротливым чудовищем, воплощением концепции Write-Once-Run-Anywhere »… э… разочаровывает. Я видел похожие жалобы на Electron, и, глядя на доступные данные, эта характеристика не выдерживает критики.

В статье есть ряд проблем с претензиями, например:

  • Следы для приложений на основе Java не соответствуют описанию автора.
  • Электронные приложения не являются обременительными в моей среде
  • Приложение на основе Electron имеет такой же объем памяти, что и приложения с собственным кодом.
  • Объединение среды выполнения с приложением упрощает доставку приложения.

Диск и память приложений Java, Electron и Native

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

Развернутое приложение Electron объединяет воедино среду выполнения Electron, а также файлы HTML и JavaScript, используемые в приложении, а также необходимый каталог node_modules, содержащий все зависимые библиотеки. Это правда, что каждое развернутое приложение Electron дублирует среду выполнения и, вероятно, дублирует зависимые библиотеки. Это действительно проблема? У моего ноутбука 1,25 терабайта дискового пространства, я не думаю, что несколько мегабайт дублированного исходного кода JavaScript - большая проблема.

Похожая ситуация существует с приложениями Java. Хотя среда выполнения Java является общим ресурсом, каждое установленное приложение Java требует установки набора JAR, включающего приложение и другие ресурсы. Опять же, проблема с потреблением места на диске?

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

На моем ноутбуке - MacBook Pro Core i7 2012 года с 16 ГБ памяти - в настоящее время я использую Chrome (со многими открытыми вкладками), Postman, Gitkraken, Slack, Visual Studio Code и небольшое количество приложений с собственным кодом, таких как Terminal.app и Preview. .приложение. Просматривая Activity Monitor, я вижу эти измерения объема памяти:

  • GitKraken - 213 МБ
  • Terminal.app - 187 МБ
  • Preview.app - 143 МБ.
  • Код Visual Studio - 123 МБ (открыто несколько окон, в каждом из которых открыто несколько файлов)
  • Почтальон - 110 МБ
  • Slack - 64 МБ

Кажется, что они соответствуют друг другу, хотя я не уверен, как учесть множество возникающих процессов «GitKraken Helper» и «Code Helper» и т. Д.

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

Упущенная возможность для общих библиотек

Следует отметить общие библиотеки и объем памяти. Все современные операционные системы позволяют использовать общие библиотеки между приложениями, эффективно уменьшая объем памяти.

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

Чтобы исправить это, платформа Electron будет поставляться / устанавливаться отдельно от приложений Electron. Это приносит с собой проблему ...

Объединение среды выполнения и приложения упрощает развертывание приложений

Чтобы разрешить разделяемым библиотекам уменьшить объем приложения, необходимо каким-то образом установить разделяемые библиотеки отдельно от приложения.

Вот почему при установке Eclipse, Freemind или любого другого приложения на основе Java необходимо сначала установить экземпляр Java.

На днях моя девушка хотела изучить Mind Mapping, и мы остановились на Freemind, как на бесплатном приложении Mind Mapping с открытым исходным кодом. Но она выполнила инструкции и застряла на шаге 1, который заключался в установке Java, и мне пришлось сделать этот шаг за нее.

В общем, любое приложение, которое сначала требует установки чего-то другого (например, исполняющей платформы), превращается в препятствие для принятия.

Объединение среды выполнения с приложением стирает это препятствие. Это также гарантирует, что приложение работает на той версии платформы, на которой оно было протестировано.

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

Я не собираюсь утверждать, что у Electron нет недостатков. Все, что создано людьми, имеет недостатки.

Написав приложения с графическим интерфейсом пользователя на Motif, Xvt, WIN32 / MFC, Java / Swing, HTML5 + JavaScript, а теперь и на Electron, я возьму Electron в любой день недели.

Начнем с того, что Node.js - это веселая платформа для разработки. Затем приятно писать приложение с использованием HTML + JavaScript, как вы это делаете в Electron. Наконец, Electron позволяет относительно легко собрать все это вместе.

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

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

Неправильная характеристика Java

Требовать:

поскольку все приложения Java зависят от одной и той же JVM, и поскольку Java может иметь огромные различия между версиями, фрагментация стала серьезной проблемой для приложений Java и пользователей.

Можно установить несколько экземпляров JRE / JDK бок о бок, если для данного приложения требуется определенная версия платформы.

Команда разработчиков Java практикует крайнюю обратную совместимость, чтобы любое приложение из прошлого могло работать на текущей JVM. Единственная фрагментация заключается в том, что приложение, написанное с функциями Java 8, не может (конечно) работать на Java 6 или Java 1.1.

Требовать:

На настольных компьютерах Java практически полностью заброшена из-за серьезных проблем, связанных с JVM.

От Java в браузере отказались из-за серьезных проблем с безопасностью, которые невозможно исправить в подключаемом модуле Java. Всем было приказано, но не предупреждено, чтобы они перестали использовать Java в браузере. Настольная Java все еще жива и используется в Netbeans и множестве других приложений. Однако он так и не стал популярным, как мог бы.

И, да, как говорится в статье, приведенной выше, есть место для новой системы WORA, в которой нет проблем с Java.

В мобильное пространство взорвалась не Java, а Android. Тот факт, что вы пишете приложения Android с использованием языка Java и некоторых пакетов среды выполнения Java, не делает Android реализацией Java.

Существуют наборы тестов на наборы тестов, которые используются для проверки того, можно ли назвать данную вещь Java. Android не может пройти эти тестовые наборы и, следовательно, не может называться Java.