Node.js

[Kolyaj]

http://kolyaj.ya.ru/replies.xml?item_no=2953

Покопался с Node.js. Для тех, кто не знает -- это такой серверный асинхронный JavaScript. Все три слова для меня ключевые, я люблю JavaScript, я люблю писать на нём в асинхронном стиле, и я давно, но не активно, ищу замену для PHP на сервере, т.к. после создания кода на JS в промышленных масштабах к PHP вернуться не могу. Так что всё, что будет написано, сильно субъективно, впрочем как и всегда.

Я написал на нём парсер логов достаточно кривого формата, которые после парсинга складываются в CouchDB. Т.к. сам Node.js предоставляет только низкоуровневые функции работы с файлами (что, несомненно, хорошо), то пришлось сначала написать функцию, наподобие PHP-шной file, но которая генерирует события по прочтении очередной строки файла (а логи, кстати, многострочные). Вокруг неё уже реализовался класс, генерирующий событие после прочтения очередной записи лога. А обработчик этих событий уже отсылал записи в CouchDB (тоже несколькими строчками). И всё это асинхронно, т.е. одновременно читается файл, одновременно парсится, одновременно отправляются несколько HTTP-запросов и всё это несколькими функциями без всяких потоков.

Вобщем достаточный минимум для серверных приложений в Node.js есть, осталось написать необходимый в виде пары сотен библиотек на любой вкус. Большинство, к сожалению, кинулось реализовывать никому не нужные в данном случае web-фреймворки, хотя есть несколько достаточно оригинальных решений, как например реализация доступа к sqlite, запускающая в отдельном процессе sqlite3 и парсящая её вывод в консоль.

Из особо бредовых на мой взгляд node-XMLHttpRequest, реализующая интерфейс XMLHttpRequest. Тот самый убогий интерфейс, для которого в браузерных фреймворках создают обёртки не ради кроссбраузерности, а ради удобства. При этом в Node.js нормальный HTTP-клиент из коробки.

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

З.Ы. Ах да, главный минус -- addListener не принимает контекста вызова колбэка, и я даже не знаю, что с этим делать, кроме повсеместного использования func.bind(), что мне не сильно нравится.

[Dmitry A. Soshnikov]

Спасибо, надо будет выделить время, тоже покапаться с серверным JS. Вкратце, конечно, читал обзоры, но не смотрел (и тем более, глубоко).

Основной принцип - они расширили какой-то движок (V8 в данном случае) новым функционалом и запускают этот интерпретатор на серваке?

Какие ещё альтернативы есть (тут, вроде недавно была похожая тема с каким-то другим серверным JS)? Какие лучшие?

Что за фреймворки? Кто пишет? Как их писать? Так же, как и для клиентского JS?

update:

Посмотрел исходники.

[Kolyaj]

Основной принцип - они расширили какой-то движок (V8 в данном случае) новым функционалом и запускают этот интерпретатор на серваке?

Он (Ryan Dahl) написал на C++ движок, использующий гугловский v8 для исполнения JS, и предоставляющий в JS объекты для асинхронного ввода/вывода.

Какие ещё альтернативы есть (тут, вроде недавно была похожая тема с каким-то другим серверным JS)? Какие лучшие?

Какие лучшие -- это, конечно, будет сильно субъективно. Но в данном случае неоспоримые преимущества: скорость v8 и асинхронность.

Что за фреймворки? Кто пишет?

http://wiki.github.com/ry/node

Как их писать? Так же, как и для клиентского JS?

Ну вот нет, например, нативного клиента для MySQL. Можно пойти в доки по MySQL, почитать формат общения клиента с сервером по TCP и написать асинхронного клиента на JS. Отличия от клиентского JS в задачах и в предоставляемых хост-объектах.

[Dmitry A. Soshnikov]

Он (Ryan Dahl) написал на C++ движок, использующий гугловский v8 для исполнения JS, и предоставляющий в JS объекты для асинхронного ввода/вывода.

Да, я посмотрел уже исходники, ядро (основное расширение для V8) - на С++, базовая библиотека - на JS.

скорость v8 и асинхронность

В смысле, асинхронность? Мульти-треды, мульти-процессы? Или тот же setTimeout?

http://wiki.github.com/ry/node

Угу, спасибо, полистаю.

Я вот эту тему имел в виду: Облачная платформа для разработки javascript приложений Там тоже наподобие - какой-то движок расширен (возможно, Rhino, т.к. там фигурирует Java тоже; хотя, это лучше в той теме интересоваться)?

