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

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

Как же хорош V8.
Прелюбопытно, что JSDB, если смотреть поиском по Хабрахабру, упоминаете почти только Вы (ну, ещё только iv1 упомянул в 2008 году да savostin упомянул не так давно), более же никто.

Хотя, казалось бы, клёвый джаваскриптовый движок, идеологически предшествующий Node.js (идея одна и та же: выковырять движок из браузера, наделить целым рядом автономных модулей — только для JSDB выдрали JS-движок из Файерфокса, а для Node.js из Chrome) и притом во многом его на Windows превосходящий. Прежде всего, JSDB превосходит Node.js на Windows по количеству готового работающего кода (что и не удивит, если припомнить, что история Node.js на Windows вне Cygwin насчитывает едва пару месяцев).

Вот пример такого превосходства: на JSDB работать с SQLite под Windows можно невозбранно, а чтобы добиться того же эффекта на Node.js, придётся дождаться окончания портирования node-sqlite3 на Windows; а меж тем это портирование ещё только на днях пришло к форме, предполагающей самостоятельную сборку пользователем из исходного кода; будет ли вообще когда-либо предлагаться решение в формате «просто скачайте и распакуйте» — Бог весть.

Единственный недостаток JSDB — не обладает той скоростью и той же асинхронностью, что у Node.js…

Между тем, при всех достоинствах, нет у JSDB на Хабрахабре ни десятков любителей, ни сообщества, ни блога отдельного.

Это прискорбно.
Кроме того, дистрибутив JSDB занимает меньше мегабайта, а файл node.exe занимает пять мегабайтов.
Как и многим замечательным вещам, JSDB не хватило пиара =(
Хоть сейчас и взлетели цены на террабайтники на всё-равно 1 или 5 метров это где-то в пределах статистической погрешности.
может виной всему event loop? И вся пляска вокруг асинхронности?
Вообще-то в JSDB есть system.wait().
Хотя, в общем, я согласен, что в Node.js асинхронность проще, потому что callback проще, чем wait.

Другое дело, что асинхронность не спасает от банальной невозможности открыть БД SQLite.
а она сильно кому-то нужна?
Если она не нужна, то что вместо неё?
а зачем? особенно под виндой? мускул например. или фаербирд
Что-то побольше. Например, Oracle Express Edition или MSSQL Compact или какая-то легкая версия DB2 от IBM — разве есть другие СУБД??? ;)

Никто не отменяет и более традиционных альтернатив: Postgre, MySQL или Firebird.

Не забудем также и про Derby DB.

Хотя для Node JS более естественным выбором может оказаться Mongo, Couch или Riak.
А мне интересно, почему не выстрелил Jaxer? Он же года за три до node.js появился.
jaxer.org/
Там внизу чарт, который все объясняет. Ну он был бы, конечно, нагляднее, если бы в него добавили NodeJS.
В отличие от JSDB и Node.js, Jaxer не работает из командной строки и притом требует (на Windows) установки, а не только распаковки.
Вот тут отличная статья об идее вложенной в node.js.
Плохо что мало кто понимает что это не просто интерпретатор JS выдраный из браузера с набором модулей
И продолжая тему JS-движков, хочу спросить, почему не попробовали Rhino? Это порт SpiderMonkey на JVM, который с определенной версии включили в официальную поставку Java. Rhino имплементит стандарт EcmaScript 3, а также некоторые расширения от Mozilla, в первую очередь E4X — XML литералы в JS. Из-за этого Rhino иногда отдают предпочтение, если работать с XML придется много. Вторым немаловажным преимуществом перед Node JS является сборщик мусора из Java, который отличается гораздо большей предсказуемостью. Особенно это важно для процессов на сервере, когда latency оказывается важнее простой скорости.

Rhino используется в Yahoo, где на нем работают сервисы YQL и YAP. Выбрали его как раз из-за предсказуемого GC и поддержки XML.

При бенчмаркинге Rhino нужно учитывать особенности Java — медленный стартап и «прогрев». Рекомендуется запустить бенчмарк минут на 10, и только после этого собирать показания. Ну и да, тюнинг JVM — дело тонкое, и не факт, что нет какой-то комбинации настроек, которая смогла бы повысить производительность системы.

По идее Rhino должен уступать Node JS из-за оверхеда, связанного с трансляций инструкций SpiderMonkey в Java bytecode.
Этот байткод можно спокойно кешировать.
Ну а JIT-код уже не скэшируешь. Поэтому все равно придется прогревать.
E4X — это скорее удобство работы с XML, чем скорость.
А движок староват и сильно быстро явно работать не будет.

Кстати, я пробовал запустить Rhino на винде — как-то не получилось. Час потыкался и забил.
Ещё есть QtScript… Интересно было бы посмотреть на его сравнительную скорость, т.к. довольно часто использую в своих проектах.
Это JavascrpiptCore из Webkit'а, да и в 5ой версии его на V8 заменят, будет та же node.js по скорости почти.
Спасибо. Особо за миром Qt не слежу, был не в курсе.
Скажите мне скорей какое состояние дел Node.JS vs. C++ на сезон 2011-2012. Порядок? Разы? Проценты?
Где-то от процентов до разов (в пределах до порядка). В общем, весьма и весьма!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.