Electron: разработка настольных приложений с использованием HTML, CSS и JavaScript

https://medium.freecodecamp.org/how-to-easily-build-desktop-apps-with-html-css-and-javascript-d3e3f03f95a5
  • Перевод
Можно ли, используя HTML, CSS и JavaScript, создавать настольные приложения? Автор статьи, перевод которой мы сегодня публикуем, даёт утвердительный ответ на этот вопрос. Здесь он расскажет о том, как, применяя веб-технологии и пользуясь возможностями фреймворка Electron, создавать кроссплатформенные приложения для настольных операционных систем.



Electron


Electron — это фреймворк для разработки настольных приложений с использованием HTML, CSS и JavaScript. Такие приложения могут работать на различных платформах. Среди них — Windows, Mac и Linux.

В основе Electron лежат проекты Chromium и Node.js, объединённые в единую среду, обеспечивающую работу приложений. Это даёт возможность применять веб-технологии при разработке настольных программ.

Electron — серьёзный проект, который использован при создании множества популярных приложений. Среди них — мессенджеры Skype и Discord, редакторы для кода Visual Studio Code и Atom, а также — ещё более 700 приложений, сведения о которых опубликованы на сайте Electron.

Electron Forge


Для разработки приложения с использованием Electron этот фреймворк надо настроить. Это касается и тех случаев, когда в приложении планируется применять другие фреймворки или библиотеки, например — Angular, React, Vue, или что-то другое.

Инструмент командной строки Electron Forge позволяет серьёзно упростить процесс настройки Electron. Он даёт в распоряжение разработчика шаблоны приложений, основанных на Angular, React, Vue, и на других фреймворках. Это избавляет программиста от необходимости настраивать всё вручную.

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

Рассмотрим процесс разработки простого приложения на Electron с использованием Electron Forge.

Предварительная подготовка


Для того чтобы приступить к разработке Electron-приложений с использованием Electron Forge вам понадобится система с установленной платформой Node.js. Загрузить её можно здесь.

Для глобальной установки Electron Forge можно воспользоваться следующей командой:

npm install -g electron-forge

Создание шаблонного приложения


Для того чтобы создать шаблонное приложение с использованием Electron Forge выполним следующую команду:

electron-forge init simple-desktop-app-electronjs

Эта команда инициализирует новый проект приложения, имя которого — simple-desktop-app-electronjs. На выполнение этой команды понадобится некоторое время. После того, как шаблонное приложение будет создано, запустить его можно так:

cd simple-desktop-app-electronjs
npm start

Здесь мы переходим в его папку и вызываем соответствующий npm-скрипт.

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


Окно приложения, созданного средствами Electron Forge

Поговорим о том, как устроено это приложение.

Структура шаблонного приложения


Материалы, из которых состоит шаблонное приложение, создаваемое средствами Electron Forge, представлены набором файлов и папок. Рассмотрим важнейшие составные части приложения.

▍Файл package.json


Этот файл содержит сведения о создаваемом приложении, о его зависимостях. В нём имеется описание нескольких скриптов, один из которых, start, использовался для запуска приложения. Новые скрипты в этот файл можно добавлять и самостоятельно.

В разделе файла config.forge можно найти специфические настройки для Electron. Например, раздел make_targets содержит подразделы, описывающие цели сборки проекта для платформ Windows (win32), Mac (darwin) и Linux (linux).

В package.json можно найти и запись следующего содержания: "main": "src/index.js", которая указывает на то, что точкой входа в приложение является файл, расположенный по адресу src/index.js.

▍Файл src/index.js


В соответствии со сведениями, находящимися в package.json, основным скриптом приложения является index.js. Процесс, который выполняет этот скрипт, называется основным процессом (main process). Этот процесс управляет приложением. Он используется при формировании интерфейса приложения, в основе которого лежат возможности браузера. На нём же лежит ответственность за взаимодействие с операционной системой. Интерфейс приложения представлен веб-страницами. За вывод веб-страниц и за выполнение их кода отвечает процесс рендеринга (renderer process).

▍Основной процесс и процесс рендеринга


Цель основного процесса заключается в создании окон браузера с использованием экземпляра объекта BrowserWindow. Этот объект использует процесс рендеринга для организации работы веб-страниц.

