Комментарии 19
слово «невозбранно» глаз сразу цепляет. Вы его в жизни используете, или это переводчик? (Это не издевка, просто интересно)
Вы просто недавно на хабре :) Почитайте топики этого автора и глаз у вас будет дергаться еще пару дней.

пы.сы. Мицгол, не осуждаю, просто человек чувствительный.
У меня дежавю: сначала был Java — язык, применявшийся в Вебе для серверной логики (сервлеты и прочее), а потом его допилили, чтобы иметь возможность применять на клиентской стороне и получился Google Web Toolkit. С Javascript все наоборот: изначально позиционировался как чисто клиентский язык, но потом Райан Дал и разработчики V8 сделали возможным выполнение Javascript на сервере. GWT объективно не нашел большого распространения. Интересно посмотреть получится ли у Javascript.
В настоящее время будущее Node.js ещё не достаточно лучезарно, поскольку ещё только ≈1½ месяца этот движок существует не только под Linux, под Mac и под Соляркою, но также и под Windows.

Следует ожидать мощного синергического толчка в тот момент, когда код модулей для 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.)
Впрочем, быть может, Node.js и не нуждается в GUI, если вебоинтерфейса будет достаточно.
Я ковырял jsdom какое-то время назад, пытался заставить работать кое-какие готовые скрипты на стороне сервера, и уперся в некоторые отличия в реализации jsdom и браузерного DOM. В итоге код не заработал, от идеи я отказался.
А какие задачи нужно было решать на сервере чтобы там потребовались DOM дерево?
Ответом на этот вопрос, собственно говоря, начинается моя блогозапись.
Меня именно это и удивило: 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.

Есть идеи?
Хотя нет, приведенный способ работает как часы. Глючил jquery.create(window);
При должном тестировании все-таки утечка возникает. Даже если window.close() работает без ошибки. А для веб сервера это недопустимо.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.