
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>
Вот как работает этот код:
- Здесь создаётся текстовое поле с идентификатором
celcius
. Когда пользователь вводит в это поле некое значение, которое должно представлять собой температуру в градусах Цельсия, вызывается функцияcelciusToFahrenheit()
. - Текстовое поле с идентификатором
fahrenheit
, также создаваемое в этом коде, принимает данные от пользователя, которые должны представлять собой температуру в градусах Фаренгейта, после чего вызывается функцияfahrenheitToCelcius()
. - Функция
celciusToFahrenheit()
конвертирует температуру, выраженную в градусах Цельсия и введённую в полеcelcius
, в температуру в градусах Фаренгейта, после чего выводит то, что у неё получилось, в полеfahrenheit
. - Функция
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)
Listrigon
17.01.2019 16:45Могу сказать, что Электрон далеко не всегда и не для всех выход.
Но когда понадобилось переписать три версии приложения для трех разных систем, написанных на разных платформах в разное время и разными людьми, то я был рад, что существует Электрон. Плюс еще получилась готовая не плохая web-версия этого же приложения с той же кодовой базой, так что могу сказать, что я остался доволен.
elve
17.01.2019 19:29Electron это палочка-выручалочка, когда надо веб-страницу представить в виде приложения. Но не надо использовать его как платформу для разработки. Ну пожаааалуйста. Это слишком неэффективно по части вычислительных ресурсов. Сам я не пользуюсь тем, что обернуто в электрон — скайпа хватило с головой.
ikachinskiy
17.01.2019 19:33+1И чем плох «просто Java»? Также работает на всех трех. Более чем объёмные приложения не тормозят совсем. Пример — все присутствующие знают продукцию JetBrains
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 разве что ститический анализ чутка даёт. Но так как не особо он и полноценен, приходится в любом случа пользоваться иными инструментами.ikachinskiy
18.01.2019 11:59Resharper — не единственное изделие JetBrains. Возможно, в вашем случае проблема в совместной работе с Visual Studio, да ещё и на Windows. Я активно пользуюсь (причем одновременно) — PHPStorm, DataGrip, Golang. В фоне ещё висит вся среда исполнения проекта — длинный список, не буду утомлять. Ничего не тормозит — правда, вся работа исключительно на Ubuntu. Машина — i7 с 6-ю ядрами, 16Gb + 1 Tb SSD. Microsoft принципиально отсутствует как класс — внутреннее правило казённой академической конторы.
AxisPod
18.01.2019 12:07Ну это домашний пример, домашний проект в виде хобби. При этом памяти 32Гб, но всё тормозит жутко, забил в итоге на Resharper C++.
На работе же WebStorm, плюс инструменты необходимые в работе, 8Гб, уже в притык. Есть ещё машина, где уже используется VS Code, и сопутствующее, вот там 8Гб уже не хватает в принципе. Так что да, WebStorm оптимальнее.
Но я ещё помню переход кодовой базы Visual Studio c С++ на .NET и помню повышение потребление оперативки с порядка 200Мб до 900Мб на нашем проекте. Это более показательно, разработчики ПО забивают на потребление памяти, они хотят экономить время скидывая это на потребителей.ikachinskiy
18.01.2019 12:32В вашем комментарии косвенно видна основная тема текущего обсуждения — все рассматриваемые инструменты задумывались, как кросс-платформенные. Т.е. по умолчанию в них ОБЯЗАТЕЛЬНО тянется за изделием универсальная среда исполнения — виртуальная машина в том или ином виде. Движок Chromium здесь также можно рассматривать как специфическую виртуальную машину. Так что обсуждаем, по факту, сравнительную эффективность однотипных в общем то решений. Сравнивать их с продуктами, у которых принципиально другая основа (Visual Studio на базе C++) — методически неверно. Они ВСЕГДА будут принципиально экономичней и быстрее. Вот родит кто-нибудь IDE на Go или Rust — тогда их можно будет сравнить с VS на С++. А так получается «мягкое с круглым»
AxisPod
18.01.2019 12:47Visual Studio на базе C++ и .NET приведены просто для примера, как нечто, где есть явное сравнение. И я указал лишь для указания того, что разработчики скидывают затраты на разработку на потребителей.
Electron по определению использует webkit и никуда от него не деться и он кроссплатформенный, при этом инструменты на Java тоже кроссплатформенны и тут я соглашусь оригинальным сообщением, что всё же решения на Java меньше жрут ресурсов, чем Electron. Но тенденция показанная на базе Visual Studio наблюдается и в использовании Java.ikachinskiy
18.01.2019 13:09Это да — в соревновании «виртуальных машин» Java, .NET и webkit — последний явно аутсайдер. И его использование оправдано только в том случае, если разработчик просто ничего, кроме JavaScript не знает. Считаем комплексные расходы на разработку, использование и поддержание продукта — сюда входит и стоимость времени разработчика, и стоимость эксплуатации готового продукта, и его поддержка автором. По интегральному параметру стоимости продукт на Electron становится оправданным только в том случае, если провальные расходы на эксплуатацию компенсируются экономией на разработке и поддержке.
AxisPod
18.01.2019 13:19Не думаю, что расходы на эксплуатацию учитывают, особенно если это не внутренний продукт.
Да и выбирают сейчас JS всё же из-за порога вхождения. К примеру WPF инструмент конечно мощный, но чтобы там сделать что-то большее чем просто конвертор температуры, нужно знатно поучиться.
Соответственно выбор в компаниях, где хотят продукт, но не хотят затрат выбор очевиден. Скайп очень показателен. Они ведь не выбрали WPF, хотя имеют в штате разработчиков знающих WPF на 5 порядочно, да и имеют средства на это.ikachinskiy
18.01.2019 13:29В случае Скайпа Микрософт опять попытался просто грубо нажиться на купленной у третьей компании клиентской базе — надо же затраты на покупку отбивать. Поэтому посадили на «новый» Скайп дешёвых стажеров, которые умеют делать хоть что-то только на JS (тот самый «низкий порог вхождения»). Загрузить этой работой дорогих спецов по .NET — жаба задушила. Ну это вполне в стиле корпоративной политики этой компании — принцип «любая деятельность, приносящая прибыль — является основной» гипертрофирован до состояния маразма.
Free_ze
18.01.2019 13:12Visual Studio на базе C++
Это могло быть сказано про v6. Сейчас GUI там активно переносится на .NET
denis-isaev
18.01.2019 14:35У них там какой-то косяк в последних релизах, который проявляется в том, что начинается какой-то бесконечный парсинг от которого все тормозит. Причем не завист от размера проекта, у меня был небольшой проект в котором сие начиналось после открытия одного конкретного небольшого файла. Закрытие файла и проекта не помогало. В phpstorm проявлялось. И в интернетах гуляют аналогичные жалобы. Так что это вероятнее всего какой-то отдельный баг, который (недеюсь) пофиксят.
Buzzzzer
18.01.2019 00:52-1Помню, как на Delphi меня огорчал размер exeшника. Я даже "огромный" VCL на KOL переписал, знатно покрасноглазив, чем уменьшил размер с 1.5 мбайт до 60 кбайт. А потом еще upx'ом сжимал даже вроде.
Эх, где то мы свернули не туда...
PaulZi
18.01.2019 10:10Давайте вместе поможем Даше найти электрон приложения!
Большая картинкаFree_ze
18.01.2019 12:57Там что-то «электронное», кроме скупе запущено? (Telegram — C++/Qt(Widgets), VirtualBox — Java, Nodepad++ — C++) FF разве что с GUI на веб-технологиях, хоть и не электрон, но его результаты ожидаемы.
PaulZi
18.01.2019 13:00Хм. Телеграм жрёт как электрон, был уверен что на нём. А так по задумке Skype и Telegram, и это ещё Slack не запущен…
AxisPod
18.01.2019 11:31Вот «почему-то» хочется найти всех разработчиков использующих Electron и оторвать всё что оторвётся. Помню те времена, когда 4Гб хватало, а тут пару приложений запустил и 8Гб уже не хватает.
servermen
18.01.2019 17:14ru_vds Спасибо за перевод! Возможно он облегчит моё понимание. Но сходу возникли два вопроса: Возможно ли при помощи Electron Forge запустить и собрать любое electron-приложение, найденное на просторах github.com? И как тогда быть с требованиями документации по сборке в Windows? Там требуется python 2.7.
kaleman
Не пишите декстопный софт на JS! Не надо издеваться над пользователями. Вспомните адский шит под названием Скайп написанный на Электроне.
Perlovich
Основные проблемы скайпа (нестабильность, баги, путешествия сообщений «во времени» и т.д.) вызваны совсем не использованием электрона.
Jouretz
150 мегабайт отжираемой памяти для звонилки висящей в фоне, кастрирование настроек и тормоза при запуске тоже не от электрона?
Минимальные требования и объём любой шняги на этом чудо-движке будут >= требованиям nodejs. Не надо мне на компьютер ради софтины конвертирующей температуру тащить ещё одну обособленную версию хромиума.
Для сравнения плагин на pidgin, например, реализующий обмен по протоколу скайпа весит ~1mb, и сам pidgin весит ещё 4. Но проблема, конечно, не в электроне.
kaleman
150 мегабайт это конечно треш… Как мы дошли до жизни такой? Ту же софтину конвертирующую температуру можно собрать на нативном языке. Она будет весить 20 килобайт максимум, работать мгновенно и на всех существующих версиях Windows.
Zenitchik
Кстати, посоветуйте, на чём и в какой IDE в наше время пишут под Window?
А то порой бывает нужно написать какую-нибудь мелочь (типа того же конвертера температур) для собственного пользования, а я со времён VB98 на нативных языках не писал.
Groramar
Я пишу на Delphi/Lazarus, быстро и просто. От мелочи, до милионно-строчных проектов.
0xf0a00
Delphi (хотя сейчас понабегут хоронители с лопатами)
unhappy
совсем простые штуки пишу на html+js -> .hta
если хочется именно IDE, то приятный минималистический вариант — PureBasic. Free version имеет ограничения: максимум 800 строк кода, нельзя использовать API, нельзя создавать DLL.
Компилирует код в standalone приложения небольшого размера (простая форма с несколькими контролами ~50KB).
Zenitchik
Там же вроде какой-то доисторический trident в качестве движка?
Whuthering
Visual Studio как среда, C# как язык, WinForms как GUI-библиотека (особенно если есть опыт со старым VB, WPF все-таки немного взрывает мозг для неподготовленного) — очень приятная и довольно простая для первых шагов связка.
В той же студии, кстати, и VB.net есть, правда, не знаю ни одного человека, который бы на нем писал)
Zenitchik
Я немножко пробовал, но честно говоря, по прошествии лет, предпочитаю языки с фигурными скобочками. Чисто зрительно удобнее.
AxisPod
Visual Studio Community Edition, правда на работе всё равно поставить будет нельзя. Если же использовать .net core, можно в том же VS Code. Можно в блокноте, правда с отладкой в этом случае будет не очень.
F0iL
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
Barafu_Albino_Cheetah
Что-то вам какой-то суровой жести насоветовали. Visual Studio конечно хорошо, но в нём ещё разобраться надо, а результат (как программа, так и ваше обучение) будет намертво привязан к винде.
Попробуйте Qt. В комплекте идёт простая, но вполне достаточная IDE QtCreator. А главное, один раз выучив, можно писать под все платформы практически идентично, включая Андроид. А ещё, если надоест C++, можно перейти на Python: API практически совпадает тоже. С той разницей, что Qt для C++ объявляет примитивы, которые в Python уже есть, а Qt для Python их больше не велосипедит.
Можете сразу с Python начать. PyCharm отличная бесплатная IDE. Да и на VSCode и других про-блокнотах питонить не сложно. На Python можно генерить обособленные EXE-шники. Но они будут тоже страдать лишним весом в 6Мб на среду и интерпретатор.
Groramar
Delphi/Lazarus. Скорее всего свою первую (неконсольную) программу Hello world вы сможете написать минут за 10 :) 9 — просмотр подходящего видео, 1 — остальное.
Delphi Community Edition — отличная бесплатная полнофункциональная среда (ограничение — зарабатываемые на ней деньги, до $5000 в год), блокнотить не нужно :)
Лазарус — бесплатный полностью. Качество постепенно приближается к Delphi и местами превосходит. Сама среда запускается почти на чем угодно, вплоть до утюгов :) Win, Linux, Mac, Raspbery и так далее. Ну и, само собой, собирает под это всё.
Barafu_Albino_Cheetah
А как оно сделает GUI на Linux? На каком тулките?
Groramar
В Лазарусе это LCL — кросс-плафторменная библиотека. Можно собрать с одним кодом и одними формами под все платформы и отлаживать по месту прямо, удобно. У нас несколько программ в продакшне, уже продаём, на Линукс в том числе.
shure348
все версии windows любят не только лишь все
более того многие не любят никакую версию windows
Zenitchik
Но, согласитесь, это не повод в каждое приложение класть 50 метров обвязки.
Вот если бы можно было движок установить раз и навсегда, а не запаковывать внутрь каждого приложения — было бы замечательно.
Jouretz
.Net, Java и т.д.
Просто взрывной рост веба породил кучу лишних js-программистов. Которые теперь пытаются найти себя в десктопной разработке.
Zenitchik
Ерунда. Нет никаких лишних js-программистов — их как раз не хватает. Много лишних js-обезьян, которые даже в прототип не врубились.
Jouretz
Ну дык, обезьяны-то по итогу рекламятся как «профессиональные разработчики со стажем».
Js позволяет прокатившись лицом по клавиатуре получить кое-как, но работающий код, потому обезьяны массово туда и валят.
Zenitchik
Угу… И, честно говоря, я опасаюсь, что по мере появления в JS «всего того что есть в „нормальных языках“ », обезьян среди нас, javascript'еров, станет в процентном отношении больше: им же даже спеку не придётся читать.
Groramar
Тот же Delphi уже давно кросс-платформенная. Да и Жава, Дотнет (частично) только что не натив.
Alexey2005
Сломали монополию MS, вот и дошли. Все девяностые об этом мечтали, и даже первую половину нулевых, ну вот и получили. Имеем дичайшую фрагментацию, и полную неготовность средств разработки к этой фрагментации.
В стандартных библиотеках современных кроссплатформенных ЯП до сих пор нет инструментов построения UI, а единственный более-менее работающий кроссплатформеный фреймворк — это Qt, который сам жрёт как пол-Электрона, разве что работает пошустрее. И то для его подключения и интеграции нужно очень уж много лишних телодвижений проделать.
Именно проблему фрагментации и решает Electron. Это среда, которая просто берёт и просто работает. Где вы можете сразу начинать писать кроссплатформенный код без необходимости предварительной установки Kubernetes и всяких виртуалок-контейнеров, чтоб просто собрать ваше приложение под десяток различных платформ.
Где все проблемы с железом и различными операционками берёт на себя разработчик самого фреймворка. И вы можете сосредоточиться на решении именно своей задачи, а не на способах заставить приложение запускаться на очередном экзотическом дистрибутиве Linux.
denis-isaev
К сожалению, это только в теории. На практике билдить приходится в виртуалбоксах потому что «нативные» зависимости вроде sqlite, sharp и т.п. нельзя билдить иначе. Может понадобиться для некоторых платформ руками перекладывать потом dll-ки в node_modules из-за того что билдер их положил не туда. Добавлять под каждую ось всякие хаки, чтобы иконки отображались в таскбарах правильные, диалоговые окна работали и т.п.
kaleman
Клиент на электроне ужасно тормозил и был дико неудобен из-за кривизны интерфейса.
Я конечно понимаю, что веб-разработчики хотят запихнуть весь софт в браузер, но существуют разумные ограничения. Для десктопного софта существуют соответствующие среды разработки и инструменты.
Groramar
Современный Скайп ужасен во всех своих проявлениях. Юзаю на Windows и Андроид. На Андроиде постоянно всё вымораживается. На Винде просто гора разнообразных глюков. От полной неотрисовки окон и частей (смайлов и т.д) до слетевшего логина, и так постоянные тормоза. Пока был на Delphi, был на порядок приятнее и стабильнее. Но тут пришел хайп :(
brick_btv
На андроид какой-то садом с настройкой звука вызова в skype. Раньше подстраивался под громкость мультимедиа, потом начал подстраиваться под громкость звонка. Последний раз использовалась "громкость при разговоре", заорало при полностью выключенном в телефоне звуке. Удалил без сожалений.
developeAR
Вспомните шикарную Visual Studio Code и не менее прекрасный Atom. А глючный софт можно на любом языке написать
0xf0a00
я так же шикарно чувствую тормоза при их использовании
Vlad_IT
Мне сложно в это поверить. У меня VS Code с кучей расширений, более плавно работает, чем тот же sublime (без расширений). Памяти конечно больше кушает, но по скорости довольно шустро.
pesh1983
А мне трудно поверить, что хорошо написанный софт на плюсах работает медленнее, чем хорошо написанный софт на js, работающий в виртуальной машине, да ещё и с плагинами)
kpakozz96pyc
Не вижу ничего прекрасного в простом текстовом редакторе, который на маленьком проекте может сожрать до 2гб оперативки, а по Find defenition переходить секунд 10. Позиционировался вроде как быстрый и легкий аналог VS, а в результате тупит еще страшнее.
Тот же сублайм на аналогичном проекте занимает 400мб памяти и не тормозит абсолютно.
boblenin
> а в результате тупит еще страшнее.
при этом может гораздо меньше.
AxisPod
Ну не у всех на рабочих компах стоит по 16Гб и больше, не надо тут говорить. На мелком проекте постоянно выжрано 2Гб+ и проц нагружен по самое нехочу, шпарит просто без остановки. Помимо VS Code надо открыть браузер, который тоже жрёт 2Гб+, надо открыть мессенджеров несколько, надо запустить webpack dev server, который жрёт 1Гб минимум. А ещё на работе стоит антивирусник, который тоже жрёт ресурся порядочно. И у меня на 8Гб постоянно всё в глубоком свапе живёт.
vadimm0s
Откуда такая уверенность в том, что в Скайпе используется именно электрон? Вообще похоже что скайп крутится в Эдже. Ошибки, что в скайпе что в эдже одинаковые и происходят при подобных обстоятельствах.
Jouretz
electronjs.org/apps/skype
А Edge по вашему нынче что? Ещё одна обёртка для хромиума blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration
Один движок — одни баги.
CuteDog
если дискорд и скайп — это примеры хороших проектов, то просто огонь. использовать чисто вебовские технологии для написания десктоп приложений — это пять! можно конечно и наждачной бумагой подтираться, но обычно люди берут мягкую.
psFitz
Вспомните очень популярный и очень пиаренный на том же хабре редактор visual studio code, он написан на Electron, так что не надо.
Alhymik
А кто-нибудь пробовал Sciter?