Node.js тоже как-то с облачной платформой связан? А в чём принципиальное отличие этой облачной платформы от этого Node.js?

[Kolyaj]

В смысле, асинхронность? Мульти-треды, мульти-процессы? Или тот же setTimeout?

Например: написан у нас веб-сервер на Node.js, приходит запрос, нам нужно прочитать с диска файл. В случае с тем же PHP чтение файла будет синхронным и весь процесс заблокируется на время чтения, поэтому там создаётся много процессов для обработки многих запросов. В случае с Node.js оставляется колбэк, который будет вызван, когда файл будет считан с диска, а за то время пока он читается, текущий процесс обрабатывает остальные http-запросы. Т.е. как с XMLHttpRequest в браузере. Так что скорее setTimeout.

Я вот эту тему имел в виду: Облачная платформа для разработки javascript приложений Там тоже наподобие - какой-то движок расширен (возможно, Rhino, т.к. там фигурирует Java тоже; хотя, это лучше в той теме интересоваться)?

Node.js тоже как-то с облачной платформой связан? А в чём принципиальное отличие этой облачной платформы от этого Node.js?

Я вот, честно говоря, не понял, зачем эта облачная платформа мне лично могла бы пригодиться, а более подробно разбираться было лень. Но там Rhino, а это очень медленно. Вот тут человек говорит

Предварительные результаты: для Node в виртуальной машине и Rhino на обычной разница примерно в 6-7 раз, но это для единовременного выполнения скрипта. В случае обработки серии запросов Rhino будет ещё больше отставать из-за времени, необходимого на запуск JVM.

[Dmitry A. Soshnikov]

Например: написан у нас веб-сервер на Node.js, приходит запрос, нам нужно прочитать с диска файл. В случае с тем же PHP чтение файла будет синхронным и весь процесс заблокируется на время чтения, поэтому там создаётся много процессов для обработки многих запросов. В случае с Node.js оставляется колбэк, который будет вызван, когда файл будет считан с диска, а за то время пока он читается, текущий процесс обрабатывает остальные http-запросы. Т.е. как с XMLHttpRequest в браузере. Так что скорее setTimeout.

Угу, но на уровне реализации, файл-то, получается, читается в другом треде этого "текущего" процесса. Возможно, так же создаётся несколько процессов с несколькими тредами. Но, я только предполагаю.

Но с точки зрения JS-кода - это просто событийное программирование, где всё разруливается коллбэками и для JS это всё подаётся, как "один" поток?

Ок, будет время, поизучаю глубже.

Вообще, ECMAScript-у ничего не мешает дописать стандартную библиотеку (до уровня Ruby, Python) и расширить сферу использования, включая серверное программирование. Имею в виду, официально, по стандарту (хотя, в ближайшее время это вряд ли будет) + чтобы появилась пара-тройка признанных фреймворков - тогда JS с лёгкостью будет отличной альтернативой PHP/Python/Ruby на сервере.

[kurokikaze]

Вообще, ECMAScript-у ничего не мешает дописать стандартную библиотеку (до уровня Ruby, Python) и расширить сферу использования, включая серверное программирование. Имею в виду, официально, по стандарту (хотя, в ближайшее время это вряд ли будет) + чтобы появилась пара-тройка признанных фреймворков - тогда JS с лёгкостью будет отличной альтернативой PHP/Python/Ruby на сервере.

Имхо стандарт должен определять синтаксис и модель языка, а не список доступных модулей. Так что библиотека может быть и внешней - главное чтобы основные модули были доступны сразу с Node, а дополнительные - по требованию. Кстати, работа над package manager для Ноды уже идёт.

А насчёт реализации - там Global interpreter lock, как в Питоне. Впрочем, если сравнивать side-by-side, Нода по производительности делает питоновский асинхронный Торнадо.

[Gvozd]

В случае с тем же PHP чтение файла будет синхронным и весь процесс заблокируется на время чтения

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

[Kolyaj]

Кстати, работа над package manager для Ноды уже идёт.

А чем текущий require не устраивает?

в PHP также доступна асинхронность при работе с потоками

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

[kurokikaze]

А чем текущий require не устраивает?

Require это способ подключения файлов. А kiwi - способ инсталляции пакетов (с учётом версий и зависимостей) типа apt или rubygems. Или PEAR, если хотите.