Комментарии 40
Интересный проект. На мой взгляд, пока что слишком мало «серверных» ф-ий (см. neutralino.js.org/docs/#/api/filesystem) для сколько-то серьёзного использования. Подождём… :)
+1
Я не до конца понял что «у ней внутре». У NW.js внутре неонка chromium, отсюда понятно какие фичи js/html/css можно использовать. А что здесь? Скажем, WebGL использовать можно?
+2
Не знаю, позже я напишу более подробную статью об этом фреймворке и разберу в том числе и этот вопрос.
+2
Спасибо! Будет интересно.
0
Да, спасибо, а то не понятно чем рендерится, что в вместо node.js и т.п. За счёт чего такая экономия?
+1
Справедливости ради, наличие в электроне двух движков JS — в Хроме и в Ноде выглядит как излишество. Плюс, непонятно, зачем надо тащить Хром целиком (с кучей ненужного функционала) вместо более легкого webview.
+2
На данный момент у этой библиотеки есть проблемы, если пытаться открывать страницу, путь до которой содержит нелатинские буквы. Ссылка на баг — bugs.webkit.org/show_bug.cgi?id=184660
0
![image](https://habrastorage.org/getpro/habr/comment_images/aa3/3a3/898/aa33a3898d667b2451791e21ecfa343b.png)
Судя по гитхабу и реддиту там нет встроенного браузера, только вебсервер, и оно юзает системный браузер по умолчанию.
В тестах ресурсы сжираемые системным браузером тактично не учитывают, а «стабильность» и «простоту отладки» фреймворка который будет на каждом компьютере запускать разные рендерные движки можете оценить сами)
+8
проблема ie6 набирает новые обороты
+1
Вот тебе и кроссплатформенность)))
+1
Ну, для каких-то приложений это будет приемлемым вариантом. Для WebGL игр, увы, не будет (мой юз-кейс).
0
Спасибо, обновил статью и добавил upd. Я ошибся с тем с расчетом того, сколько занимает Hello World на Neutralinojs.
0
Судя про гитхабу, там внутри webview на Webkit + GTK.
0
То есть при разработке надо учитывать все глюки обоих браузеров и все их версии. А если под mac, то видимо и Safari добавится в этот список. С электроном разработка выходит проще и результат более предсказуемый.
+1
Не совсем понимаю смысл такой реализации. Создание «кроссплатформенного» инструмента, где всё равно прийдётся думать о платформах…
Плата за память, не совсем целесообразная, как мне кажется.
Плата за память, не совсем целесообразная, как мне кажется.
0
в винде придется использовать практически мертвый ie11, а версия для мака лишь в планах. так себе альтернативка…
+1
![](https://habrastorage.org/webt/nx/k1/qf/nxk1qffglab9fkwe-ixzfnzspzs.jpeg)
Под капотом у клиента там вот эта библиотека — github.com/zserge/webview То есть на виндовс будет ослик…
+1
Спасибо, не слышал о нём.
От статьи как минимум ожидал, короткого обзора фрэймворка/хотябы рассмотра helloworld файла.
То что он потребляет так мало — это отлично, но остаётся ли он при этом альтернативой electron'у? Пакеты, модули, функционал и т.д...?
От статьи как минимум ожидал, короткого обзора фрэймворка/хотябы рассмотра helloworld файла.
То что он потребляет так мало — это отлично, но остаётся ли он при этом альтернативой electron'у? Пакеты, модули, функционал и т.д...?
+4
Это все замечательно, но как он себя ведет при расширении? Может он потом разростается, а электрон нет
+1
Есть еще интересное направление — приложения на node.js, но с нативным gui. Вот фреймворк на базе vue и react.
+2
А откуда такая интересная цифра для 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 окружения это неправильно.
0
Часто electron применяется как простой webview для сайта. Функции ос используются по минимуму, например добавляют иконку в трее и глобальные hotkeys. Интересно использование в таком ключе.
+1
Saidai, для мака есть аналогичный проект — https://github.com/pojala/electrino
0
Автор нормально так замерял размер папки электрона с модулями, половины которых после упаковки не будет в проекте совсем :)
+1
Да, вы абсолютно правы, правда одно вы не учли, а зачем было клонить и запускать electron hello world, нужно было просто написать что Electron г*вно и всё, а то напрягались, место на диске занимали, время свое тратили… Если пишите статью о сравнении двух технологий, вы должны их хотя бы хорошо знать. Вам задают вопросы по Neutralino, вы не знаете, по электрону вообще ерунду написали. А вы хоть другие проекты изучали? Как уже сказали Electrino, GoogleChromeLabs и прочие.
P.s. я осознаю ОБОСНОВАННОЕ отношение сообщества к Electron, но в статье намеренно манипулируют цифрами.
P.s. я осознаю ОБОСНОВАННОЕ отношение сообщества к Electron, но в статье намеренно манипулируют цифрами.
+1
Вот бы ещё узнать, почему это (и электрон) вообще кто-то использует, вместо qt/gtk/lazarus/.net/что-там-у-явы.
0
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.
0
Вот пример.
Делали мы игру. Начинали как прототип на js-движке, потом затея переросла во что-то крупное. Решили выпускать. Переписывать игру на другом стэке — дорого, не потянем. Поэтому завернули в NW.js и выпустили. Среди вариантов «погрязнуть в переписывании и не выпустить игру» и «выпустить хотя бы так» предпочтительнее оказался второй.
Делали мы игру. Начинали как прототип на js-движке, потом затея переросла во что-то крупное. Решили выпускать. Переписывать игру на другом стэке — дорого, не потянем. Поэтому завернули в NW.js и выпустили. Среди вариантов «погрязнуть в переписывании и не выпустить игру» и «выпустить хотя бы так» предпочтительнее оказался второй.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Neutralinojs — альтернатива Electron, потребляющая меньше памяти