I>>>обычно у программистов уже есть свой оверлей со всеми стандартными функциями, а переделывать синтаксис орбражений в DOM зачем? XPath? реализуется если надо простым регспом, причем на стандартном сайте имхо такие извраты абсолютно не зачем.

M>>Там не только XPath, там и CSS селекторы. Которые во много раз удобнее, чем getElementById + getElmentsByTagName
I>Кстати говори XPath не полный к сожелению. мне бы гораздо удобнее был XPath, хотя селекторы тоже интересно.

XPath я, например, вообще не использую (разве что $("elem[@attr='']")). Необходимость получать элементы по интересным комбинациям CSS-селекторов встречается чаще. И обычно в таких комбинациях:

$("#myid > div")
$(".articles div:nth(odd)")

и т.п.

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

I>>>Деревья, табы, ajax? обычно это стандартные контролы на стандартной обвязке там где оно надо — проинклюдили скрипт вызвали функцию и все.

M>>Что такое стандартные контролы в стандартной обвязке?
I>Имеется ввиду что есть куча контролов уже написанных "самих в себе" требующих лишь их проинклюдить и вызвать

Не такие уж эти контролы и стандартные

Мы, например, используем такие же "стандартные" контролы и для jQuery: Tabs и календарь

M>>Что за свои шаблонизаторы? В статье об этом ни слова
I>Просто такаяже распространенная тема как и фреймворки. Шаблонизаторы модель "данные отдельно от дизайна" например :D

Ааа. MVC. Это лучше всего разруливается на стороне сервера, чем клиента.

M>>Теперь развернутый ответ.

M>>Что такое фреймворк? Это набор функций, облегчающий выполнение каких-то действий. Каждый раз, когда программист говорит "обычно у программистов уже есть свой оверлей со всеми стандартными функциями", это надо читать так: "а у нас уже свой фреймворк используется".
I>Так оно и есть, мне просто интересно почему именно такой способ используете, чем он лучше чем набор DOMа + несколько небольших функций. быстродействие то ведь страдает.

Почему же страдает? Вот сейчас сделал замер: Общая стоимость загрузки всей страницы — 1.7 секунд (без яваскрипта). Профайлер дал (264.365ms, 3915 calls) для JS. Это — на одной из самых тяжелых страниц. На нее навешано 200 KB (!) только яваскрипта. Путем сжатия всех библиотек и оптимизации это можно снизить килобайтов до 50

I>Ну почемуж:
I>вот кусок очень старой фии:
I>

I> function GetElementByProp.internal( o ) {
скип...
I> }

I>

I>За код не ручаюсь — по памяти писал — ну чтото типа этого и производные от него.
I>С помощью нее достаточно просто путешествовать и достаточно быстро. Но опережая Ваши возражения — конечно не так удобно, как с jQuery, однако гораздо быстрей.

Зачем мне быстрей, если мне надо удобно Да и разницу в 10-20 миллисекунд вряд ли кто заметит: http://dev.jquery.com/~john/slick/

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

Не в случае с jQuery. Нет, конечно, можно наворотить тааакооого!

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>но второй медленнее

Это всяко будет медленнее, чем getElementById

M>>Причем такие проблемы возникают на самом деле чаще, чем кажется. Просто работа с чистым JS или слабым фреймворком заставляет заранее избегать таких постановок задач. С jQuery становится нестрашен практически по-любому сформированный документ.

I>ну если честно, у меня и при plain js таких проблем не возникало. Они обычно возникают изза плохо продумывания и алгоритмизации, а также изза недостаточной универсальностти подходов при программировании. Если серъезно обдумать проект и набросать вехи на бумаге — обычно не встречается таких проблем. Это так называемый "дизайн программы"

У нас был такой случай. Выводится на экран довольно большая таблица с данными. В какой-то момент мы поняли, что надо визуально показывать юзеру, надж какой строчкой в таблице он находится. Вписывать в каждый tr onmouseover не хотелось. Плюс хотелось, чтобы при клике выбранная строка меняла свой цвет... В общем:

    $(document).ready(
        function() {
            $("#blocks tr") // находим все tr внутри элемента с id="blocks"
                .hover(
                    function() {  // onmouseover
                        var t = $(this);
                        if(t.attr('class') != 'selected')
                            t.css("background-color", "#efefef");
                        else
                            t.css("background-color", "#FFFF66");
                    },
                    function() { // onmouseout
                        var t = $(this);
                        if(t.attr('class') != 'selected')
                            t.css("background-color", "#fff");
                        else
                            t.css("background-color", "#FFFF99");
                    }
                )
                .click( // onclick
                    function() {
                        var t = $(this);
                        t.toggleClass('selected');
                        if(t.attr('class') == 'selected')
                            t.css("background-color", "#FFFF66");
                    }
                );
        }
    )

M>>Например, один мой товарищ получает списки цен в виде HTML. Ему надо выводить сумму. Решение? Простейше на jQuery.
I>ну список цен в виде HTML — это по моему самый простой пример неправильного "дизайна" — не считаете? :D

в том случае не было вариантов — файл он получал сос тороны и изменить ситуацию было нельзя.

I>Хотя если с таким столкнуться, я бы не стал загружать спсиок в DOM — зачем? проще пропарсить регспами будет в данном случае — и быстрей гораздо? я не прав?

сложно сказать. в той его ситуации было легче использовать jQuery. Потому что парсинг HTML — все же нетривиальная вещь.

M>>Решение занимает четыре строчки. Для того, чтобы его написать, мне понадобилось меньше пяти минут. И так — во всем
I>Спс, хоть один человек толково объяснить смог. а не затруднит ответить на вопрос?
I>всежтаки в серъезных проэктах очень критично две вещи — быстродействие и долгое незакрыти браузера ( у ff кстати есть офигенная привычка разрастаться от этого в памяти при использовании объектов, у IE + к этому — начинаются тормоза и он в конце концов умирает — в 6-ке было так 7 не мучал еще ), что можно сказать в отчношении jQuery?

Не знаю. У меня ни проблем с быстродействием ни проблем с закрытием браузера не было
Тем более, что jQuery — это не библиотека типа script.aculo.us. Она не содержит виджетов, контролов и прочая и прочая. Она является очень простым фундаментом, на основе которого можно сделать очень многое — в том числе и виджеты и контролы и проч. Но при этом уже "голый" jQuery — это гигантское ускорение разработки, когда нужно довольно много манипулировать DOM'ом или работать с AJAX'ом