Comments 19
слово «невозбранно» глаз сразу цепляет. Вы его в жизни используете, или это переводчик? (Это не издевка, просто интересно)
У меня дежавю: сначала был Java — язык, применявшийся в Вебе для серверной логики (сервлеты и прочее), а потом его допилили, чтобы иметь возможность применять на клиентской стороне и получился Google Web Toolkit. С Javascript все наоборот: изначально позиционировался как чисто клиентский язык, но потом Райан Дал и разработчики V8 сделали возможным выполнение Javascript на сервере. GWT объективно не нашел большого распространения. Интересно посмотреть получится ли у Javascript.
В настоящее время будущее Node.js ещё не достаточно лучезарно, поскольку ещё только ≈1½ месяца этот движок существует не только под Linux, под Mac и под Соляркою, но также и под Windows.
Следует ожидать мощного синергического толчка в тот момент, когда код модулей для Node.js начнут сочинять также и те разработчики на JavaScript, у которых на рабочем компьютере стоит Windows. По моим оценкам, для этого не достаточно портировать на Windows один только сам движок Node.js; потребуется также, по меньшей мере, вот что:
Следует ожидать мощного синергического толчка в тот момент, когда код модулей для Node.js начнут сочинять также и те разработчики на JavaScript, у которых на рабочем компьютере стоит Windows. По моим оценкам, для этого не достаточно портировать на Windows один только сам движок Node.js; потребуется также, по меньшей мере, вот что:
- Плавная работа пакетного менеджера npm. В частности, будет необыкновенном полезным появление у разработчиков модулей возможности поставлять заранее скомпилированные модули для win32 и win64: нельзя же полагаться на то, что у каждого конечного пользователя стоят средства разработки (например, Visual Studio 2010 Express). Понятно, что и разработчики модулей должны взяться за ум, а не то даже команду npm install zip нельзя под Windows подать без того, чтобы наткнуться на симлинк внутри тарболла. (Или автор скрипта npm/lib/utils/tar.js мог бы получше предусмотреть это.)
- Появление возможности оскриптовывания произвольной системной библиотеки. (Появится, вероятно, после портирования
node-ffi на Windows.) Только отсюда протянется тропка к сотворению GUI.
- Появление возможности работать с БД файлового (а не клиент-серверного) типа. (Появится, вероятно, после портирования
node-sqlite3 на Windows.)
Я ковырял jsdom какое-то время назад, пытался заставить работать кое-какие готовые скрипты на стороне сервера, и уперся в некоторые отличия в реализации jsdom и браузерного DOM. В итоге код не заработал, от идеи я отказался.
А какие задачи нужно было решать на сервере чтобы там потребовались DOM дерево?
Не вдаваясь в подробности, мне нужен был контент парсер типа Readability — www.readability.com/
А скажите мне, зачем нужен jQuery внутри Node.js?
Ответом на этот вопрос, собственно говоря, начинается моя блогозапись.
Меня именно это и удивило: XML, HTML, объекты DOM, обыкновенные объекты — 3 пункта из 4 требуют DOM-движка, а для последнего есть undescore.js, у которого и вызовы «удобные», и к node.js подключается легко и без дополнительных телодвижений, и функций по-боле, чем у jQuery.
Ну, разве я стану оспаривать достоинства underscore? Библиотека underscore в рейтинге npm не зря занимает первое место в номинации «пакет, на котором основано больше всего других пакетов»: это удобное, а иногда и незаменимое средство. Использовать jQuery вместе (а подчас и вместо) underscore понадобится только тогда, когда прежде всего нужно поработать с XML и (или) HTML.
Просто шикарно, спасибо. Для парсинга это просто незаменимая связка получается. Красота кода от jQuery + скорость от node.
Использую данный метод, наблюдаются утечки памяти.
Баг на jsodom. В частности при вызове window.close() который должен освобождать память — происходит весьма таки fatal error.
Есть идеи?
Баг на jsodom. В частности при вызове window.close() который должен освобождать память — происходит весьма таки fatal error.
Есть идеи?
Sign up to leave a comment.
Запускаем jQuery на движке Node.js вместо браузера