У каждого Electron-приложения может быть лишь один основной процесс, но процессов рендеринга может быть несколько. Кроме того, можно наладить взаимодействие между основным процессом и процессами рендеринга, об этом мы, правда, здесь говорить не будем. Вот схема архитектуры приложения, основанного на Electron, на которой представлен основной процесс и два процесса рендеринга.


Архитектура Electron-приложения

На этой схеме показаны две веб-страницы — index.html и abcd.html. В нашем примере будет использоваться лишь одна страница, представленная файлом index.html.

▍Файл src/index.html


Скрипт из index.js загружает файл index.html в новый экземпляр BrowserWindow. Если описать этот процесс простыми словами, то оказывается, что index.js создаёт новое окно браузера и загружает в него страницу, описанную в файле index.html. Эта страница выполняется в собственном процессе рендеринга.

▍Разбор кода файла index.js


Код файла index.js хорошо прокомментирован. Рассмотрим его важнейшие части. Так, следующий фрагмент кода функции createWindow() создаёт экземпляр объекта BrowserWindow, загружает в окно, представленное этим объектом, файл index.html и открывает инструменты разработчика.

// Создаём окно браузера.
mainWindow = new BrowserWindow({
  width: 800,
  height: 600,
});

// и загружаем в него файл приложения index.html.
mainWindow.loadURL(`file://${__dirname}/index.html`);
// Открываем инструменты разработчика.
mainWindow.webContents.openDevTools();

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

В коде этого файла часто встречается объект app. Например — в следующем фрагменте:

// Этот метод будет вызван после того, как Electron завершит
// инициализацию и будет готов к созданию окон браузера.
// Некоторые API можно использовать только после возникновения этого события.
app.on('ready', createWindow);

Объект app используется для управления жизненным циклом приложения. В данном случае после завершения инициализации Electron вызывается функция, ответственная за создание окна приложения.

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

Теперь, когда мы ознакомились со структурой Electron-приложения, рассмотрим пример разработки такого приложения.

Разработка настольного приложения — конвертера температур


В качестве основы для этого учебного приложения воспользуемся ранее созданным шаблонным проектом simple-desktop-app-electronjs.

Для начала установим пакет Bootstrap, воспользовавшись, в папке проекта, следующей командой:

npm install bootstrap --save

Теперь заменим код файла index.html на следующий:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Temperature Converter</title>
    <link rel="stylesheet" type="text/css" href="../node_modules/bootstrap/dist/css/bootstrap.min.css">

  </head>
  <body>
    <h1>Temperature Converter</h1>
    <div class="form-group col-md-3">
      <label for="usr">Celcius:</label>
      <input type="text" class="form-control" id="celcius" onkeyup="celciusToFahrenheit()">
    </div>
    <div class="form-group col-md-3">
      <label for="pwd">Fahrenheit:</label>
      <input type="text" class="form-control" id="fahrenheit" onkeyup="fahrenheitToCelcius()">
    </div>
    <script src='./renderer.js'></script>
  </body>
  </body>
</html>

Вот как работает этот код:

  1. Здесь создаётся текстовое поле с идентификатором celcius. Когда пользователь вводит в это поле некое значение, которое должно представлять собой температуру в градусах Цельсия, вызывается функция celciusToFahrenheit().
  2. Текстовое поле с идентификатором fahrenheit, также создаваемое в этом коде, принимает данные от пользователя, которые должны представлять собой температуру в градусах Фаренгейта, после чего вызывается функция fahrenheitToCelcius().
  3. Функция celciusToFahrenheit() конвертирует температуру, выраженную в градусах Цельсия и введённую в поле celcius, в температуру в градусах Фаренгейта, после чего выводит то, что у неё получилось, в поле fahrenheit.
  4. Функция fahrenheitToCelcius() выполняет обратное преобразование — берёт значение температуры, выраженное в градусах Фаренгейта и введённое в поле fahrenheit, преобразует его в значение, выраженное в градусах Цельсия, после чего записывает то, что у неё получилось, в поле сelcius.

Две функции, о которых мы только что говорили, объявлены в файле renderer.js. Этот файл нужно создать в папке src и поместить в него следующий код:

