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
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 34
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Могу ошибаться, но вроде как последняя версия electron поддерживает все плюшки es6, а nw.js — нет
        • НЛО прилетело и опубликовало эту надпись здесь
          • 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.
                          • НЛО прилетело и опубликовало эту надпись здесь
                          • 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
                                    Все верно, в nw.js при сборке и chromium, и node.js используют одну и ту же версию v8.
                                    Версия v8 у них обновляется вместе со всеми изменениями проекта chromuim, который они регулярно мержат со своим проектом nw.js.
                                    Интересно кстати тестируют ли разработчики проекта nw.js работу node.js + последняя версия v8, если разработчики node.js сами ещё не включили эту версию в свой релиз?

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