Если вы хотите создать собственное десктопное приложение на основе веб-технологий, то мир опенсорса предлагает два основных варианта: NW.js (ранее известный как node-webkit) и Electron (atom-shell). Выбор между ними не так очевиден, поэтому я решил создать сравнительную таблицу и остановиться на самых важных отличиях.
И NW.js и Electron предоставляют платформу для разработки десктопных приложений с HTML в качестве представления и NodeJS для доступа к системному API (для работы с жестким диском, железом и т.д.). Но существуют принципиальные различия между двумя проектами.
Парадигма
В NW.js точкой входа в приложение является веб-страница. Вы указываете URL основной страницы в package.json и она открывается как главное окно приложения. В Electron точка входа — это программа на NodeJS. Вместо указания URL-адреса напрямую вы «вручную» создаете окно и загружаете в него HTML-файл с помощью API.
Это чрезмерное упрощение, но можно сказать, что парадигма NW.js более браузера-ориентированная. NW.js загружает указанную HTML-страницу и эта страница получает доступ к контексту Node.js. Если открыто больше одного окна, то все они получают доступ к этому общему Node.js контексту. Это означает, что вы можете получить прозрачный доступ к DOM всех открытых окон.
Electron, с другой стороны, имеет более NodeJS-ориентированный подход. Он запускает среду выполнения Node.js, которая получает возможность открывать окна, в которые вы можете затем загружать веб-страницы. Это означает, что связать несколько окон с основным процессом намного сложнее.
Победитель: зависит от ваших потребностей.
Защита исходного кода
В Electron нет какого-либо механизма для защиты вашего исходного кода. Asar трудно назвать приемлемой защитой, учитывая что это простой tar-архив и фактически любой пользователь может «распаковать» вашу программу как обычный архив и получить доступ ко всем ресурсам и исходному коду.
NW.js позволяет собрать исполняемый файл с защитой через V8 Snapshot. Данное решение конечно не компилирует JavaScript в машинный код (как утверждает документация) и не обеспечивает полную безопасность исходного кода. По сути это просто очень хорошо обфусцированный код. Но если единственная альтернатива — оставить исходный код совершенно открытым, то многие разработчики предпочтут V8 Snapshot, даже учитывая потерю примерно 30% производительности.
Победитель: NW.js
Время запуска
Я не пытался специально замерять время запуска приложения, но по личным ощущениям приложение на Electron запускается заметно быстрее как на Windows, так и на OSX. Даже если отключить V8 Snapshot, NW.js-приложение загружается гораздо медленнее.
Победитель: Electron
Open Source
В свое время Electron сделал смелый шаг, поддержав IO.js в момент застоя разработки Node.js. Это означает, что Electron в большой степени стремится поддерживать передовые возможности JavaScript, в то время как NW.js больше ориентируется на поддержку обратной совместимости (по крайней мере в теории).
Также нельзя не заметить высокую скорость разработки Electron. Больше сотни коммитов в неделю, по десять релизов в месяц. Команда разработчиков активно отвечает на вопросы на github. С другой стороны, NW.js все еще находится в версии 0.15, а github-документация кажется довольно устаревшей. Например, регулярно можно увидеть упоминания названия «node-webkit», хотя проект был переименован несколько лет назад.
Победитель: Electron
Послужной список
Несмотря на то, что NW.js существует дольше Electron'а, насколько я могу судить, на Electron разработано гораздо больше популярных приложений. Из данного списка NW.js, кроме Popcorn Time и Koala, трудно выделить что-либо значительное. С другой стороны список Electron смотрится гораздо солиднее:
— Atom
— Slack
— Visual Studio Code
— Cocos Creator
— Pixate Pixate
Победитель: Electron
Вывод
По большему счету, единственное существенное различие между двумя проектами сводится к одному признаку — способности (или отсутствию таковой) «обезопасить» ваш исходный код. На мой взгляд, это единственная причина, почему разработчик может выбрать NW.js. Хотя данный вывод, вероятно, страдает от моей собственной предвзятости, т.к. я использовал Electron гораздо активнее, чем NW.js. Поэтому в комментариях просьба рассказать про ваш опыт работы с этими двумя библиотеками.
См. также
NW.js & Electron Compared
Technical Differences Between Electron and NW.js
Комментарии (32)
vlreshet
01.07.2016 17:22Могу ошибаться, но вроде как последняя версия electron поддерживает все плюшки es6, а nw.js — нет
lsknwns
01.07.2016 18:49+8Ну, нет.
>В NW.js точкой входа в приложение является веб-страница.
В nw.js точкой входа может быть js-файл, внимательне читаем документация docs.nwjs.io/en/latest/References/Manifest%20Format/#main
А еще, есть bg-script (chrome api like) и node-main скрипт, который запускается в контексте ноды, до запуска браузера.
Не описано основное различие платформ, которое в суть и должно влиять на выбор.
Electron построен вокруг CEF (chromium embedded framework), в то время как nw.js вокруг полноценного Chromium
Отсюда тянуться все сущетсвенные отличия. Например, nw.js полностью поддерживает chrome app\extension api, а Electron нет.
Так же элемент webview (который является рендером в песочнице) полностью реализуется через chrome api, в отличии от Electron.
А еще в nw.js есть поддержка NaCL, которую Electron даже не планирует включать github.com/electron/electron/issues/835.
Говоря о webview, в nwjs есть возможность сделать песочницу из обычного iframe, который рендерится в том же процессе, а не в отдельном. В Electron этого сделать нельзя. (зато в electron есть возможность прокинуть котекст ноды в webview, но в nw.js это тоже обещали реализовать github.com/nwjs/nw.js/issues/4780)
Все эти различия с интеграцией контекстов, созданием песочниц и распараллеливанием рендер-процессов, могут быть весомы при выборе платформы.
Еще, есть такой нюанс, как две сборки nw.js — с интегрированными DevTools и без них.
amphasis
10.11.2016 16:11Не могу ничего сказать о «замедлении времени». Но вывод о том, что «фотон не имеет ни прошлого, ни будущего» делается из общей теории относительности. Грубо говоря, поскольку фотон перемещается со скоростью света, в его системе отсчета время не идет, соответственно в своей системе отсчета он излучается, проходит весь свой путь и поглощается одновременно, в один момент времени.
adombrovsky
01.07.2016 19:13В свое время nw.js нам подошел тем, что его можно было собрать с любой версией Chromium (мы накатывали на WebRTC компонент собственные патчи с фиксами).
Можно ли такое провернуть с Electron?
petyamorozov
01.07.2016 19:38-2Вот еще интересный подход к созданию десктопных приложений используя веб-технологии — web4gui — http://stunnix.com/prod/aws/
Там поднимается локально веб-сервер (и mysql, если надо) и открывается окно браузера (без меню и тулбаров). В качестве браузера кстати можно использовать nwjs. А логику — можно писать даже на php.
Правда это не бесплатное. Но тоже поддерживает win/mac/linux.
Antelle
01.07.2016 19:42+1Как же радуют такие сайты Used by: Dell, General Electric, Cisco. А конкретные приложения не покажете? Не покажем.
petyamorozov
01.07.2016 19:47ну вот вы когда visual studio у майкрософт покупаете, отчитываетесь в Редмонд о всех разработанных вами в visual studio проектах, да?
Antelle
01.07.2016 19:50Одно дело Visual Studio, который стандарт де-факто, а другое дело вот это. Я вот хотел скачать посмотреть чьё-нибудь готовое приложение, но его нет, ну и идём дальше.
petyamorozov
01.07.2016 19:52если вам надо какое-либо демо — качайте на том сайте его.
Если вам надо именно сделанное Dell'ом — напишите в Dell, может дадут его скачать.
IvanPanfilov
01.07.2016 21:02+1https://ru.wikipedia.org/wiki/HTML_Application
вот была перспективная технология
возродить бы MS эту штуку и сделать кроссплатформенной и кроссбраузерной и использовать со своим браузером который уже установлен.
а так тащить ради приложения целый браузер да еще с нодой — спасибо но нет.
pterolex
01.07.2016 22:31Мы переводили проект с NW.js на Electron где-то год назад потому, что в Electron можно было легко сделать инсталлятор и авто-апдейтер
(для nodewebkit пришлось писать свое решение)
ujeenator
02.07.2016 01:43У Electron'e в дистрибутиве сразу в комплекте идут видео кодеки
В NW.js их нет, мейнтейнеры говорят — сами вытаскиваейте билд кодека из Chrome
Для меня это был огромный перевес в сторону Electron'alsknwns
02.07.2016 02:17+2Мейнтейнеры говорят (http://docs.nwjs.io/en/latest/For%20Developers/Enable%20Proprietary%20Codecs/#enable-proprietary-codecs-in-nwjs),
вы можете взять предварительно скомпилированный ffmpeg вот тут https://github.com/iteufel/nwjs-ffmpeg-prebuilt/releases
Мне кажется квест с копированием одного файла в директорию, так себе причина для огромного перевеса.
ujeenator
02.07.2016 14:15первый предварительно скомпилированный ffmpeg был только с 29 марта
у меня проблема возникла гораздо раньше, еще в начале 2015-го
тогда этого не было
baka_cirno
02.07.2016 15:44Я мало что знаю о NW.js, но за Electron слежу регулярно и очень доволен тем, как он развивается. Сама идея мне импонирует — у них главным продуктом является Atom, а Electron просто платформа для него. Таким образом предпочтение отдается реально нужным фичам. Команда разработчиков очень отзывчивая, старается вчитываться в открытые issues и адекватно реагирует. Постоянно пилят API, не только дополняя его новыми возможностями, но и не забывая о рефакторинге. Они не боялись ломать обратную совместимость, в итоге API сейчас довольно стройный и кучерявый, в отличие от того, что было всего лишь полгода назад. Очень много тонких моментов, которые помогают сделать приложение больше похожим на родное.
jhekasoft
02.07.2016 17:09Ещё Electron не работает на Windows XP. Если вдруг нужна поддержка, то выбор за NW.js.
degorov
04.07.2016 09:30+1Выбор за версией 0.14.* LTS, последующие не работают. Я пробовал 0.15 — запускается, но не работает корректно, 0.16 — даже не запускается. Впрочем, никто и не обещал.
eugene2008
02.07.2016 20:07+4Был опыт написания небольшого проекта на связке Electron + Polymer. Дело было прошлой зимой и были кое где баги в самом движке электрона. В принципе все решилось танцами с бубном. Проблему безопасности решили просто: всю «секретную» логику вынесли в Node Native Addon. Там на на плюсах все написали. Конечно туда же можно и библиотеки впилить. У нас была например Crypto++. Далее во время сборки джава скиптового билда собрали хэши каждого файла и включили в аддон как константы. В аддоне поток мониторил файлы и при обнаружении разницы убивал процесс. Сам аддон защитили Arxan и Whitecryption. К слову сказать оба варианта прошли тест на проникновение в одной из кантор по безопасности (я в США живу — у нас тут их куча). Получилась комплексная зашита — зашифрованый бинарный код который в рантайм проверяет джаваскрипт (и конечно сам по себе имеет некоторую секретную логику аппликации).
zapolnoch
02.07.2016 20:07+2Это должно стать темой для статьи!
eugene2008
02.07.2016 22:19К сожалению проект закрыли сразу после репорта по безопасности. Причина во многом политическая: оказалось что кросс-платформенные и безопасные приложения можно писать на электроне с нод-аддонами, в результате пошло недовольство платформенных групп и они начали давить на руководство. Ведь до самого репорта никто не верил что можно добиться безопасности корпоративного уровня в приложении на Javascript / Polymer. Далее я переключился на мак и с тех пор уже много воды утекло. Примеры в статье придется делать самому так как оригинал под строгим копирайтом даже будучи в мусоре. К сожалению времени на статью нет. Но тому кому понадобиться, то что я написал уже достаточно для воодушевления! А инженерные задачи они всегда решаемы.
biaks
02.07.2016 20:08+6Добавлю свои пять копеек:
Недавно решал задачу по сборке NW.js из исходников в 32 битном линуксе с GLIBC 2.14 и 32 битным gcc 4.9.2. Сертификация, российские реалии, все такое. Долго и много разбирался с исходным кодом NW.js. В результате пришел к выводу, что это сделать невозможно. nw.js собирается только в debian wheezy x64 и только в static mode. Хочу поделиться здесь своими впечатлениями.
В начале про оригинальный chromium:
— Оригинальный chromium можно собрать на 32 битной системе и можно собрать в dynamic mode (с использованием shared библиотек).
— Разработчики chromium нашли фатальные недостатки в существующих системах сборки и написали для сборки свои инструменты: gyp (аналог cmake) — для верхнего уровня и ninja (аналог make) — для нижнего. Кроме того, они используют свой инструмент-обертку над системами контроля версий: depot_tools.
— Проекты, которые зависят от webkit, v8 и chromium также стараются использовать эти инструменты для сборки и контроля версий.
— Так как эти инструменты больше почти нигде не используются, документация и примеры по ним довольно скудные.
Теперь про nw.js, как я для себя понял структуру его исходного кода:
— Разработчики проекта nw.js клонировали исходный код проекта chromium в свой репозитрий. Вместе с wibkit, v8 и еще кучей всего, что входит в оригинальные проект.
— Клонировали туда исходный код проекта node.js.
— Добавили туда код, который дает возможность получать доступ из node,js к компонентам chromium и наоборот. Частично он внедрен в оригинальные файлы chromium и node.js.
— Добавили много хаотично расположенного кода, в том числе изменяя оригинальные файлы проектов chromium и node.js, который там и тут костылями устраняет появившиеся проблемы с безопасностью.
— Для сборки всего этого использовали инструменты и файлы конфигурации оригинального chromium, на живую и очень грубо внедряя свои модули в процесс компиляции, описанный в gyp файлах конфигурации.
Что получилось в итоге:
— Самое важное для меня: сломались все типы сборок под линукс, доступных в оригинальном chromium, кроме одной. Собрать nw.js можно только под debian wheezy x64, 64 битным gcc и только в static mode.
— Код, который отвечает за связывание node.js и chromium выглядит очень не аккуратно. Так выглядит код человека,
которому нужно, чтобы к утру заработало, а остальное можно будет поправить позже, когда спешка закончится. Например после добавления костылей в оригинальный код chromium появились кольцевые зависимости когда один модуль ссылается на другой и наоборот (из-за этого он и не собирается в shared mode).
— Не завидую разработчикам nw.js: у них теперь огромная проблема с обновлением оригинальных проектов, которые они использовали. Раз они залезли прямо в исходный код этих проектов со своими костылями, значит теперь после каждого обновления например chromium им придется все мержить со своими изменениями, тестировать что ничего не отвалилось и только после этого добавлять в свой репозиторий.
— Нормальной документации по сборке (да и по самому проекту) нет. То, что есть по сборке — это просто документация, которая кусками скопирована (причем в разное время) с документации оригинального проекта chromium.
Мое мнение такое:
— этот проект не является дальнейшим развитием проекта node.js. Это отдельный проект, который взял проекты chromium и node.js и на их основе сделал свой продукт.
— этот проект должен был называться не «nw.js» и не «webkit + node.js», а «chromium + node.js + костыли». В таком случае было бы сразу понятно, с чем придется иметь дело.
— проект делается в спешке и очень небольшим количеством разработчиков.
— деньги, которые были выделены на развитие проекта, в основном, видимо, ушли на рекламу, раскрутку и супер красивый сайт.
Я считаю, что именно поэтому о nw.js сейчас столько говорят, но никто пока не торопится его использовать. Деньги, потраченные на рекламу, дали свой результат, но сам проект из-за выбранного разработчиками способа реализации содержит несколько трудно разрешаемых системных проблем и поэтому до сих пор находится в достаточно сыром состоянии.degorov
04.07.2016 09:39О, а может быть Вы тогда сможете разъяснить такой момент. Я правильно понимаю, что и chromium и node там собраны с одной версией v8 и при этом эта версия может отличаться от той, с которой та же node идёт в случае если качать её отдельно? Ну то есть вот в 0.14.6 идёт нода v5.11.1 при этом она собрана с v8 5.0-чего-то-там, так же как и chromium 50, который там идёт. А если с nodejs.org скачать ноду, то там v8 более древняя — что-то из 4.8 или 4.9, кажется. Соответственно уровень поддержки ES6, например, в nw.js получается выше, чем заявленный для соответствующей версии node вот тут ну и в общем надо по версии chromium ориентироваться.
biaks
04.07.2016 19:25Все верно, в nw.js при сборке и chromium, и node.js используют одну и ту же версию v8.
Версия v8 у них обновляется вместе со всеми изменениями проекта chromuim, который они регулярно мержат со своим проектом nw.js.
Интересно кстати тестируют ли разработчики проекта nw.js работу node.js + последняя версия v8, если разработчики node.js сами ещё не включили эту версию в свой релиз?
degorov
Документация у nw.js не на гитхабе, а вот тут. Ответы на все вопросы, что у меня были, я там нашёл.
Ещё нюанс — у nw.js есть LTS релиз, который будет поддерживаться до мая 2018 года. Он поддерживает Windows XP (которую Electron, вроде бы, не поддерживал никогда) и старые версии OS X (кажется, вплоть до 10.6). При этом там вполне себе современные Chromium 50 и node 5.11.1.
nw.js в некоторых случаях заставлял меня грустить из-за того, что там нода и хромиум имели разные контексты (иногда это оправдано, но не всегда), но в 0.13 добавили Mixed Context Mode и я больше не грущу.