Можно ли, используя 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 для разработки настольных приложений?

Комментарии (60)


  1. kaleman
    17.01.2019 13:56
    -1

    Не пишите декстопный софт на JS! Не надо издеваться над пользователями. Вспомните адский шит под названием Скайп написанный на Электроне.


    1. Perlovich
      17.01.2019 14:12
      +2

      Основные проблемы скайпа (нестабильность, баги, путешествия сообщений «во времени» и т.д.) вызваны совсем не использованием электрона.


      1. Jouretz
        17.01.2019 14:21

        150 мегабайт отжираемой памяти для звонилки висящей в фоне, кастрирование настроек и тормоза при запуске тоже не от электрона?
        Минимальные требования и объём любой шняги на этом чудо-движке будут >= требованиям nodejs. Не надо мне на компьютер ради софтины конвертирующей температуру тащить ещё одну обособленную версию хромиума.

        Для сравнения плагин на pidgin, например, реализующий обмен по протоколу скайпа весит ~1mb, и сам pidgin весит ещё 4. Но проблема, конечно, не в электроне.


        1. kaleman
          17.01.2019 14:48

          150 мегабайт это конечно треш… Как мы дошли до жизни такой? Ту же софтину конвертирующую температуру можно собрать на нативном языке. Она будет весить 20 килобайт максимум, работать мгновенно и на всех существующих версиях Windows.


          1. Zenitchik
            17.01.2019 15:28
            +2

            Кстати, посоветуйте, на чём и в какой IDE в наше время пишут под Window?
            А то порой бывает нужно написать какую-нибудь мелочь (типа того же конвертера температур) для собственного пользования, а я со времён VB98 на нативных языках не писал.


            1. Groramar
              17.01.2019 15:46
              +1

              Я пишу на Delphi/Lazarus, быстро и просто. От мелочи, до милионно-строчных проектов.


            1. 0xf0a00
              17.01.2019 16:13
              +1

              Delphi (хотя сейчас понабегут хоронители с лопатами)


            1. unhappy
              17.01.2019 16:46

              совсем простые штуки пишу на html+js -> .hta
              если хочется именно IDE, то приятный минималистический вариант — PureBasic. Free version имеет ограничения: максимум 800 строк кода, нельзя использовать API, нельзя создавать DLL.
              Компилирует код в standalone приложения небольшого размера (простая форма с несколькими контролами ~50KB).


              1. Zenitchik
                17.01.2019 17:22

                hta

                Там же вроде какой-то доисторический trident в качестве движка?


            1. Whuthering
              18.01.2019 12:50
              +1

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

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


              1. Zenitchik
                18.01.2019 15:35

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

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


            1. AxisPod
              18.01.2019 12:53

              Visual Studio Community Edition, правда на работе всё равно поставить будет нельзя. Если же использовать .net core, можно в том же VS Code. Можно в блокноте, правда с отладкой в этом случае будет не очень.


              1. F0iL
                18.01.2019 13:22

                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


            1. Barafu_Albino_Cheetah
              18.01.2019 18:58

              Что-то вам какой-то суровой жести насоветовали. Visual Studio конечно хорошо, но в нём ещё разобраться надо, а результат (как программа, так и ваше обучение) будет намертво привязан к винде.
              Попробуйте Qt. В комплекте идёт простая, но вполне достаточная IDE QtCreator. А главное, один раз выучив, можно писать под все платформы практически идентично, включая Андроид. А ещё, если надоест C++, можно перейти на Python: API практически совпадает тоже. С той разницей, что Qt для C++ объявляет примитивы, которые в Python уже есть, а Qt для Python их больше не велосипедит.
              Можете сразу с Python начать. PyCharm отличная бесплатная IDE. Да и на VSCode и других про-блокнотах питонить не сложно. На Python можно генерить обособленные EXE-шники. Но они будут тоже страдать лишним весом в 6Мб на среду и интерпретатор.


              1. Groramar
                18.01.2019 21:01
                -1

                Но они будут тоже страдать лишним весом в 6Мб на среду и интерпретатор.
                Ну и с гуём в Питоне не очень. В том смысле, что консоль онли. Только если внешнее что-то подключать. Ну и скорость, как у любых скриптов, на троечку, если не на двоечку. Так что местами там тоже суровая жесть :)
                Delphi/Lazarus. Скорее всего свою первую (неконсольную) программу Hello world вы сможете написать минут за 10 :) 9 — просмотр подходящего видео, 1 — остальное.
                Delphi Community Edition — отличная бесплатная полнофункциональная среда (ограничение — зарабатываемые на ней деньги, до $5000 в год), блокнотить не нужно :)
                Лазарус — бесплатный полностью. Качество постепенно приближается к Delphi и местами превосходит. Сама среда запускается почти на чем угодно, вплоть до утюгов :) Win, Linux, Mac, Raspbery и так далее. Ну и, само собой, собирает под это всё.


                1. Barafu_Albino_Cheetah
                  19.01.2019 03:15

                  А как оно сделает GUI на Linux? На каком тулките?


                  1. Groramar
                    19.01.2019 10:17

                    В Лазарусе это LCL — кросс-плафторменная библиотека. Можно собрать с одним кодом и одними формами под все платформы и отлаживать по месту прямо, удобно. У нас несколько программ в продакшне, уже продаём, на Линукс в том числе.


          1. shure348
            17.01.2019 19:33
            +1

            все версии windows любят не только лишь все
            более того многие не любят никакую версию windows


            1. Zenitchik
              17.01.2019 20:14
              +1

              Но, согласитесь, это не повод в каждое приложение класть 50 метров обвязки.
              Вот если бы можно было движок установить раз и навсегда, а не запаковывать внутрь каждого приложения — было бы замечательно.


              1. Jouretz
                17.01.2019 20:16

                .Net, Java и т.д.
                Просто взрывной рост веба породил кучу лишних js-программистов. Которые теперь пытаются найти себя в десктопной разработке.


                1. Zenitchik
                  18.01.2019 15:38

                  Ерунда. Нет никаких лишних js-программистов — их как раз не хватает. Много лишних js-обезьян, которые даже в прототип не врубились.


                  1. Jouretz
                    18.01.2019 15:43

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


                    1. Zenitchik
                      18.01.2019 15:52

                      Угу… И, честно говоря, я опасаюсь, что по мере появления в JS «всего того что есть в „нормальных языках“ », обезьян среди нас, javascript'еров, станет в процентном отношении больше: им же даже спеку не придётся читать.


            1. Groramar
              17.01.2019 20:42

              Тот же Delphi уже давно кросс-платформенная. Да и Жава, Дотнет (частично) только что не натив.


          1. Alexey2005
            17.01.2019 20:45
            +4

            Сломали монополию MS, вот и дошли. Все девяностые об этом мечтали, и даже первую половину нулевых, ну вот и получили. Имеем дичайшую фрагментацию, и полную неготовность средств разработки к этой фрагментации.
            В стандартных библиотеках современных кроссплатформенных ЯП до сих пор нет инструментов построения UI, а единственный более-менее работающий кроссплатформеный фреймворк — это Qt, который сам жрёт как пол-Электрона, разве что работает пошустрее. И то для его подключения и интеграции нужно очень уж много лишних телодвижений проделать.
            Именно проблему фрагментации и решает Electron. Это среда, которая просто берёт и просто работает. Где вы можете сразу начинать писать кроссплатформенный код без необходимости предварительной установки Kubernetes и всяких виртуалок-контейнеров, чтоб просто собрать ваше приложение под десяток различных платформ.
            Где все проблемы с железом и различными операционками берёт на себя разработчик самого фреймворка. И вы можете сосредоточиться на решении именно своей задачи, а не на способах заставить приложение запускаться на очередном экзотическом дистрибутиве Linux.


            1. denis-isaev
              18.01.2019 14:28

              К сожалению, это только в теории. На практике билдить приходится в виртуалбоксах потому что «нативные» зависимости вроде sqlite, sharp и т.п. нельзя билдить иначе. Может понадобиться для некоторых платформ руками перекладывать потом dll-ки в node_modules из-за того что билдер их положил не туда. Добавлять под каждую ось всякие хаки, чтобы иконки отображались в таскбарах правильные, диалоговые окна работали и т.п.


      1. kaleman
        17.01.2019 14:23

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


    1. Groramar
      17.01.2019 14:22
      +1

      Современный Скайп ужасен во всех своих проявлениях. Юзаю на Windows и Андроид. На Андроиде постоянно всё вымораживается. На Винде просто гора разнообразных глюков. От полной неотрисовки окон и частей (смайлов и т.д) до слетевшего логина, и так постоянные тормоза. Пока был на Delphi, был на порядок приятнее и стабильнее. Но тут пришел хайп :(


      1. brick_btv
        17.01.2019 20:05

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


    1. developeAR
      17.01.2019 15:07

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


      1. 0xf0a00
        17.01.2019 16:13
        +2

        я так же шикарно чувствую тормоза при их использовании


        1. Vlad_IT
          17.01.2019 17:28

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


          1. pesh1983
            19.01.2019 22:14

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


      1. kpakozz96pyc
        17.01.2019 17:23

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


        1. boblenin
          17.01.2019 22:02
          +1

          > а в результате тупит еще страшнее.

          при этом может гораздо меньше.


      1. AxisPod
        18.01.2019 11:37

        Ну не у всех на рабочих компах стоит по 16Гб и больше, не надо тут говорить. На мелком проекте постоянно выжрано 2Гб+ и проц нагружен по самое нехочу, шпарит просто без остановки. Помимо VS Code надо открыть браузер, который тоже жрёт 2Гб+, надо открыть мессенджеров несколько, надо запустить webpack dev server, который жрёт 1Гб минимум. А ещё на работе стоит антивирусник, который тоже жрёт ресурся порядочно. И у меня на 8Гб постоянно всё в глубоком свапе живёт.


    1. vadimm0s
      18.01.2019 14:04

      Откуда такая уверенность в том, что в Скайпе используется именно электрон? Вообще похоже что скайп крутится в Эдже. Ошибки, что в скайпе что в эдже одинаковые и происходят при подобных обстоятельствах.


      1. Jouretz
        18.01.2019 14:33

        electronjs.org/apps/skype
        А Edge по вашему нынче что? Ещё одна обёртка для хромиума blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration
        Один движок — одни баги.


    1. CuteDog
      18.01.2019 14:04

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


    1. psFitz
      18.01.2019 14:34

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


    1. Alhymik
      18.01.2019 16:36

      А кто-нибудь пробовал Sciter?


  1. Listrigon
    17.01.2019 16:45

    Могу сказать, что Электрон далеко не всегда и не для всех выход.
    Но когда понадобилось переписать три версии приложения для трех разных систем, написанных на разных платформах в разное время и разными людьми, то я был рад, что существует Электрон. Плюс еще получилась готовая не плохая web-версия этого же приложения с той же кодовой базой, так что могу сказать, что я остался доволен.


  1. elve
    17.01.2019 19:29

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


  1. ikachinskiy
    17.01.2019 19:33
    +1

    И чем плох «просто Java»? Также работает на всех трех. Более чем объёмные приложения не тормозят совсем. Пример — все присутствующие знают продукцию JetBrains


    1. AxisPod
      18.01.2019 11:48

      Точно, попробуйте Visual Studio + Resharper C++ + Unreal Engine. Вот повеселитесь. Парсит исходы более получаса, почти любое действие в визуалке открывает модальный диалог с инфой о парсинге. После парсинга каждые 1-2 секунды подвисание на 2-3 секунды. Отличная работа JetBrains. На примере WebStorm, открыл пару довольно больших текстовых файла, начались лютые тормоза, проц выжран очень знатно, закрыл, а ничего не изменилось, спасает только перезапуск среды. Только не надо тут про то, что Java не умеет работать с большим объёмом текста, я как пользователь об этом знать не должен.

      P.S. Если заменить Resharper C++ на Visual Assist (чем всегда и пользовался), то проблемы пропадают, парсит за пару минут, тормозов нет, функционала в основном больше. Resharper разве что ститический анализ чутка даёт. Но так как не особо он и полноценен, приходится в любом случа пользоваться иными инструментами.


      1. ikachinskiy
        18.01.2019 11:59

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


        1. AxisPod
          18.01.2019 12:07

          Ну это домашний пример, домашний проект в виде хобби. При этом памяти 32Гб, но всё тормозит жутко, забил в итоге на Resharper C++.

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

          Но я ещё помню переход кодовой базы Visual Studio c С++ на .NET и помню повышение потребление оперативки с порядка 200Мб до 900Мб на нашем проекте. Это более показательно, разработчики ПО забивают на потребление памяти, они хотят экономить время скидывая это на потребителей.


          1. ikachinskiy
            18.01.2019 12:32

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


            1. AxisPod
              18.01.2019 12:47

              Visual Studio на базе C++ и .NET приведены просто для примера, как нечто, где есть явное сравнение. И я указал лишь для указания того, что разработчики скидывают затраты на разработку на потребителей.

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


              1. ikachinskiy
                18.01.2019 13:09

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


                1. AxisPod
                  18.01.2019 13:19

                  Не думаю, что расходы на эксплуатацию учитывают, особенно если это не внутренний продукт.

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

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


                  1. ikachinskiy
                    18.01.2019 13:29

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


            1. Free_ze
              18.01.2019 13:12

              Visual Studio на базе C++

              Это могло быть сказано про v6. Сейчас GUI там активно переносится на .NET


      1. denis-isaev
        18.01.2019 14:35

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


  1. Buzzzzer
    18.01.2019 00:52
    -1

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


  1. PaulZi
    18.01.2019 10:10

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


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


    1. Free_ze
      18.01.2019 12:57

      Там что-то «электронное», кроме скупе запущено? (Telegram — C++/Qt(Widgets), VirtualBox — Java, Nodepad++ — C++) FF разве что с GUI на веб-технологиях, хоть и не электрон, но его результаты ожидаемы.


      1. PaulZi
        18.01.2019 13:00

        Хм. Телеграм жрёт как электрон, был уверен что на нём. А так по задумке Skype и Telegram, и это ещё Slack не запущен…


  1. AxisPod
    18.01.2019 11:31

    Вот «почему-то» хочется найти всех разработчиков использующих Electron и оторвать всё что оторвётся. Помню те времена, когда 4Гб хватало, а тут пару приложений запустил и 8Гб уже не хватает.


  1. servermen
    18.01.2019 17:14

    ru_vds Спасибо за перевод! Возможно он облегчит моё понимание. Но сходу возникли два вопроса: Возможно ли при помощи Electron Forge запустить и собрать любое electron-приложение, найденное на просторах github.com? И как тогда быть с требованиями документации по сборке в Windows? Там требуется python 2.7.