function celciusToFahrenheit(){
    let celcius = document.getElementById('celcius').value;
    let fahrenheit = (celcius* 9/5) + 32;
    document.getElementById('fahrenheit').value = fahrenheit;

}

function fahrenheitToCelcius(){
    let fahrenheit = document.getElementById('fahrenheit').value;
    let celcius = (fahrenheit - 32) * 5/9
    document.getElementById('celcius').value = celcius;
}

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

Будем считать, что приложение готово. Испытаем его.

Запуск приложения


Для того чтобы запустить приложение, воспользуемся следующей командой:

npm start

После её успешного выполнения будет открыто окно приложения со следующим содержимым.


Окно приложения-конвертера

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

Упаковка приложения


Для того чтобы упаковать приложение, воспользуйтесь следующей командой:

npm run package

На выполнение этой команды системе понадобится некоторое время. После того, как её работа завершится, загляните в папку out, которая появится в папке проекта.

Эксперимент по разработке Electron-приложения, описанный здесь, проводился на компьютере, работающем под управлением ОС Windows. Поэтому в папке out была создана папка simple-desktop-app-electronjs-win32-x64. В этой папке, кроме прочего, можно найти .exe-файл приложения. В нашем случае он называется simple-desktop-app-electronjs.exe. Для запуска приложения достаточно обычного двойного щелчка мышью по этому файлу.

Разберём имя папки, в которую попал исполняемый файл приложения. А именно, он построен по шаблону имя приложения - платформа - архитектура. В нашем случае его структура раскрывается так:

  • Имя приложения — simple-desktop-app-electronjs.
  • Платформа — win32.
  • Архитектура — x64.

Обратите внимание на то, что при вызове команды npm run package без параметров, по умолчанию, создаётся исполняемый файл приложения для той платформы, которая используется в ходе разработки.

Предположим, вам нужно упаковать приложение для какой-то другой платформы и архитектуры. Для этого можно воспользоваться расширенным вариантом вышеописанной команды. Структура этой команды выглядит так:

npm run package -- --platform=<platform> arch=<architecture>

Например, для того чтобы сформировать пакет приложения для Linux, можно воспользоваться следующей командой:

npm run package -- --platform=linux --arch=x64

После завершения её работы в папке проекта out появится директория simple-desktop-app-electronjs-linux-x64 с соответствующим содержимым.

Создание установочных файлов приложений


Для того чтобы создать установочный файл приложения воспользуйтесь следующей командой:

npm run make

Результаты её работы окажутся в уже знакомой вам папке out. А именно, запуск этой команды в вышеприведённом виде на Windows-машине приведёт к созданию установочного файла приложения для Windows в папке out\make\squirrel.windows\x64. Как и команда package, команда make, вызванная без параметров, создаёт установщик для платформы, используемой при разработке.

Итоги


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

Уважаемые читатели! Пользуетесь ли вы фреймворком Electron для разработки настольных приложений?

RUVDS.com
1039,00
RUVDS – хостинг VDS/VPS серверов
Поделиться публикацией

Комментарии 77

    +7
    Не пишите декстопный софт на JS! Не надо издеваться над пользователями. Вспомните адский шит под названием Скайп написанный на Электроне.
      +8
      Основные проблемы скайпа (нестабильность, баги, путешествия сообщений «во времени» и т.д.) вызваны совсем не использованием электрона.
        +8
        150 мегабайт отжираемой памяти для звонилки висящей в фоне, кастрирование настроек и тормоза при запуске тоже не от электрона?
        Минимальные требования и объём любой шняги на этом чудо-движке будут >= требованиям nodejs. Не надо мне на компьютер ради софтины конвертирующей температуру тащить ещё одну обособленную версию хромиума.

        Для сравнения плагин на pidgin, например, реализующий обмен по протоколу скайпа весит ~1mb, и сам pidgin весит ещё 4. Но проблема, конечно, не в электроне.
          +2
          150 мегабайт это конечно треш… Как мы дошли до жизни такой? Ту же софтину конвертирующую температуру можно собрать на нативном языке. Она будет весить 20 килобайт максимум, работать мгновенно и на всех существующих версиях Windows.
            +2
            Кстати, посоветуйте, на чём и в какой IDE в наше время пишут под Window?
            А то порой бывает нужно написать какую-нибудь мелочь (типа того же конвертера температур) для собственного пользования, а я со времён VB98 на нативных языках не писал.
              –2
              Я пишу на Delphi/Lazarus, быстро и просто. От мелочи, до милионно-строчных проектов.
                +1
                Delphi (хотя сейчас понабегут хоронители с лопатами)
                  +2
                  совсем простые штуки пишу на html+js -> .hta
                  если хочется именно IDE, то приятный минималистический вариант — PureBasic. Free version имеет ограничения: максимум 800 строк кода, нельзя использовать API, нельзя создавать DLL.
                  Компилирует код в standalone приложения небольшого размера (простая форма с несколькими контролами ~50KB).
                    +2
                    hta

                    Там же вроде какой-то доисторический trident в качестве движка?
                    +1
                    Visual Studio как среда, C# как язык, WinForms как GUI-библиотека (особенно если есть опыт со старым VB, WPF все-таки немного взрывает мозг для неподготовленного) — очень приятная и довольно простая для первых шагов связка.

                    В той же студии, кстати, и VB.net есть, правда, не знаю ни одного человека, который бы на нем писал)
                      0
                      В той же студии, кстати, и VB.net есть, правда, не знаю ни одного человека, который бы на нем писал)

                      Я немножко пробовал, но честно говоря, по прошествии лет, предпочитаю языки с фигурными скобочками. Чисто зрительно удобнее.
                      0
                      Visual Studio Community Edition, правда на работе всё равно поставить будет нельзя. Если же использовать .net core, можно в том же VS Code. Можно в блокноте, правда с отладкой в этом случае будет не очень.
                        0
                        Community-версию можно использовать и на работе в случае in a classroom learning environment, for academic research, or for contributing to open source projects, либо же up to five users в non-enterprise organizations:
                        visualstudio.microsoft.com/license-terms/mlt553321
                        0
                        Что-то вам какой-то суровой жести насоветовали. Visual Studio конечно хорошо, но в нём ещё разобраться надо, а результат (как программа, так и ваше обучение) будет намертво привязан к винде.
                        Попробуйте Qt. В комплекте идёт простая, но вполне достаточная IDE QtCreator. А главное, один раз выучив, можно писать под все платформы практически идентично, включая Андроид. А ещё, если надоест C++, можно перейти на Python: API практически совпадает тоже. С той разницей, что Qt для C++ объявляет примитивы, которые в Python уже есть, а Qt для Python их больше не велосипедит.
                        Можете сразу с Python начать. PyCharm отличная бесплатная IDE. Да и на VSCode и других про-блокнотах питонить не сложно. На Python можно генерить обособленные EXE-шники. Но они будут тоже страдать лишним весом в 6Мб на среду и интерпретатор.
                          –2
                          Но они будут тоже страдать лишним весом в 6Мб на среду и интерпретатор.
                          Ну и с гуём в Питоне не очень. В том смысле, что консоль онли. Только если внешнее что-то подключать. Ну и скорость, как у любых скриптов, на троечку, если не на двоечку. Так что местами там тоже суровая жесть :)
                          Delphi/Lazarus. Скорее всего свою первую (неконсольную) программу Hello world вы сможете написать минут за 10 :) 9 — просмотр подходящего видео, 1 — остальное.
                          Delphi Community Edition — отличная бесплатная полнофункциональная среда (ограничение — зарабатываемые на ней деньги, до $5000 в год), блокнотить не нужно :)
                          Лазарус — бесплатный полностью. Качество постепенно приближается к Delphi и местами превосходит. Сама среда запускается почти на чем угодно, вплоть до утюгов :) Win, Linux, Mac, Raspbery и так далее. Ну и, само собой, собирает под это всё.
                            0
                            А как оно сделает GUI на Linux? На каком тулките?
                              0
                              В Лазарусе это LCL — кросс-плафторменная библиотека. Можно собрать с одним кодом и одними формами под все платформы и отлаживать по месту прямо, удобно. У нас несколько программ в продакшне, уже продаём, на Линукс в том числе.
                          0
                          MS VC++, C Builder, Qt Creator, C#, Delphi, VB6, PowerBasic, etc…
                          +2
                          все версии windows любят не только лишь все
                          более того многие не любят никакую версию windows
                            +1
                            Но, согласитесь, это не повод в каждое приложение класть 50 метров обвязки.
                            Вот если бы можно было движок установить раз и навсегда, а не запаковывать внутрь каждого приложения — было бы замечательно.
                              –2
                              .Net, Java и т.д.
                              Просто взрывной рост веба породил кучу лишних js-программистов. Которые теперь пытаются найти себя в десктопной разработке.
                                0
                                Ерунда. Нет никаких лишних js-программистов — их как раз не хватает. Много лишних js-обезьян, которые даже в прототип не врубились.
                                  +1
                                  Ну дык, обезьяны-то по итогу рекламятся как «профессиональные разработчики со стажем».
                                  Js позволяет прокатившись лицом по клавиатуре получить кое-как, но работающий код, потому обезьяны массово туда и валят.
                                    0
                                    Угу… И, честно говоря, я опасаюсь, что по мере появления в JS «всего того что есть в „нормальных языках“ », обезьян среди нас, javascript'еров, станет в процентном отношении больше: им же даже спеку не придётся читать.
                              0
                              Тот же Delphi уже давно кросс-платформенная. Да и Жава, Дотнет (частично) только что не натив.
                              +8
                              Сломали монополию MS, вот и дошли. Все девяностые об этом мечтали, и даже первую половину нулевых, ну вот и получили. Имеем дичайшую фрагментацию, и полную неготовность средств разработки к этой фрагментации.
                              В стандартных библиотеках современных кроссплатформенных ЯП до сих пор нет инструментов построения UI, а единственный более-менее работающий кроссплатформеный фреймворк — это Qt, который сам жрёт как пол-Электрона, разве что работает пошустрее. И то для его подключения и интеграции нужно очень уж много лишних телодвижений проделать.
                              Именно проблему фрагментации и решает Electron. Это среда, которая просто берёт и просто работает. Где вы можете сразу начинать писать кроссплатформенный код без необходимости предварительной установки Kubernetes и всяких виртуалок-контейнеров, чтоб просто собрать ваше приложение под десяток различных платформ.
                              Где все проблемы с железом и различными операционками берёт на себя разработчик самого фреймворка. И вы можете сосредоточиться на решении именно своей задачи, а не на способах заставить приложение запускаться на очередном экзотическом дистрибутиве Linux.
                                +2
                                К сожалению, это только в теории. На практике билдить приходится в виртуалбоксах потому что «нативные» зависимости вроде sqlite, sharp и т.п. нельзя билдить иначе. Может понадобиться для некоторых платформ руками перекладывать потом dll-ки в node_modules из-за того что билдер их положил не туда. Добавлять под каждую ось всякие хаки, чтобы иконки отображались в таскбарах правильные, диалоговые окна работали и т.п.
                            0
                            Клиент на электроне ужасно тормозил и был дико неудобен из-за кривизны интерфейса.
                            Я конечно понимаю, что веб-разработчики хотят запихнуть весь софт в браузер, но существуют разумные ограничения. Для десктопного софта существуют соответствующие среды разработки и инструменты.
                            +4
                            Современный Скайп ужасен во всех своих проявлениях. Юзаю на Windows и Андроид. На Андроиде постоянно всё вымораживается. На Винде просто гора разнообразных глюков. От полной неотрисовки окон и частей (смайлов и т.д) до слетевшего логина, и так постоянные тормоза. Пока был на Delphi, был на порядок приятнее и стабильнее. Но тут пришел хайп :(
                              0

                              На андроид какой-то садом с настройкой звука вызова в skype. Раньше подстраивался под громкость мультимедиа, потом начал подстраиваться под громкость звонка. Последний раз использовалась "громкость при разговоре", заорало при полностью выключенном в телефоне звуке. Удалил без сожалений.

                              +7
                              Вспомните шикарную Visual Studio Code и не менее прекрасный Atom. А глючный софт можно на любом языке написать
                                –4
                                я так же шикарно чувствую тормоза при их использовании
                                  +3

                                  Мне сложно в это поверить. У меня VS Code с кучей расширений, более плавно работает, чем тот же sublime (без расширений). Памяти конечно больше кушает, но по скорости довольно шустро.

                                    +1

                                    А мне трудно поверить, что хорошо написанный софт на плюсах работает медленнее, чем хорошо написанный софт на js, работающий в виртуальной машине, да ещё и с плагинами)

                                      0

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

                                  +1
                                  Не вижу ничего прекрасного в простом текстовом редакторе, который на маленьком проекте может сожрать до 2гб оперативки, а по Find defenition переходить секунд 10. Позиционировался вроде как быстрый и легкий аналог VS, а в результате тупит еще страшнее.
                                  Тот же сублайм на аналогичном проекте занимает 400мб памяти и не тормозит абсолютно.
                                    +1
                                    > а в результате тупит еще страшнее.

                                    при этом может гораздо меньше.
                                      +1
                                      Работаю на VS Code уже более года и не могу представить на каких древних пк вы работаете если он у вас тупит. За все время работы несколько раз подвисал, в таких случаях просто закрываю приложение и открываю заново, это занимает секунд 15, после чего все прекрасно работает. Тот же Sublime стабильно падает и виснит, про расширения в саблайме вообще молчу, постоянные танцы с бубнами. 2 года работал в Sublime после установки VS Code удалил саблайм на 3-й день, перейти было очень просто, так как они очень похожи.
                                      +1
                                      Ну не у всех на рабочих компах стоит по 16Гб и больше, не надо тут говорить. На мелком проекте постоянно выжрано 2Гб+ и проц нагружен по самое нехочу, шпарит просто без остановки. Помимо VS Code надо открыть браузер, который тоже жрёт 2Гб+, надо открыть мессенджеров несколько, надо запустить webpack dev server, который жрёт 1Гб минимум. А ещё на работе стоит антивирусник, который тоже жрёт ресурся порядочно. И у меня на 8Гб постоянно всё в глубоком свапе живёт.
                                      0
                                      Откуда такая уверенность в том, что в Скайпе используется именно электрон? Вообще похоже что скайп крутится в Эдже. Ошибки, что в скайпе что в эдже одинаковые и происходят при подобных обстоятельствах.
                                      +1
                                      если дискорд и скайп — это примеры хороших проектов, то просто огонь. использовать чисто вебовские технологии для написания десктоп приложений — это пять! можно конечно и наждачной бумагой подтираться, но обычно люди берут мягкую.
                                        0
                                        С каких пор дискорд чисто десктопный? его прелесть то как раз что он везде одинаково работает. Что веб, что десктоп, что андроиды. Попеременно активно пользуюсь везде. Для меня единственный существенный минус дискорда, это слабенький поиск по истории.
                                        –1

                                        Вспомните очень популярный и очень пиаренный на том же хабре редактор visual studio code, он написан на Electron, так что не надо.

                                          0
                                          А кто-нибудь пробовал Sciter?
                                          +6
                                          Могу сказать, что Электрон далеко не всегда и не для всех выход.
                                          Но когда понадобилось переписать три версии приложения для трех разных систем, написанных на разных платформах в разное время и разными людьми, то я был рад, что существует Электрон. Плюс еще получилась готовая не плохая web-версия этого же приложения с той же кодовой базой, так что могу сказать, что я остался доволен.
                                            –1
                                            Electron это палочка-выручалочка, когда надо веб-страницу представить в виде приложения. Но не надо использовать его как платформу для разработки. Ну пожаааалуйста. Это слишком неэффективно по части вычислительных ресурсов. Сам я не пользуюсь тем, что обернуто в электрон — скайпа хватило с головой.
                                              +2
                                              И чем плох «просто Java»? Также работает на всех трех. Более чем объёмные приложения не тормозят совсем. Пример — все присутствующие знают продукцию JetBrains
                                                –1
                                                Точно, попробуйте Visual Studio + Resharper C++ + Unreal Engine. Вот повеселитесь. Парсит исходы более получаса, почти любое действие в визуалке открывает модальный диалог с инфой о парсинге. После парсинга каждые 1-2 секунды подвисание на 2-3 секунды. Отличная работа JetBrains. На примере WebStorm, открыл пару довольно больших текстовых файла, начались лютые тормоза, проц выжран очень знатно, закрыл, а ничего не изменилось, спасает только перезапуск среды. Только не надо тут про то, что Java не умеет работать с большим объёмом текста, я как пользователь об этом знать не должен.

                                                P.S. Если заменить Resharper C++ на Visual Assist (чем всегда и пользовался), то проблемы пропадают, парсит за пару минут, тормозов нет, функционала в основном больше. Resharper разве что ститический анализ чутка даёт. Но так как не особо он и полноценен, приходится в любом случа пользоваться иными инструментами.
                                                  0
                                                  Resharper — не единственное изделие JetBrains. Возможно, в вашем случае проблема в совместной работе с Visual Studio, да ещё и на Windows. Я активно пользуюсь (причем одновременно) — PHPStorm, DataGrip, Golang. В фоне ещё висит вся среда исполнения проекта — длинный список, не буду утомлять. Ничего не тормозит — правда, вся работа исключительно на Ubuntu. Машина — i7 с 6-ю ядрами, 16Gb + 1 Tb SSD. Microsoft принципиально отсутствует как класс — внутреннее правило казённой академической конторы.
                                                    0
                                                    Ну это домашний пример, домашний проект в виде хобби. При этом памяти 32Гб, но всё тормозит жутко, забил в итоге на Resharper C++.

                                                    На работе же WebStorm, плюс инструменты необходимые в работе, 8Гб, уже в притык. Есть ещё машина, где уже используется VS Code, и сопутствующее, вот там 8Гб уже не хватает в принципе. Так что да, WebStorm оптимальнее.

                                                    Но я ещё помню переход кодовой базы Visual Studio c С++ на .NET и помню повышение потребление оперативки с порядка 200Мб до 900Мб на нашем проекте. Это более показательно, разработчики ПО забивают на потребление памяти, они хотят экономить время скидывая это на потребителей.
                                                      0
                                                      В вашем комментарии косвенно видна основная тема текущего обсуждения — все рассматриваемые инструменты задумывались, как кросс-платформенные. Т.е. по умолчанию в них ОБЯЗАТЕЛЬНО тянется за изделием универсальная среда исполнения — виртуальная машина в том или ином виде. Движок Chromium здесь также можно рассматривать как специфическую виртуальную машину. Так что обсуждаем, по факту, сравнительную эффективность однотипных в общем то решений. Сравнивать их с продуктами, у которых принципиально другая основа (Visual Studio на базе C++) — методически неверно. Они ВСЕГДА будут принципиально экономичней и быстрее. Вот родит кто-нибудь IDE на Go или Rust — тогда их можно будет сравнить с VS на С++. А так получается «мягкое с круглым»
                                                        0
                                                        Visual Studio на базе C++ и .NET приведены просто для примера, как нечто, где есть явное сравнение. И я указал лишь для указания того, что разработчики скидывают затраты на разработку на потребителей.

                                                        Electron по определению использует webkit и никуда от него не деться и он кроссплатформенный, при этом инструменты на Java тоже кроссплатформенны и тут я соглашусь оригинальным сообщением, что всё же решения на Java меньше жрут ресурсов, чем Electron. Но тенденция показанная на базе Visual Studio наблюдается и в использовании Java.
                                                          0
                                                          Это да — в соревновании «виртуальных машин» Java, .NET и webkit — последний явно аутсайдер. И его использование оправдано только в том случае, если разработчик просто ничего, кроме JavaScript не знает. Считаем комплексные расходы на разработку, использование и поддержание продукта — сюда входит и стоимость времени разработчика, и стоимость эксплуатации готового продукта, и его поддержка автором. По интегральному параметру стоимости продукт на Electron становится оправданным только в том случае, если провальные расходы на эксплуатацию компенсируются экономией на разработке и поддержке.
                                                            0
                                                            Не думаю, что расходы на эксплуатацию учитывают, особенно если это не внутренний продукт.

                                                            Да и выбирают сейчас JS всё же из-за порога вхождения. К примеру WPF инструмент конечно мощный, но чтобы там сделать что-то большее чем просто конвертор температуры, нужно знатно поучиться.

                                                            Соответственно выбор в компаниях, где хотят продукт, но не хотят затрат выбор очевиден. Скайп очень показателен. Они ведь не выбрали WPF, хотя имеют в штате разработчиков знающих WPF на 5 порядочно, да и имеют средства на это.
                                                              0
                                                              В случае Скайпа Микрософт опять попытался просто грубо нажиться на купленной у третьей компании клиентской базе — надо же затраты на покупку отбивать. Поэтому посадили на «новый» Скайп дешёвых стажеров, которые умеют делать хоть что-то только на JS (тот самый «низкий порог вхождения»). Загрузить этой работой дорогих спецов по .NET — жаба задушила. Ну это вполне в стиле корпоративной политики этой компании — принцип «любая деятельность, приносящая прибыль — является основной» гипертрофирован до состояния маразма.
                                                          0
                                                          Visual Studio на базе C++

                                                          Это могло быть сказано про v6. Сейчас GUI там активно переносится на .NET
                                                      +1
                                                      У них там какой-то косяк в последних релизах, который проявляется в том, что начинается какой-то бесконечный парсинг от которого все тормозит. Причем не завист от размера проекта, у меня был небольшой проект в котором сие начиналось после открытия одного конкретного небольшого файла. Закрытие файла и проекта не помогало. В phpstorm проявлялось. И в интернетах гуляют аналогичные жалобы. Так что это вероятнее всего какой-то отдельный баг, который (недеюсь) пофиксят.
                                                    0

                                                    Помню, как на Delphi меня огорчал размер exeшника. Я даже "огромный" VCL на KOL переписал, знатно покрасноглазив, чем уменьшил размер с 1.5 мбайт до 60 кбайт. А потом еще upx'ом сжимал даже вроде.
                                                    Эх, где то мы свернули не туда...

                                                      +3

                                                      Давайте вместе поможем Даше найти электрон приложения!


                                                      Большая картинка


                                                        0
                                                        Там что-то «электронное», кроме скупе запущено? (Telegram — C++/Qt(Widgets), VirtualBox — Java, Nodepad++ — C++) FF разве что с GUI на веб-технологиях, хоть и не электрон, но его результаты ожидаемы.
                                                          –1
                                                          Хм. Телеграм жрёт как электрон, был уверен что на нём. А так по задумке Skype и Telegram, и это ещё Slack не запущен…
                                                      +1
                                                      Вот «почему-то» хочется найти всех разработчиков использующих Electron и оторвать всё что оторвётся. Помню те времена, когда 4Гб хватало, а тут пару приложений запустил и 8Гб уже не хватает.
                                                        0
                                                        Какие-то не те времена вы помните. Я помню когда хватало 64Кб (8 x K565РУ5). Оторвать всем разработчикам все?
                                                          +1
                                                          Знаете, когда двухмерная оконная аркада жрёт системы больше чем 3D-бегалка начала века (ну да, 3D там было чисто условные, но тем не менее) — это настораживает.
                                                            0
                                                            Не настораживает вообще. Потому что бывали (и есть) системы которые без всяких бегалок сжирали сами себя, только оставь ее на пару дней. И никто никому ничего не отрывал.
                                                              0
                                                              И никто никому ничего не отрывал.

                                                              Я полагаю, зря?
                                                                0
                                                                Ничто не рождается сразу идеальным. Когда то тетрис сжирал всю систему.
                                                                  0
                                                                  Верно, но когда тенденция обратная — это ненормально.
                                                                    0
                                                                    Вся история IT показывает, что нормально.
                                                                      0
                                                                      Да, если понимать норму в статистическом смысле — то действительно нормально.
                                                        –1
                                                        ru_vds Спасибо за перевод! Возможно он облегчит моё понимание. Но сходу возникли два вопроса: Возможно ли при помощи Electron Forge запустить и собрать любое electron-приложение, найденное на просторах github.com? И как тогда быть с требованиями документации по сборке в Windows? Там требуется python 2.7.
                                                          0
                                                          Всем привет. Может кто-нибудь поделится информацией. Как собрать на Linux инсталяшки для трех платформ (Linux, Windows, MacOS).
                                                          Или это невозможно?
                                                            0
                                                            Для macOS никак. Но можно собирать в облаке. Например в CircleCI, благо, есть бесплатный тариф.

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое