Создаём своё первое десктопное приложение при помощи HTML, JS и Node-WebKit

[@blackstrip]

А можно еще брать dosbox, старый QBasic и текст проги в bas-файле, запихивать все это дело в самораспаковывающийся архив со скриптом, запускающим досбокс, запускающим qbasic, открывающим bas файл и исполняющим как интерпретатор эту прогу. Выполнение проги в интерпретаторе, запущенном в эмуляторе — это нормально, ибо как сказали, кажется, в майкрософте — если у вас не пашут, лагают и тормозят наши неоптимизированные проги, то просто выкиньте свой комп и купите более мощный. Аминь =)

[@MadridianFox]

Node-webkit – мощная штучка, открывающая новые возможности для веб-разработчиков.

Ну да, как С++/Java/PHP программисты тащат в JS свои классы, так и JS программисты пытаются делать всё старым проверенным способом. Но если в первом случае страдает производительность, то во втором — пользователь.

[@k12th]

Расскажите мне, как я страдаю, пользуясь Popcorn Time.

[@k12th]

да.

[@krasulya]

Большое спасибо за ссылку, крутое приложение

[@artem90]

На мой взгляд, для desktop приложений, все же, лучше использовать NET или Java, чем такие инструменты. Мне они напоминают php-gtk

[@sferrka]

Это не так, ведь PHP не создавался для UI, в отличии от HTML, CSS, JS. Собственно, десктопные приложения на этом стеке технологий пишутся уже давным-давно, в том или ином виде контейнеров (Adobe Air, .NET + WebBrowser, Java + WebView, в итоге Apache Cordova). Знаю очень много корпоративного софта, написанного подобным образом еще с 2002 года.

[@artem90]

Если говорить именно о HTML и CSS, то я обоими руками «за» использование данных технологий для оформления — они для этого и создавались, и выполняют свою функцию прекрасно. Но использование JS для кода самого приложения, на мой взгляд жирно.
Если сможете продемонстрировать, что JS быстрее и ест меньше памяти чем С# или Java для решения одной и той же задачи, я сильно изменю свой взгляд на JS.

[@sferrka]

Если сможете продемонстрировать, что JS быстрее и ест меньше памяти чем С# или Java для решения одной и той же задачи, я сильно изменю свой взгляд на JS.

Это не аргумент, CLR и JVM тоже медленные)

[@Leopotam]

habrahabr.ru/post/123154/
Попробуйте повторить на C# или Java на том же железе — это сильно пошатнет вашу веру в них.

[@nsinreal]

Я не бенчмарчил, но в чем проблема-то? Берешь и пишешь асинхронный код в c# и получишь как минимум те же самые лям соединений. Или есть какая-то проблема, о которой я не знаю?

[@Leopotam]

Не получишь. Памяти сожрется больше + тупо форкать потоки на клиентов даже с пулом — заткнется достаточно быстро с быстрым повышением времени отклика.

[@nsinreal]

Хм, для меня ваши заявления выглядят странно. К сожалению, повторить опыт пока что не удастся, да и лениво. Но…

Памяти сожрется больше

Ты хочешь сказать, что компилируемый (с легкой смещенностью в сторону интерпретируемого, но можно добиться native-компиляции) язык со статической типизацией будет жрать больше, чем интерпретируемый (с легкой смещенностью в сторону компилируемого благодаря v8)… Почему ты думаешь, что в C# памяти будет жраться больше?

тупо форкать потоки на клиентов даже с пулом — заткнется достаточно быстро с быстрым повышением времени отклика.

Объясни, пожалуйста. Есть асинхронные неблокирующие операции, есть тред-пул. В node.js все точно так же. В чем разница?

[@Leopotam]

Почему ты думаешь, что в C# памяти будет жраться больше?

Ну попробуй, увидишь. Хотя бы 100к коннектов сделай — приложение уже будет не совсем адекватно отвечать вместе с хостом. Довольно странно, но V8 + IO обвязка жрут меньше ресурсов на обработку, как памяти, так и cpu.

Есть асинхронные неблокирующие операции, есть тред-пул

