Pull to refresh

Comments 25

NW.js не рассматривался? Вроде как дает меньший размер приложения на выходе.
У электрона есть свои преимущества, Как упомянул ниже, для меня это ES6(кстати, не понял, почему не работает в nw.js, если у него на данный момент хром посвежее. Включать нужно, что ли?), и более полноценная консоль(к примеру, то же сохранение css в nw.js не работает). Ну и electron-rebuild — удобная штука(не в курсе, есть ли аналоги у nw).

Что до размера — 123МБ у свежего nw.js, 120 — у электрона.
Рассказываю про ECMAScript 6 в NW.js: поддержка этой версии языка JavaScript будет в новой версии NW.js (в версии v0.13.0), выпуск которой ещё не состоялся, но ужé вот-вот состоится. А последняя стабильная версия (0.12.3) основана на движке IO.js v1.2.0 — это довольно старая версия нодовского движка, именно поэтому в ней всё плохо с ECMAScript 6.

Кто не хочет дожидаться выпуска новой версии, тот может поставить себе v0.13.0-rc1 на пробу (скачать по гиперссылке с Гитхаба или установить командою «npm install nw@0.13.0-rc1sdk» как npm-пакет). Сразу предупреждаю, что rc1 ещё не годится в продакшен из-за неустранённых багов (заголовок окна выглядит не лучшим образом, например).
Ну и конечно же еще никто не мешает добавить babel в проект :)
Основными плюсами Электрона для меня были ES6 и, самое главное, документация. Она у Electron ощутимо лучше
По поводу путей — в чем проблема использовать тот же __dirname? Да и насчет точки не понял, откуда такая информация? Кусок из html текущего проекта:

<script>window.$ = window.jQuery = require('./web/libs/jquery/dist/jquery.min.js');</script>

Возможно, такая проблема возникает только внутри скриптов, подключаемых через require или index.html лежит в корне, а не в какой-либо папке? По крайней мере, с такой проблемой не сталкивался.
Кстати, еще не помешало бы упомянуть, что как минимум jQuery сходу не заведется(если не ошибаюсь, связано с проверкой на окружение) и вышеупомянутая строчка как раз является фиксом.

По поводу взаимодействия main.js/index.html и передачи переменных напрямую не совсем верно. Точнее говоря, напрямую передать нельзя, а вот посредством ipc — пожалуйста.
https://github.com/atom/electron/blob/master/docs/api/ipc-main.md
https://github.com/atom/electron/issues/991
Кстати говоря, это же справедливо и для webview.

Еще бы не помешало упомянуть про то, что index.html не обязательно должен находиться на локальной машине. Довольно удобным способом является использование BrowserWindow в качестве обычного браузера, но с подключением скрипта с нодой с указанием через параметр preload и отключением контекста ноды для безопасности(ну или без отключения, если таковая не требуется).

Насчет глобального объекта — не уверен, сработает ли такой фокус. Разве если в main.js добавить свойство в тот же process, оно будет доступно в "клиентской" части? Если да — спасибо, пригодится.

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

Ну и главное — планируется ли написание других статей по электрону? Перешел на него с nw.js(приманило наличие ES6 из коробки и рабочее сохранение файлов из devtools), было бы интересно почитать статьи об особенностях использования.
Насчет глобального объекта — не уверен, сработает ли такой фокус. Разве если в main.js добавить свойство в тот же process, оно будет доступно в «клиентской» части? Если да — спасибо, пригодится.

На самом деле, и main.js и index.html выполняются node. Но, main.js и index.html для node — это разные модули. Совершенно справедливо, что переменные одного модуля не видны в других модулях. Иначе, подключив все нужные модули npm, мы бы получали кашу из переменных, и могли бы сломать работу, если переменные определены в разных модулях дважды.

Передавать переменные в index.html лучше через свойство global чем через свойство process. Так и логичнее, и доступ к переменной будет короче на длину "process.".

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

// module1.js
global.a = "hello";

// module2.js
console.log(a);  // => hello

// module3.js
var a = 0;
console.log(a);  // => 0
Еще добавлю, что backbone можно подключать через require(), но jQuery я бы подключал через тэг <script src=""></script>.

