1 июля 2016 в 16:34

NW.js или Electron?



Если вы хотите создать собственное десктопное приложение на основе веб-технологий, то мир опенсорса предлагает два основных варианта: 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
zplch @zapolnoch
карма
190,7
рейтинг 8,0
Пользователь
Похожие публикации
Самое читаемое Разработка

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

  • +2
    Документация у 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 и я больше не грущу.
  • 0
    Могу ошибаться, но вроде как последняя версия electron поддерживает все плюшки es6, а nw.js — нет
    • +1
      Ошибаетесь. Версии nw.js выходят регулярно. В стабильной ветке nw.js сейчас 51 хромиум и нода 6.2.2, в бете — 52-ой.
      • 0
        Значит я что-то напутал :/
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      > Еще, есть такой нюанс, как две сборки nw.js — с интегрированными DevTools и без них.
      Вот не понимаю, зачем было так делать

      • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    В свое время nw.js нам подошел тем, что его можно было собрать с любой версией Chromium (мы накатывали на WebRTC компонент собственные патчи с фиксами).

    Можно ли такое провернуть с Electron?
  • –2
    Вот еще интересный подход к созданию десктопных приложений используя веб-технологии — web4gui — http://stunnix.com/prod/aws/

    Там поднимается локально веб-сервер (и mysql, если надо) и открывается окно браузера (без меню и тулбаров). В качестве браузера кстати можно использовать nwjs. А логику — можно писать даже на php.

    Правда это не бесплатное. Но тоже поддерживает win/mac/linux.
    • +1

      Как же радуют такие сайты Used by: Dell, General Electric, Cisco. А конкретные приложения не покажете? Не покажем.

      • 0
        ну вот вы когда visual studio у майкрософт покупаете, отчитываетесь в Редмонд о всех разработанных вами в visual studio проектах, да?
        • 0

          Одно дело Visual Studio, который стандарт де-факто, а другое дело вот это. Я вот хотел скачать посмотреть чьё-нибудь готовое приложение, но его нет, ну и идём дальше.

          • 0
            если вам надо какое-либо демо — качайте на том сайте его.

            Если вам надо именно сделанное Dell'ом — напишите в Dell, может дадут его скачать.
            • +1

              Демки, сделанные создателями продукта, обычно не так показательны

  • +1
    https://ru.wikipedia.org/wiki/HTML_Application
    вот была перспективная технология
    возродить бы MS эту штуку и сделать кроссплатформенной и кроссбраузерной и использовать со своим браузером который уже установлен.

    а так тащить ради приложения целый браузер да еще с нодой — спасибо но нет.

    • +3
      Не виндовсом единым живет и пользуется IT мир)
  • 0
    Мы переводили проект с NW.js на Electron где-то год назад потому, что в Electron можно было легко сделать инсталлятор и авто-апдейтер
    (для nodewebkit пришлось писать свое решение)
    • 0
      Лол. Инсталлятор делается простейшим скриптом и одной командой NSIS. Автоапдейт рализуется в несколько десятков строк с учетом всех трех платформ. Не понимаю… Кроме того, для nwjs автоапдейты уже давно есть — в чате или гугл группе кидали ссылки на исходники. Даже у меня вон где-то завалялся.
  • +2
    Думаю, здесь стоит применить аксиому Эскобара
  • 0
    У Electron'e в дистрибутиве сразу в комплекте идут видео кодеки

    В NW.js их нет, мейнтейнеры говорят — сами вытаскиваейте билд кодека из Chrome

    Для меня это был огромный перевес в сторону Electron'a
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        первый предварительно скомпилированный ffmpeg был только с 29 марта

        у меня проблема возникла гораздо раньше, еще в начале 2015-го

        тогда этого не было
  • 0
    Я мало что знаю о NW.js, но за Electron слежу регулярно и очень доволен тем, как он развивается. Сама идея мне импонирует — у них главным продуктом является Atom, а Electron просто платформа для него. Таким образом предпочтение отдается реально нужным фичам. Команда разработчиков очень отзывчивая, старается вчитываться в открытые issues и адекватно реагирует. Постоянно пилят API, не только дополняя его новыми возможностями, но и не забывая о рефакторинге. Они не боялись ломать обратную совместимость, в итоге API сейчас довольно стройный и кучерявый, в отличие от того, что было всего лишь полгода назад. Очень много тонких моментов, которые помогают сделать приложение больше похожим на родное.
    • 0
      Ой да ладно, отзывчивая, очень. Ага. А чего они отказались фиксить баг с jQuery-то??? «Грузите его через ноду». Ага, а вы воду пейте вниз головой из носика чайника. Нет, спасибо, я лучше продолжу использовать стабильный NWJS.
  • 0
    Ещё Electron не работает на Windows XP. Если вдруг нужна поддержка, то выбор за NW.js.
    • +1
      Выбор за версией 0.14.* LTS, последующие не работают. Я пробовал 0.15 — запускается, но не работает корректно, 0.16 — даже не запускается. Впрочем, никто и не обещал.
  • 0
    Есть ещё такая статья. Там даже в таблице сравнение.
  • +4
    Был опыт написания небольшого проекта на связке Electron + Polymer. Дело было прошлой зимой и были кое где баги в самом движке электрона. В принципе все решилось танцами с бубном. Проблему безопасности решили просто: всю «секретную» логику вынесли в Node Native Addon. Там на на плюсах все написали. Конечно туда же можно и библиотеки впилить. У нас была например Crypto++. Далее во время сборки джава скиптового билда собрали хэши каждого файла и включили в аддон как константы. В аддоне поток мониторил файлы и при обнаружении разницы убивал процесс. Сам аддон защитили Arxan и Whitecryption. К слову сказать оба варианта прошли тест на проникновение в одной из кантор по безопасности (я в США живу — у нас тут их куча). Получилась комплексная зашита — зашифрованый бинарный код который в рантайм проверяет джаваскрипт (и конечно сам по себе имеет некоторую секретную логику аппликации).
    • +2
      Это должно стать темой для статьи!
      • 0
        К сожалению проект закрыли сразу после репорта по безопасности. Причина во многом политическая: оказалось что кросс-платформенные и безопасные приложения можно писать на электроне с нод-аддонами, в результате пошло недовольство платформенных групп и они начали давить на руководство. Ведь до самого репорта никто не верил что можно добиться безопасности корпоративного уровня в приложении на Javascript / Polymer. Далее я переключился на мак и с тех пор уже много воды утекло. Примеры в статье придется делать самому так как оригинал под строгим копирайтом даже будучи в мусоре. К сожалению времени на статью нет. Но тому кому понадобиться, то что я написал уже достаточно для воодушевления! А инженерные задачи они всегда решаемы.
  • +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 сейчас столько говорят, но никто пока не торопится его использовать. Деньги, потраченные на рекламу, дали свой результат, но сам проект из-за выбранного разработчиками способа реализации содержит несколько трудно разрешаемых системных проблем и поэтому до сих пор находится в достаточно сыром состоянии.
    • 0

      О, а может быть Вы тогда сможете разъяснить такой момент. Я правильно понимаю, что и 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 ориентироваться.

      • 0
        Все верно, в nw.js при сборке и chromium, и node.js используют одну и ту же версию v8.
        Версия v8 у них обновляется вместе со всеми изменениями проекта chromuim, который они регулярно мержат со своим проектом nw.js.
        Интересно кстати тестируют ли разработчики проекта nw.js работу node.js + последняя версия v8, если разработчики node.js сами ещё не включили эту версию в свой релиз?

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