Асинхронность делается фактически через тот же пул потоков. Нода — однопоточная, как бы это странно ни звучало. Весь код — это фактически реакция на события, вызываемые нейтивной частью. Как конкретно реализовано, к сожалению, сказать не могу, давно бросил native и пристрастился к managed, обратно возвращаться как-то не хочется. :)

[@nsinreal]

Ну попробуй, увидишь

Ну вот не могу я попробовать, на моей машине 4 гб памяти и большая часть занята. Плюс я на Windows. И делать 100к коннектов несколько напряжно.

Асинхронность делается фактически через тот же пул потоков.

В указанной статье сказано, что есть распределение на ядра. Так что не надо тут про однопоточность. И я гарантирую, что в C# можно на одном потоке держать больше одного соединения благодаря тем же асинхронным операциям.

Весь код — это фактически реакция на события, вызываемые нейтивной частью.

А вот теперь уже верю. Если часть кода написана на си/плюсах, то естественно эта часть будет быстрее C#-кода (хотя у C# часть вещей тоже реализована нативно). И естественно, что на примитивных случаях (типа того, которое описано в статье) большая часть работы будет отводиться на нейтив код.
А если добавим больше логики и операций, то гораздо больше времени будет занимать managed код и тут уже выигрыш будет у C#.

[@Leopotam]

моей машине 4 гб памяти и большая часть занята. Плюс я на Windows. И делать 100к коннектов несколько напряжно.

Нода есть под все основные платформы, включая Windows. Если не хватает ресурсов, то можно организовать тест на меньших циферках, сколько допустимо. Нода выиграет везде, где нужно много операций ввода-вывода — оно заточено именно под этот сценарий работы, а не под сложные и длительные операции обработки (которые можно распилить на стадии и колбеки или вообще вынести в нейтив, что не совсем честно, раз разговор про managed).

Так что не надо тут про однопоточность.

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

И я гарантирую, что в C# можно на одном потоке держать больше одного соединения благодаря тем же асинхронным операциям.

Еще раз — асинхронность .net внутри обеспечивается пулом потоков внутри, а не какой-то магией рантайма, позволяющей работать в одном потоке. Можно проверять текущий тред в колбеке — он будет / может быть отличным от основного потока.
Если прочитать статью по ссылке, то видно, что нода плохо переваривает хип боьше 500мб — выполнялся запуск с ключиками, настраивающими это поведение. В шарпе такое невозможно в общем случае — сборка мусора не дает гарантированного контроля. Да, можно установить размер хипа и ловить эксепшн + форсировать сборку мусора, но… это не работа для пользовательского кода.

[@Razaz]

Извиняюсь что вклиниваюсь в беседу многоуважаемых мужей, но:
1. async/await — не жрет потоки из тред пула, а разворачивается в стэйт машину и использует IOCP. Просто у вас есть выбор — использовать асинхронность по необходимости.
http://blog.stephencleary.com/2013/11/there-is-no-thread.html

2. Проблема Asp.Net была в потреблении памяти — каждый HttpContext — около 30 кб. Эта проблема решена
в Asp.Net 5.
http://gunnarpeipman.com/2014/07/asp-net-5-new-httpcontext/

3. Сборка мусора — отдельная тема. Многопоточный, неблокирующий GC проекрасно справляется ;)

В Java не спец, но на C#/.Net сейчас реально написать сервер, который выдержит может и не миллион соедиений(но близко к этому. Надо смотреть финальный код), но уж точно будет в выигрыше, если там появится бизнес логика.

Сугубо имхо

[@Leopotam]

Верно, но вот бы все это (>=FW5) завести на любой платформе, а не только Windows :) Mono в этом отношении слабоват в плане совместимости и особенностей реализации.

[@nsinreal]

Как-бы довольно скоро будет официальный .net под линукс.

[@Razaz]

К релизу обещались что усе ок будет. CoreClr пилят очень активно под Unix.
5 часов назад https://github.com/dotnet/coreclr/issues/366 например.

