Comments 40
Интересный проект. На мой взгляд, пока что слишком мало «серверных» ф-ий (см. neutralino.js.org/docs/#/api/filesystem) для сколько-то серьёзного использования. Подождём… :)
Я не до конца понял что «у ней внутре». У NW.js внутре неонка chromium, отсюда понятно какие фичи js/html/css можно использовать. А что здесь? Скажем, WebGL использовать можно?
Не знаю, позже я напишу более подробную статью об этом фреймворке и разберу в том числе и этот вопрос.
Спасибо! Будет интересно.
Да, спасибо, а то не понятно чем рендерится, что в вместо node.js и т.п. За счёт чего такая экономия?
Судя по описанию на гитхабе оно использует libwebkit2gtk, а это полноценный браузерный движок и тот же Node.JS. Так что звучит красиво, а на практике...
Справедливости ради, наличие в электроне двух движков JS — в Хроме и в Ноде выглядит как излишество. Плюс, непонятно, зачем надо тащить Хром целиком (с кучей ненужного функционала) вместо более легкого webview.
На данный момент у этой библиотеки есть проблемы, если пытаться открывать страницу, путь до которой содержит нелатинские буквы. Ссылка на баг — bugs.webkit.org/show_bug.cgi?id=184660
Судя по гитхабу и реддиту там нет встроенного браузера, только вебсервер, и оно юзает системный браузер по умолчанию.
В тестах ресурсы сжираемые системным браузером тактично не учитывают, а «стабильность» и «простоту отладки» фреймворка который будет на каждом компьютере запускать разные рендерные движки можете оценить сами)
проблема ie6 набирает новые обороты
Вот тебе и кроссплатформенность)))
Ну, для каких-то приложений это будет приемлемым вариантом. Для WebGL игр, увы, не будет (мой юз-кейс).
Спасибо, обновил статью и добавил upd. Я ошибся с тем с расчетом того, сколько занимает Hello World на Neutralinojs.
Тогда уж лучше взять carlo. Идея та же самая: используем внешний браузер вместо того чтобы таскать свой, но у carlo это всегда хром, а значит более предсказуемо.
UFO just landed and posted this here
тыц
Падает с ошибкой.
Q: What happens if the user does not have Chrome installed?
Carlo prints an error message when Chrome can not be located.
Падает с ошибкой.
Судя про гитхабу, там внутри webview на Webkit + GTK.
Нашел в одной статье не медиуме.
Neutralinojs window mode uses MSHTML (IE10/11) on Windows and gtk-webkit2 on Linux for rendering web pages.
То есть при разработке надо учитывать все глюки обоих браузеров и все их версии. А если под mac, то видимо и Safari добавится в этот список. С электроном разработка выходит проще и результат более предсказуемый.
Не совсем понимаю смысл такой реализации. Создание «кроссплатформенного» инструмента, где всё равно прийдётся думать о платформах…
Плата за память, не совсем целесообразная, как мне кажется.
Плата за память, не совсем целесообразная, как мне кажется.
в винде придется использовать практически мертвый ie11, а версия для мака лишь в планах. так себе альтернативка…
Под капотом у клиента там вот эта библиотека — github.com/zserge/webview То есть на виндовс будет ослик…
Спасибо, не слышал о нём.
От статьи как минимум ожидал, короткого обзора фрэймворка/хотябы рассмотра helloworld файла.
То что он потребляет так мало — это отлично, но остаётся ли он при этом альтернативой electron'у? Пакеты, модули, функционал и т.д...?
От статьи как минимум ожидал, короткого обзора фрэймворка/хотябы рассмотра helloworld файла.
То что он потребляет так мало — это отлично, но остаётся ли он при этом альтернативой electron'у? Пакеты, модули, функционал и т.д...?
Это все замечательно, но как он себя ведет при расширении? Может он потом разростается, а электрон нет
Есть еще интересное направление — приложения на node.js, но с нативным gui. Вот фреймворк на базе vue и react.
А откуда такая интересная цифра для Electron: 85mb? Вы пробовали собрать приложение?
На Windows:
Установщик: 41,1mb.
Распакованное приложение: 145mb.
При запуске три процесса: 16,5mb + 25mb + 15mb = 56,5mb. Много, не спорю.
На Linux ситуация даже лучше, но сейчас нет возможности дать цифры именно по Hello world на Linux, но подход замерять размер для dev окружения это неправильно.
На Windows:
Установщик: 41,1mb.
Распакованное приложение: 145mb.
При запуске три процесса: 16,5mb + 25mb + 15mb = 56,5mb. Много, не спорю.
На Linux ситуация даже лучше, но сейчас нет возможности дать цифры именно по Hello world на Linux, но подход замерять размер для dev окружения это неправильно.
Часто electron применяется как простой webview для сайта. Функции ос используются по минимуму, например добавляют иконку в трее и глобальные hotkeys. Интересно использование в таком ключе.
Saidai, для мака есть аналогичный проект — https://github.com/pojala/electrino
Автор нормально так замерял размер папки электрона с модулями, половины которых после упаковки не будет в проекте совсем :)
Да, вы абсолютно правы, правда одно вы не учли, а зачем было клонить и запускать electron hello world, нужно было просто написать что Electron г*вно и всё, а то напрягались, место на диске занимали, время свое тратили… Если пишите статью о сравнении двух технологий, вы должны их хотя бы хорошо знать. Вам задают вопросы по Neutralino, вы не знаете, по электрону вообще ерунду написали. А вы хоть другие проекты изучали? Как уже сказали Electrino, GoogleChromeLabs и прочие.
P.s. я осознаю ОБОСНОВАННОЕ отношение сообщества к Electron, но в статье намеренно манипулируют цифрами.
P.s. я осознаю ОБОСНОВАННОЕ отношение сообщества к Electron, но в статье намеренно манипулируют цифрами.
Я не писал, что Electron плох. Поинт в том, что NeutralinoJs потребляет меньше памяти по словам, разработчика фреймворка. Это я и проверил. Я не собирался в этой статье полноценно сравнивать две технологии, а только познакомить с Neutralinojs, так как на русском о нем ничего не было.
Вот бы ещё узнать, почему это (и электрон) вообще кто-то использует, вместо qt/gtk/lazarus/.net/что-там-у-явы.
JavaFX.
Ну я вижу только 3 «причины»:
1. Есть определенные условия, в которых компания ориентированная на web не может себе позволить набрать и содержать команду «нативщиков» ради одного краткосрочного проекта. Ну затем этот краткосрочный проект может перелиться в что-то крупное и переписывать будет очень дорого, но это жестокие реалии, с этим трудно что-то сделать.
2. Есть проекты которые заведомо жертвуют быстродействием, ради UI и скорости разработки: Slack, Github Desktop etc.
3. Когда нужна поддержка пользовательских плагинов, в большом количестве и простоте написания: VSCode, Atom.
Ну я вижу только 3 «причины»:
1. Есть определенные условия, в которых компания ориентированная на web не может себе позволить набрать и содержать команду «нативщиков» ради одного краткосрочного проекта. Ну затем этот краткосрочный проект может перелиться в что-то крупное и переписывать будет очень дорого, но это жестокие реалии, с этим трудно что-то сделать.
2. Есть проекты которые заведомо жертвуют быстродействием, ради UI и скорости разработки: Slack, Github Desktop etc.
3. Когда нужна поддержка пользовательских плагинов, в большом количестве и простоте написания: VSCode, Atom.
Вот пример.
Делали мы игру. Начинали как прототип на js-движке, потом затея переросла во что-то крупное. Решили выпускать. Переписывать игру на другом стэке — дорого, не потянем. Поэтому завернули в NW.js и выпустили. Среди вариантов «погрязнуть в переписывании и не выпустить игру» и «выпустить хотя бы так» предпочтительнее оказался второй.
Делали мы игру. Начинали как прототип на js-движке, потом затея переросла во что-то крупное. Решили выпускать. Переписывать игру на другом стэке — дорого, не потянем. Поэтому завернули в NW.js и выпустили. Среди вариантов «погрязнуть в переписывании и не выпустить игру» и «выпустить хотя бы так» предпочтительнее оказался второй.
Sign up to leave a comment.
Neutralinojs — альтернатива Electron, потребляющая меньше памяти