Кстати, разницы в поведении require() в main.js и index.html нет, если они находятся в одной папке.
По поводу jQuery выше отписывался — в electron из-за наличия module и window единовременно jQuery начинает колбасить. потому приходится изгаляться. Напрямую через скрипт просто так не подключишь.
Еще смешнее получается при использовании preload и включенной ноде. Как в таком случае поступать. так и не придумал. в итоге тупо выключил ноду для окна(благо. в скрипте из preload контекст ноды доступен в любом случае).

Про global для ноды в курсе. но не знал. что это справедливо и для BrowserWindow, спасибо.
Если не трудно, опишите в чем проявляется колбас jQuery? В последний раз (уже довольно давно) на nw делал десктопное приложение. Клиентского js, как такового, я не писал. Но был подключен jQuery и Bootstrap. И, вроде бы, все bootstrap-овское работало как часы без костылей.
Опытным путем я выяснил что нормально скриптово подключенная jQuery работает только версии 1.7.1. Даже последняя 1.12 (в первой ветке последняя) уже черт те что творит. Функции могут отказывать, могут не срабатывать совершенно не записывая ничего в лог, может попросту не инициализироваться, даже вручную.

Самое оптимальное — подключать модулем. Тем более что с точки зрения здравого смысла это гораздо логичнее, чем подключать ссылкой непосредственно к разметке.
jquery спокойно следует UMD, и подключать его можно как хотите. К тому же используя сборщики, подключать jquery в html дико :)
В nw.js такой проблемы нет, насколько мне известно.
В electron немножко другой принцип работы. Пример ошибки и решения можно посмотреть хотя бы и здесь — https://github.com/atom/electron/issues/254. Судя по описанию, проблема состоит в том, что jQuery более поздних версий может работать как в браузерном контексте, так и в CommonJS. Подстава в том, что в electron'е jQuery видит наличие module и пытается работать как в CommonJS, не объявляя переменной jQuery/$ в глобальной области видимости. Там же можно подсмотреть обычное предлагаемое решение — window.$ = window.jQuery = require('/path/to/jquery');.
Подстава еще в том, что если использовать не локальный файл, а подгружать скрипт preload'ом, то происходит какая-то хитрая балалайка: jQuery вываливается на функции assert с гениальным уведомлением о том, что document не объявлен. Пробовал фиксить сам jQuery и хитрыми шаманскими методами, но за пару часов так и не получилось ничего наковырять, а лезть дальше в кишки библиотеки с дебаггером было откровенно лень. Благо что в самом BrowserWindow мне контекст ноды был не нужен, а в preload'е не нужен был jQuery, так что просто отключил контекст ноды у окна.

Что до разницы версий(DarthGelum) — спасибо, надо будет проверить. Я так понимаю, эту проверку на module добавили в очередной версии jQuery, возможно, более старые версии будут работать адекватно.
Проблема являла себя вне зависимости от положения index.html.
jQuery 1.7.1 заводится абсолютно без проблем (не знаю почему именно эта версия, попробую вычислить причину при случае).
Фокус с глобальным объектом работает, но это убогое решение. Глобальные, тем более объекты, — зло.
Да, добавление свойств в process тоже работает, это стоит иметь в виду, я согласен.

Я бы хотел написать еще статей по Электрону. Честно говоря, я обнаружил много любопытных деталей. Постараюсь сделать это когда наберется достаточно материала и возможность соединить это в логичное повествование.
А кто-нибудь может подсказать, сколько требует минимально памяти Electron для удовлетворительной работы? Или может у кого-нибудь есть бенчмарки?
У меня электрон в относительно простом приложении зачем-то держит около 5 процессов суммарно метров на 100.
Какая ОС? 64бит?
У меня 64 бит Linux Mint, Электрон создает три процесса при отладке, и два в билде. Памяти суммарно около 60-80 мб.
В electron приложениях можно же использовать webpack или browserify для сборки "клиентского" кода, как раз, чтобы не переживать о том, как работает require.
Какой в среднем вес программы получается, около 120 МБ?
На разные ОС по разному.
Версия для Linux в распакованном виде 105.9Mb.
Чтобы уменьшить вес программы, можно собирать Electron вручную. Серьезного профита можно добиться выключив поддержку ES2015 в ключах сборки v8. Да и вообще, из v8 можно много чего выкинуть…
И если всё выкинуть, то сколько в результате вес получится?
Sign up to leave a comment.

Articles