Как стать автором
Обновить

Комментарии 20

НЛО прилетело и опубликовало эту надпись здесь
Статья на эту тему была бы уместна…
есть и просто node-webkit, без express, без сети, кросплатформенный и бесплатный
Сыроват этот Sencha Desktop Packager еще. Когда я последний раз его пробовал остановился на том, что у него нету поддержки history и наше веб приложение дальше первой страницы не куда не двигалось… Хотя может сейчас уже исправили, обещали добавить в скором времени. Плюс все запросы работали только через jsonp потому что policy не позволяла делать кроссайт запросы. Хотя в phonegap нашли решение этой проблемы.
Есть еще www.tidesdk.org/ — бесплатный. С его помощью заворачивал одну «софтину» на extjs
Как? Тут до сих пор нет картинки про буханку хлеба и троллейбус?
Да ладно, оригинальная же идея — засунуть сервер и клиент в одно и то же приложение.

Сперва выглядит дико, я допускаю это; но затем ответ на вопрос «но зачем?» становится очевиден: затем, чтобы не переписывать сервер с нуля в форме так называемого «одностраничного» веб-приложения, а пользоваться этим сервером в готовом виде. (Ну если сервер готов уж совершенно — так что целая куча совершённого ранее труда не должна просто так уйти, как говорится, коту под хвост.)

Вот для разработки GUI-приложений «с нуля» я такой подход не рекомендовал бы.
Митгол.
Вызывает вопрос поддержка технологий вебкитом, встроенным в node-webkit.js. Судя по всему, node-webkit использует какой-то свой форк вебкита, в связи с чем какие-то новшества могут отсутствовать. К примеру, сделать 3D игрушку на WebGL и затем распространять просто так законно не получится.
Каждый раз поднимается этот вопрос, но ведь уже давно понятно, что подобные хаки что с node-webkit, что с phonegap / appcelerator, sencha desktop, qtwebkit не подходят для тех вещей, где нужна производительность. Написать игрушку на webgl — круто, да, но только для себя самого. Такие «обёртки» подходят для «формочных офисных приложений». Когда нужно быстро, дёшево накидать — и чтоб работало.
appcelerator явно лишний в этом ряду. У него конечно производительность тоже страдает, но он все таки не является оберткой-браузером
Да дело не столько в производительности, её, кстати, достаточно: тот же pixi.js показывает весьма впечатляющий результат. Заманчива именно перспектива писать приложение, которое как в браузере можно запускать, так и на десктопе.
А запустить вторую копию приложения? Или второе приложение, выполненное с использованием этого подхода?
Как вариант:
Номер порта который прослушивает «серверная» часть необходимо сгенерировать динамически. Функцию startServer выполнить не в виде immediate-function, а обычной функцией с параметром (номер порта) и вызывать её из webkit`а. Если приложение работает в классическом варианте предусмотреть передачу номера порта через параметры командной строки.
Да, с этим можно жить, но вариант не оч крутой. То есть можно забиндиться на порт, который потом захочет занять другое приложение, на чей порт мы случайно попали при генерации.
Возможно, отвечать на эту реплику через год с лишним — достаточно поздно; но я всё же отвечу (в интересах будущих читателей), что свободный порт можно сгенерировать вон тем модулем.
При таком подходе теряется возможность использовать скоуп node-webkit. Получается, что вы просто показываете сайт в милом окошке, все плюшки node-webkit придется забыть.
Согласен, это довольно логичный вывод.
Прошу прощения, написал не подумав: в манифесте node-webkit можно использовать ключ node-remote (более подробно тут), в котором указывается маска адресов / сайтов, которые могут использовать node-webkit скоуп (тема на github по этому поводу).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории