M>>Полный XPath поддерживать сложно, потому что все это — эмуляция, так как браузеры не обеспечивают нативную поддержку ни XPath ни CSS selectors

I>есть полная реализация на js XPath 1.0 100k

Ого

M>>>>// находим все элементы div внутри элемента с id="example"
I>>>GetElementByProp( document.body, "id", "example" )[0].getElementsByTagName("div")
I>>>ну илиже GetElementByProp( document.body, "id", "example" )[0].GetElementByProp( document.body, "tagName", "div" ),
I>>>но второй медленнее

M>>Это всяко будет медленнее, чем getElementById
I>но быстрее jQuery :D

Не думаю, чтобы настолько, чтобы это было заметно пользователю А выигрыш в скорости разработки налицо:

$('#example > div')
// vs.
GetElementByProp( document.body, "id", "example" )[0].getElementsByTagName("div")

I>Вот здесь кстати интересно очень. Щас объясню почему — у моего движка в качестве шаблонов используется XSLT+XML.
I>Т.е. мне не надо в кажлдом tr чтото дпроисывать — я в шаблоне в ставлю в один tr, остальное все сделает XSLT — и при этом никакой работы на стороне клиента — по моему гораздо более проще и быстрей. Правда конечнр, если такое ДЕЙСТВИТЕЛЬНО требуется на стороне клиента — тогда jQuery конечно выручает, согласен.

Это не всегда выгодно. Все же сотня записей onmouseover='что-то там' против одного вызова $('tr').hover опять же проиграет просто ценой размера страницы (и, как следствие, скоростью загрузки)

M>>в том случае не было вариантов — файл он получал сос тороны и изменить ситуацию было нельзя.
I>>>Хотя если с таким столкнуться, я бы не стал загружать спсиок в DOM — зачем? проще пропарсить регспами будет в данном случае — и быстрей гораздо? я не прав?
M>>сложно сказать. в той его ситуации было легче использовать jQuery. Потому что парсинг HTML — все же нетривиальная вещь.
I>ну я так понимаю там были ячейки с цифрами — можно было бы чтото типа <td>([0-9]*)</td> — врядли чтото еще надо было.

Ему надо было выводить сумму по колонкам. Или в какой-то определенной колонке. Там простыми регэкспами не отмахаешься.

I>Согласен, но всеж таки если не затруднит — я так понимаю что Вы плотно рабоатет на jQ, засечь начальный объем памяти браузера а затем в конце дня. Просто очень интересно. Я так понимаю стоит FF?

Это сложно сделать Это надо выделить машину, на которой надо запустить ФФ и ничего не делать Просто у меня и ФФ и Опера активно используются, они постепенно растут в памяти и сами Поэтому доля jQuery там будет незаметна (если она есть)

На самом деле сама задача поставлена не совсем корректно. Потому что есть, грубо говоря, пассивное использование яваскрипта и активное (применительно к документу).

Например:

$('a.clicker').click(
    function(){
        alert('yo');
    }
)

Это пассивное использование. Он один раз сделал attachEventListener и все — дальше все зависит от браузера (IE по-моему тек на этом, но не уверен)

С другой стороны есть активное манипулирование состоянием объектов и/или DOM'ом. Repaint and reflow: http://dev.opera.com/articles/view/efficient-javascript/?page=3

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

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