На данном витке развития причин недоверять MS нет) Я пробовал запускать тестовые приложения на Ubuntu — работает. Понятно, что еще рано писать тесты, но думаю будет шустро. Да и нодоводам может понравиться, что новый Asp.Net очень похож на Ноду со строгой типизацией;) К релизу готовят еще и родную поддержку PostgreSQL в EF7.

public class Startup
    {
        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerfactory)
        {
            app.UseStaticFiles();
        }
}

var express = require('express');
var app = express();
app.use(express.static(__dirname + '/public'));
app.listen(process.env.PORT || 3000);

Структура пакетов кстати тоже как у Ноды — каждый пакет имеет свой граф зависимостей.

[@Leopotam]

Так ведь только core, а не весь bcl. Ну и когда это будет, а релизить надо как обычно — вчера :) Сейчас используется самописный аналог pomelo (видео-конфа с разработчиком) на сервере, на клиенте mono 2.6.3 (unity). Гоняется реалтайм трафик поверх wss-вебсокетов между узлами кластера и клиентами и фронтенд узлами, тормозов не замечается.

[@nsinreal]

Спасибо за вклинывание в беседу. У вас получилось гораздо лучше.

[@gonzazoid]

в ноде один процесс. нет нитей, тредов, прочих синонимов. никто никуда не форкается, все в одном пространстве, мухи от котлет отделяются под капотом. Как в шарпах — хз, это была росто реплика в ваш диалог.

[@gonzazoid]

*читать комментарии буду я

[@mikenerevarin]

Проект недавно переименовался и теперь называется nw.js.

[@savostin]

Есть еще минус — весь ваш код открыт.

[@aleks_raiden]

так это ок для упаковки сложных веб-проектов — там и так код открыт

[@savostin]

Не совсем. Серверный код обычно скрыт.

[@aleks_raiden]

а при чем тут серверный код то? Максимум — в клиентскую часть впихивают автообновление. Все остальное как было через Ajax/sockets, так и остается. Лишь как бонус можно использовать UDP/TCP обычные сокеты

[@savostin]

А, Вы про веб-морду сайта-сервиса? Зачем это оформлять отдельным приложением? Какие функции ОС нужны для этого?

[@aleks_raiden]

Скорость, интеграция с десктопом, дополнительный функционал, который нельзя или сложно сделать внутри барузера, невозможность использовать современный браузер у клиента, сеть, работа с файлами прозрачная — много возможностей, но это специфические случаи.

[@sindzicat]

Получается, что я например таким образом могу создать веб-морду веб-приложения, которое будет у пользователя Windows запускаться как обычное приложение и даже при необходимости взаимодействовать с его программами на компьютере (например, САПР)? Я правильно понимаю? Если нет, подскажите пожалуйста примеры дополнительных возможностей, недоступных в браузере.

[@aleks_raiden]

На счет взаимодействия с программами — возможно придется писать бинарный модуль (плагин для v8/io.js). в остальном да.

[@dangreen]

github.com/nwjs/nw.js/wiki/Protect-JavaScript-source-code-with-v8-snapshot

[@chelaxe]

Помнится в далеком студенчестве делали такие штуки. HTA вроде называлось. Сейчас driverpack solution так же делает если ничего не спутал.

[@zenden2k]

Пожалуйста ребята не надо, теперь и десктопные приложения будут тормозить. Я конечно понимаю ребята что вы начинали с самого дна верстальщиками и что-то кроме убогого джаваскрипта выучить у вас ума не хватило, но джаваскрипт подходит для разработки десктопных приложений чуть менее, чем никак. Пусть джабоскрипт останется в вебе.

[@Sombressoul]

Пожалуйста, расскажите ещё этих замечательных историй про JavaScript. Только на этот раз бездарям из Epic Games, начинавшим верстальщиками с самого дна. Ведь они, к сожалению, не выучив ничего, кроме убогого и тормозного JavaScript, из-за нехватки ума и чувства вселенской несправедливости теперь транслируют в него игры на Unreal Engine 4.7. [/sarcasm]

[@k12th]

Пыхера ответ.