jQuery – Javascript нового поколения - Веб программирование

S>А у тебя случайно не было ссылок на DOM изнутри JS объектов?
Ссылок — в смысле переменных, которые указывали бы на DOM элементы? конечно были, достаточно много. Знаю, знаю JS eff говорит о том, что надо юзать ID, но к сожелению присваивать ID находу куче элементов не есть хорошо и удобно (Ветка дерева содержит 500 элементов, каждый запоминается в структуре контрола, чтобы быстро обеспечивать выборку. Можно конечно родить енумератор для ID, но как то не комильфо). Или есть вариант?

I>>Да, согласен, бегать будет чуть чаще, но по моему модульность добавляет удобства?
S>Удобство должно быть измеримым.

Сама по себе модульность ничего не значит. Слепое следование абстрактным ценностям прививают низкооплачиваемым кодерам, поскольку считается, что они не в состоянии самостоятельно ориентироваться в окружающем мире. Так и здесь — какой бенефит даст тебе возможность не включать, к примеру, анимацию? Кроме download size?
Ну у меня привычка есть — не включать на страницу то, что там не используется — чистота кода так сказать :D
Сам же ругаю FW здоровые — а они как раз и грузят все что можно на каждую страницу. Ведь кроме размера это добавляет времени и на рендеринг страницы — отсройка JS насколько я знаю тоже времени занимает?
Нет, ну в случае с jQuery, я согласен — можно еще мириться, но ведь все таки больше используется именно поисковые запросы, что мешает отделить все остальное на основе плагина? В конце концов если программист найдет нужным включить основные плагины в модуль jQ — это достаточно просто, а вот "вытаскивать" модули из сегодняшней сборки — достаточно проблематично. Я по этому и люблю модульность — не потому что "Так Сказали" :D "Так Сказали" мне говорили когда я на ДВК программил в Малой Академии наук ( оттуда начал я свой компьютерный путь когда было мне 12 лет... эххх ностальгия :D ), с тех пор прошло очень много времени, и опыта я набрался достаточно, и считаю как раз удобно имея функциональный набор комбинировать его так, как тебе необходимо. Просто очень многие как раз не делуют "чистые" страницы и зачастую весь набор библиотек гркзится на каждую страницу, даже если там нет ни одного их вызова — я частенько, расковыривая сайты, такое наблюдал. В принципе если пренебречь тем, что есть первичная нагрузка, и подготовка JS занимает малую толику времени, можно этим принебречь... Но я всегда не любил за это Microsoft :D ( они очень любят делать именно так — навтыкать что нужно и ненужно, расширять свою программу экстенисвно ), и боюсь быть похожими на них... Естественно, все что написал — ИМХО. Быть может я делую ненужную работу, делая страницы более "прозрачными" — не знаю.

S>В других случаях модульность может действительно добавить удобства — там, к примеру, где модули могут быть взаимозаменяемыми. Но что-то я не вижу никакой взаимозаменяемости в jQuery.
А вот тут бы поспорил — представь себе, что в одной форме можно было бы разделить два движка посиковых CSS селекторный и XPath-овый. Хочешь — используй одновремено оба, хочешь по отдельности. Хочешь — прикурвти свои собственные селекторы — ведь XPath & CSS селекторы — не есть конечная инстанция в поиске — можно былоб тотже регсповый прикрутить например. Сделав DOM пространствое единым текстовым полем с возможностью его парсить — есть задачи когда это удобней — опять же ИМХО конечно.

S>А, собственно, зачем? У тебя есть какие-то реальные задачи, требующие неподдерживаемого в jQuery XPath? Или ты просто заранее боишься, что однажды такая задача возникнет, а отказаться от jQuery будет уже поздно?

Ну во первых боюсь :D во вторых если честно — ОЧЕНЬ не хватает position, т.к. без этого часть логики, которую я бы хотел пренести с XSLT ( обычно раскраска данных и создание элементов в контроле ) не может быть перенесена. У меня часто используется определение позиции элементов внутри коллекции, они идут по порядку — и достаточно удобно их раскрашивать либо же перекладывать ориентируясь на их нумерацию в коллекции. Хотя быть может я не до конца просек все фишки jQ?

I>>Хотя даже не знаю, может эти ребята сделают потом отдельно реализацию XPath? Было бы классно, потому как единственную полную реализацию XPath 1.0 я уже приводил 100k

S>Ну, я так думаю, что пусть цветут все цветы. Вот у тебя есть полная реализация XPath. Если она тебе часто нужна, то никакой проблемы один раз ее отдать пользователю нету. Достаточно озаботиться грамотным кэшированием, и никто ничего не заметит. Ну положим 100к отдать — согласен — можно — но она еще и достаточно медленна, и к сожелению не так популярна, как тотже jQ, может быть тогда соптимизировали бы :D А копаться самому — нет, кончено можно — но шибко времени много уйдет + кто сказал что я знаю один лучше остальных :D

S>Я считаю CSS селекторы очень важными, и вот почему: сейчас CSS по факту используется гораздо чаще, чем XSLT. Поэтому как правило HTML уже верстается так, чтобы можно было применять CSS правила. Так что шанс на то, что нужные тебе элементы уже проидентифицированы каким-то CSS правилом, достаточно велик. И тебе не нужно переводить "#cart-content > td.amount" в XPath, можно просто его скопировать.

Быть может, если честно то давно уже очень хочется получить некую суперпозицию XPath и CSS селекторов — CSS селекторы — это некое подобие передвижения по дереву не путем а выборками как бы — и действительно — встречается такое чаще да и синтаксис не так сложен, как в xph, но есть такие моменты которые не решить ими, к сожелению. Я согласен выучить новый язык

Я Даже согласен поучавствовать в его созждании, чтобы потом иметь удобный инструмент. А то что сейчас есть — тоже не плохо, но инструменты имеют тенденцию устаревать :/ Скока лет XPath у то :D

В принципе jQ итак сделала шаг в этом направлении — она объеденила CSS sel & XPh. Буду ждать дальнейших шагов. Вот кстати где и нужна будет модульность, о кторой выше говорилось. А то будет уже не 20 кил ) а кил 100 потом

I>>В принципе очень функциональная штука.
S>Угу. Я вообще всё больше начинаю верить в декларативные языки запросов.
Ага, удобно. Но синтаксис мутный к сожелению ) Хотя зная один легко осваиваешь другой

Здравствуйте, ionicman, Вы писали:

S>>А у тебя случайно не было ссылок на DOM изнутри JS объектов?
I>Ссылок — в смысле переменных, которые указывали бы на DOM элементы? конечно были, достаточно много.
Ну вот оттуда и утечки. GC не может разрулить циклы, часть которых расположена в DOM, а часть — в JS.
I>Ну у меня привычка есть — не включать на страницу то, что там не используется — чистота кода так сказать :D
I>Сам же ругаю FW здоровые — а они как раз и грузят все что можно на каждую страницу. Ведь кроме размера это добавляет времени и на рендеринг страницы — отсройка JS насколько я знаю тоже времени занимает?
Что такое "отсройка JS"? Парсинг джаваскрипта? Ну, можно померить, но боюсь разница между 20k и 200k джаваскрипта будет тоньше комариного хвоста.

I>Нет, ну в случае с jQuery, я согласен — можно еще мириться, но ведь все таки больше используется именно поисковые запросы, что мешает отделить все остальное на основе плагина? В конце концов если программист найдет нужным включить основные плагины в модуль jQ — это достаточно просто, а вот "вытаскивать" модули из сегодняшней сборки — достаточно проблематично. Я по этому и люблю модульность — не потому что "Так Сказали" :D "Так Сказали" мне говорили когда я на ДВК программил в Малой Академии наук ( оттуда начал я свой компьютерный путь когда было мне 12 лет... эххх ностальгия :D ), с тех пор прошло очень много времени, и опыта я набрался достаточно, и считаю как раз удобно имея функциональный набор комбинировать его так, как тебе необходимо. Просто очень многие как раз не делуют "чистые" страницы и зачастую весь набор библиотек гркзится на каждую страницу, даже если там нет ни одного их вызова — я частенько, расковыривая сайты, такое наблюдал. В принципе если пренебречь тем, что есть первичная нагрузка, и подготовка JS занимает малую толику времени, можно этим принебречь... Но я всегда не любил за это Microsoft :D ( они очень любят делать именно так — навтыкать что нужно и ненужно, расширять свою программу экстенисвно ), и боюсь быть похожими на них... Естественно, все что написал — ИМХО. Быть может я делую ненужную работу, делая страницы более "прозрачными" — не знаю.
А чего тут знать — оптимизацию нужно делать с профайлером. Смотри на page load times. Если ты потратил день, а сэкономил 1ms из 790, то лучше заняться чем-то другим.

I>А вот тут бы поспорил — представь себе, что в одной форме можно было бы разделить два движка посиковых CSS селекторный и XPath-овый. Хочешь — используй одновремено оба, хочешь по отдельности.
Не понимаю, что значит "по отдельности"? В jQuery и XPath и CSS присутствуют одновременно. Хочешь — используй одновремено оба, хочешь по отдельности. Чего именно ты добъешся, распилив эту функциональность на jQueryCSS.js и jQueryXPath.cs?

S>>А, собственно, зачем? У тебя есть какие-то реальные задачи, требующие неподдерживаемого в jQuery XPath? Или ты просто заранее боишься, что однажды такая задача возникнет, а отказаться от jQuery будет уже поздно?

I>Ну во первых боюсь :D во вторых если честно — ОЧЕНЬ не хватает position, т.к. без этого часть логики, которую я бы хотел пренести с XSLT ( обычно раскраска данных и создание элементов в контроле ) не может быть перенесена.
Как раз раскраска данных и создание элементов делаются на jQuery просто офигенно.
I>У меня часто используется определение позиции элементов внутри коллекции, они идут по порядку — и достаточно удобно их раскрашивать либо же перекладывать ориентируясь на их нумерацию в коллекции. Хотя быть может я не до конца просек все фишки jQ?
Может быть. Приведи пример раскраски, которую ты делаешь в XPath, и не можешь в CSS/jQuery.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Если не хранить ссылки, то как тогда быть — ID? :/

добавляет времени и на рендеринг страницы — отсройка JS насколько я знаю тоже времени занимает?
S>Что такое "отсройка JS"? Парсинг джаваскрипта? Ну, можно померить, но боюсь разница между 20k и 200k джаваскрипта будет тоньше комариного хвоста.
Ага, парсинг. Вот про здарежку не скажу — до такой проверки руки не доходили. Быть может она и мала.

похожими на них... Естественно, все что написал — ИМХО. Быть может я делую ненужную работу, делая страницы более "прозрачными" — не знаю.
S>А чего тут знать — оптимизацию нужно делать с профайлером. Смотри на page load times. Если ты потратил день, а сэкономил 1ms из 790, то лучше заняться чем-то другим.
Ну кроме page load существует такой параметр как рпеемтсвееность кода — т.е. "прозрачный" код гораздо легче править аутсорсеру либо же другому человеку в комнаде — т.к. не приходится вычленять что с кем и как работает — все что есть — значит работает. Если же один пишешь — может быть тогда только page load

I>>А вот тут бы поспорил — представь себе, что в одной форме можно было бы разделить два движка посиковых CSS селекторный и XPath-овый. Хочешь — используй одновремено оба, хочешь по отдельности.
S>Не понимаю, что значит "по отдельности"? В jQuery и XPath и CSS присутствуют одновременно. Хочешь — используй одновремено оба, хочешь по отдельности. Чего именно ты добъешся, распилив эту функциональность на jQueryCSS.js и jQueryXPath.cs?
Возможность использовать лишь то что надо и когда надо. Кроме того возможность добавялть свои парсеры.

S>>>А, собственно, зачем? У тебя есть какие-то реальные задачи, требующие неподдерживаемого в jQuery XPath? Или ты просто заранее боишься, что однажды такая задача возникнет, а отказаться от jQuery будет уже поздно?

S>Может быть. Приведи пример раскраски, которую ты делаешь в XPath, и не можешь в CSS/jQuery.
Ну типа такого например:
tr[position() mod 3 = 0 ]
так, на вскидку. У меня такой фигней раскрашиваются группы ячеек в таблице.

M>>Сможет ли с этим справиться предложенный getProp или регэксп — не знаю. Я даже не представляю, как на них написать аналог $("#checkout_grid input:checkbox")

I>Ну на самом деле не сложно:
I>GetProp( document.getElementByID("checkout_grid"),["tagName", "type"],["input", "checkbox"] );

На самом деле это сложно

Один вызов с ясным CSS против вызова функции (с неясным названием, кстати

) с тремя аргументами

M>>Особенности движка. Много раз обсуждалось в "обсуждении сайта", но общее решение было, что такая фича скорее не нужна, чем нужна

I>:D Ну как сказать, мне очень не хватает — бывает гдето чуть ошибешься, или забудешь чтонидь добавить. Да, я конечно знаю, что можно добьавить все это новыми сообщениями, но как то не удобно, хотя не смертельно есессно :D

Ну вот примерно такая же аргументация была — что это не смертельно

Зато, когда длинное сообщение пишешь, часто сидишь, выверяешь текст, чтобы все было сразу — стройно и логично

ionicman wrote:

> Если не хранить ссылки, то как тогда быть — ID? :/
Да. Можно их генерить. Заведи глобальную функцию
function genId(){return 'id'+(++genId.currId)}

Или как вариант — разрушать ссылки вручную (например в window.onunload).

Posted via RSDN NNTP Server 2.1 beta

I>добавляет времени и на рендеринг страницы — отсройка JS насколько я знаю тоже времени занимает?
S>>Что такое "отсройка JS"? Парсинг джаваскрипта? Ну, можно померить, но боюсь разница между 20k и 200k джаваскрипта будет тоньше комариного хвоста.
I>Ага, парсинг. Вот про здарежку не скажу — до такой проверки руки не доходили. Быть может она и мала.

200KB у нас занимает 200ms. При том, что, на самом деле, это можно убить до 50ms максимум — мы оптимизацией еще не занимались

I>похожими на них... Естественно, все что написал — ИМХО. Быть может я делую ненужную работу, делая страницы более "прозрачными" — не знаю.
S>>А чего тут знать — оптимизацию нужно делать с профайлером. Смотри на page load times. Если ты потратил день, а сэкономил 1ms из 790, то лучше заняться чем-то другим.
I>Ну кроме page load существует такой параметр как рпеемтсвееность кода — т.е. "прозрачный" код гораздо легче править аутсорсеру либо же другому человеку в комнаде — т.к. не приходится вычленять что с кем и как работает — все что есть — значит работает. Если же один пишешь — может быть тогда только page load

В этом отношении jQuery — гениальна

Потому что, за исключением вырожденных и действительно сложных случаев, глядя на код сразу понимаешь, что происходит.

S>>Не понимаю, что значит "по отдельности"? В jQuery и XPath и CSS присутствуют одновременно. Хочешь — используй одновремено оба, хочешь по отдельности. Чего именно ты добъешся, распилив эту функциональность на jQueryCSS.js и jQueryXPath.cs?
I>Возможность использовать лишь то что надо и когда надо. Кроме того возможность добавялть свои парсеры.

Я не понимаю, зачем нужны свои парсеры. Свой парсер нужен, когда бОльшая часть задач не решается данной библиотекой (в нашем случае — jQuery).

S>>>>А, собственно, зачем? У тебя есть какие-то реальные задачи, требующие неподдерживаемого в jQuery XPath? Или ты просто заранее боишься, что однажды такая задача возникнет, а отказаться от jQuery будет уже поздно?

S>>Может быть. Приведи пример раскраски, которую ты делаешь в XPath, и не можешь в CSS/jQuery.
I>Ну типа такого например:
I>tr[position() mod 3 = 0 ]
I>так, на вскидку. У меня такой фигней раскрашиваются группы ячеек в таблице.

Грузанул

В рассылке по jQuery подсказали: (не проверено) $('tr').filter(function(position) { return position % 3 == 0; });
Что, увы, не настолько же понятно

Здравствуйте, Dmitrii 'Mamut' Dimandt, Вы писали:

DMD>Статья:
DMD>jQuery – Javascript нового поколения

DMD>Авторы:
DMD> Dmitrii 'Mamut' Dimandt

рассмотренный пример пример ajax с xml-документом не работает:

<html><head><script type="text/javascript" language="JavaScript" src="../jquery.pack.js"></script>
<script type="text/javascript" language="JavaScript">
$(document).ready(function () {
    $('#test').click(function () {
        $.post('ajaxtest2.php', {}, onAjaxSuccess);
        
        function onAjaxSuccess(xml) {
          items = $("item", xml);
          item = $("#1", xml);
          item2 = $("item[@id='2']", xml);
          alert(item2.html());  //undefined, также как и остальные свойства объекта item2
        }
    });
});
</script></head>
<body><form><input type="button" id="test" value="go" /></form></body></html>

ajaxtest2.php:

<?php
  header("Content-Type: text/xml; charset=utf-8");
?>
<list>
  <item id="1">
    Item 1 
  </item>
  <item id="2">
    Item 2 
  </item>
</list>

E>рассмотренный пример пример ajax с xml-документом не работает:

    alert(item2.html());  //undefined, также как и остальные свойства объекта item2

Спасибо за найденную ошибку. Сработает item2.text(). Это, видимо, связано с тем, что полученный xml не является частью DOM загруженного HTML-документа, поэтому у него нет свойства innerHtml

Размышляя о "простоте, изящности и т.д." jQuery хочу задать вопрос знатокам этого фреймворка. Во многих туториалах приводятся самые простейшие примеры, дескать, вот как легко и непринуждённо можно повесить клик на ссылку и т.п. Возьмём ещё более примитивный пример — нужно при загрузке просто показать идиотский алерт: "Превед вам, медведы, от jQuery!". Внимание, очень конкретный вопрос — сколько всего вызовов (всяких разных функций) будет сделано в ходе работы фреймворка, чтобы показать этот алерт?

Z>Размышляя о "простоте, изящности и т.д." jQuery хочу задать вопрос знатокам этого фреймворка. Во многих туториалах приводятся самые простейшие примеры, дескать, вот как легко и непринуждённо можно повесить клик на ссылку и т.п. Возьмём ещё более примитивный пример — нужно при загрузке просто показать идиотский алерт: "Превед вам, медведы, от jQuery!". Внимание, очень конкретный вопрос — сколько всего вызовов (всяких разных функций) будет сделано в ходе работы фреймворка, чтобы показать этот алерт?

Я немножко изменил условия. дело в том, что функция, вызывающая alert(), ждет, пока пользователь не кликнет OK, что сбивает с толку профайлер. То есть, профайлер показывает, что функция очень долго выполняется.

Поэтому http://dmitriid.com/files/rsdn/jquery/preved.html
Специально взята нескомпрессированная версия jQuery 1.1.2 (ага, старенькая)

<html>
    <head>
        <script language="Javascript" type="text/javascript" src="/js/jquery-latest.js"></script>

        <script>
            $(document).ready(
                function() {
                    $(document.body).append('preved');
                }
            );
        </script>
    </head>
    <body>
    </body>
</html>

Профайлер показывает: Profile (6.489ms, 98 calls)
Гигантское время, 6.489 миллисекунды. Это в 52 раза меньше, чем загрузка собственно страницы (и это при том, что 338ms занимала загрузка уже закешированного файла jquery-latest.js и 11ms — собственно html)

Количество вызовов внутри jQuery — это далеко не самая главная проблема в библиотеке

Здравствуйте, Mamut, Вы писали:

M>Профайлер показывает: Profile (6.489ms, 98 calls)
M>Гигантское время, 6.489 миллисекунды. Это в 52 раза меньше, чем загрузка собственно страницы (и это при том, что 338ms занимала загрузка уже закешированного файла jquery-latest.js и 11ms — собственно html)

У меня 139 calls (110 — при загрузке) на jquery-1.1.3.1.js. Дело-то совсем не во времени, а в кажущейся простоте, которую приписывают jQuery. Вот цитата из вашей статьи:

Для начала – решение на чистом Javascript:

var tables = document.getElementsByTagName("table");
for ( var t = 0; t < tables.length; t++ ) {
var rows = tables[t].getElementsByTagName("tr");
for ( var i = 1; i < rows.length; i += 2 )
if ( !/(^|s)odd(s|$)/.test( rows[i].className ) )
rows[i].className += " odd";
}

Ну а теперь – jQuery:

$("tr:nth-child(odd)").addClass("odd");

Как видно из этого примера, библиотека jQuery позволяет находить простые и изящные решения для, казалось бы, сложных задач.

Я, конечно, понимаю, что пример натянут, но вы что, серъёзно считаете, что это корректное сравнение??? За этой 1-ой строчкой стоит полновесный скрипт, создание десятков функций, сто с лишним вызовов при загрузке, ещё с десяток, если не больше вызовов непосредственно при исполнении этой конкретной задачи. Я специально акцентирую внимание на "вызовах" и их количестве, чтобы подчеркнуть теневую активную работу скрипта, да и сам по себе вызов функции — не самое простое, что есть в javascript. В общем, по сравнению с приведённым вами примером "чистого" javascript-a, решение от jQuery намного сложнее, в тени остаётся масса работы (большая часть из которой не имеет вообще никакого отношения к вышеупомянутой задаче)... Я ещё понимаю, когда в плюс библиотекам пишут экономию времени на разработку или минимум кроссбраузерных проблем, но называть это более простым решением — несправедливо по отношению к "чистому" javascript. В результате таких вот "рекламных кампаний в массы о простоте" фреймворки начинают пользовать почём зря, тултипчики показать, раскрасить чего и т.п., то есть там, где 10-20-30 строк понятного кода были бы уже достаточным (идеальным) решением.

Предыдущее сообщение от меня, прошу прощения, разлогинился случайно.

Z>Предыдущее сообщение от меня, прошу прощения, разлогинился случайно.

Хорошо. Начинаем по-новой

Я, конечно, понимаю, что пример натянут, но вы что, серъёзно считаете, что это корректное сравнение??? За этой 1-ой строчкой стоит полновесный скрипт, создание десятков функций, сто с лишним вызовов при загрузке, ещё с десяток, если не больше вызовов непосредственно при исполнении этой конкретной задачи.

Да. Я считаю это корректным сравнением по одной простой причине. Для достижения той же функциональности мне придется написать столько же (если не больше), сколько во всем jQuery, кода ручками, если я хочу получить такую же функциональность.

Потому что jQuery — это фреймворк, который действительно упрощает решение проблем. Ты же не будешь спорить с тем, что $('div.items :nth(odd)') проще, чем 5-10 килобайтов кода, пытающегося достигнуть той же функциональности?

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

Я специально акцентирую внимание на "вызовах" и их количестве, чтобы подчеркнуть теневую активную работу скрипта, да и сам по себе вызов функции — не самое простое, что есть в javascript. В общем, по сравнению с приведённым вами примером "чистого" javascript-a, решение от jQuery намного сложнее, в тени остаётся масса работы (большая часть из которой не имеет вообще никакого отношения к вышеупомянутой задаче)...

Еще раз повторю — вызовы функций — это не самая большая проблема в jQuery. Они занимают хорошо, если 1/10 часть от всего другого на странице.

Насчет "намного сложнее". Попрошу привести мне, например, реализацию следующего кода на чистом JS:

http://codylindley.com/blogstuff/js/jquery/ (пример С)

$("div.contentToChange")  // находим div с class="contentToChange"
    .find("p")            // в этом div находим все p
    .not(".alert")        // которые не имеют class="alert"
    .append(              // добавляем текст
        "<strong class=\"addedtext\"> This text was just appended to this paragraph</strong>"
    )

Потом сравнить с jQuery. Если получится меньше кода, скажите мне, как.

Да, на фоне будут вызовы различных функций. Да, вызовов этих функций будет много. Но. Разве их будет меньше, если мы реализуем то же на "чистом" JS?

В результате таких вот "рекламных кампаний в массы о простоте" фреймворки начинают пользовать почём зря, тултипчики показать, раскрасить чего и т.п., то есть там, где 10-20-30 строк понятного кода были бы уже достаточным (идеальным) решением.

Покажи мне JS для показа тултипа например, вот такого: http://jquery.bassistance.de/tooltip/ Чтобы его можно было так же легко прикреплять к элементам и чтобы он был так же изменяем (см. пример "Two tooltips with extra classes"). Когда напишешь половину jQuery...

M>Да. Для достижения той же функциональности мне придется написать столько же (если не больше), сколько во всем jQuery, кода ручками, если я хочу получить такую же функциональность.

LOL. Кому нужна такая же точно функциональность в полном объёме? Покажи мне всего один сайт, который использует ВСЮ функциональность jQuery разом. А если всё-таки кому-то и нужен гипер-мега-важный-яваскрипт-актив, то тем более стоит писать своё.

M>Потому что jQuery — это фреймворк, который действительно упрощает решение проблем. Ты же не будешь спорить с тем, что $('div.items :nth(odd)') проще, чем 5-10 килобайтов кода, пытающегося достигнуть той же функциональности?

Конечно буду, ты почему-то всё время демонстрируешь какой-то отдельно взятый левый вызов, хитро обзывая это простым кодом. This is передёргивание. Почему не пишешь ниже код всей т.н. фабрики рядом? А весь остальной код, что будет участвовать в решении задачи? Посмотри в профайлере, кто работает и рядышком их, рядышком, это и есть код, который можно справедливо противопоставлять 'чистому' javascript.

M>Еще раз повторю — вызовы функций — это не самая большая проблема в jQuery. Они занимают хорошо, если 1/10 часть от всего другого на странице.

Ну, значит, ещё хуже дела обстоят, чем я думал.

M>Попрошу привести мне, например, реализацию следующего кода на чистом JS
M>Покажи мне JS для показа тултипа

Беспроигрышная позиция — иди, Zeroglif, пиши тултипы и прочее, а я буду сидеть и оценивать, не напишешь — не доказал. Мне недосуг, написался уже выше головы, да и чего тут кодить, если и ёжику понятно, код отдельно взятой задачи всегда будет проще/адекватнее, чем весь код jQuery вместе взятый и прекратите уже, наконец, хитро популизировать jQuery, выдавая вызовы неких функций за весь его код, это вводит в заблуждение ньюбов. Почитал туториалы, "New JavaScript", "magic сhaining", дичь какая-то... Если и сравнивать, так библиотеку против библиотеки, где более-менее равная функциональность, это полезно для профи, делающего выбор. Отдельные же задачи всегда выиграют по всем статьям, или говоря лозунгами — "Чистый javascript рулит!"...

M>Да, вызовов этих функций будет много. Но. Разве их будет меньше, если мы реализуем то же на "чистом" JS?

Взгляни ещё раз на свою статью, где пример раскраски таблицы, что уж может быть проще. Неужели ты никогда не открывал страницы, где типа 2-3-4 красивых фишечки, и вся эта ерундистика стоит аж на prototype.js, это сделали люди, у которых a)нет времени; б)нет знаний; c)нет сил отказаться от лапши, что так проще...

p.s. prototype.js привёл просто как типичный пример бездумного использования популярного фреймворка

Здравствуйте, <Аноним>, Вы писали:

А>У меня 139 calls (110 — при загрузке) на jquery-1.1.3.1.js. Дело-то совсем не во времени, а в кажущейся простоте, которую приписывают jQuery. Вот цитата из вашей статьи:
Налицо терминологическая путаница.
Под простотой обычно понимают простоту применения. Никто не пытался убедить, что jQuery сведет все NP-проблемы к P-проблемам.
Поэтому никакой "кажущести" нет. Простой код — он и есть простой. Простота кода обеспечивает скорость разработки и дешевизну отладки .

Если мы говорим о вычислительной сложности, то оперировать количеством вызовов — бессмысленно. Потому что нас интересуют наблюдаемые характеристики. Простота прикладного кода — одна из таких наблюдаемых характеристик. Ее наблюдает программист, тестер, и менеджер проекта.
Пользователь ничего этого не видит. Впрочем, он не видит и вызовов — все, что он видит — это производительность.
Производительность имеет очень мало общего с количеством вызовов. Она мерится в миллисекундах.

Неужели это неочевидно? Неужели есть иллюзия, что код с одним вызовом, который выполняется 1600ms, чем-то лучше, чем код с 200 вызовами, исполняющийся за 160ms?

... << RSDN@Home 1.2.0 alpha rev. 677>>

M>>Да. Для достижения той же функциональности мне придется написать столько же (если не больше), сколько во всем jQuery, кода ручками, если я хочу получить такую же функциональность.

Z>LOL. Кому нужна такая же точно функциональность в полном объёме? Покажи мне всего один сайт, который использует ВСЮ функциональность jQuery разом. А если всё-таки кому-то и нужен гипер-мега-важный-яваскрипт-актив, то тем более стоит писать своё.

90% функциональности jQuery указана в статье. Мы, например, ее всю используем. За 20KB исходников мы получили невероятно гибкий и удобный в использовании инструмент, покрывающий 100% наших нужд.

M>>Потому что jQuery — это фреймворк, который действительно упрощает решение проблем. Ты же не будешь спорить с тем, что $('div.items :nth(odd)') проще, чем 5-10 килобайтов кода, пытающегося достигнуть той же функциональности?

Z>Конечно буду, ты почему-то всё время демонстрируешь какой-то отдельно взятый левый вызов, хитро обзывая это простым кодом. This is передёргивание.

Ни в коем случае не передергивание. Я описываю фреймворк. С его использованием задачи решаются проще, чем написание того же ручками с нуля.

Z>Почему не пишешь ниже код всей т.н. фабрики рядом? А весь остальной код, что будет участвовать в решении задачи? Посмотри в профайлере, кто работает и рядышком их, рядышком, это и есть код, который можно справедливо противопоставлять 'чистому' javascript.

Зачем? Любой фреймворк — это всегда overhead. Цель люого фреймворка — упростить разработку, спрятав "чистый" код от разработчика. Кому надо, посмотрит в код фреймворка, благо в jQuery его не так уж и много. Заметь, что если ты будешь реализовывать ту же функциональность на чистом JS — то есть настолько же гибкую, легкую и т.п., то все равно ты придешь к тому же, если не большему, количеству кода и вызовов.

Ключевое здесь — гибкое и легкое. ЧТобы не пришлось для каждой отдельной страницы писать тонны кода такого типа:

// jQuery
$('a.ajax');

// аналог
var links = getElementsByTagName('a');
var selectedLinks = [];
for(i = 0; i < links.length; i++)
{
    // split потому что может быть class="ajax links other_class"
    elemClasses = links[i].className.split(/\s+/);
    if(inArray(elemClasses, "ajax") > -1)
    {
        selectedLinks.push(links[i]);
    }
}

// функция взята из jQuery
function inArray(a, и)
{
    for ( var i = 0, al = a.length; i < al; i++ )
        if ( a[i] == b )
            return i;

    return -1;
}

При этом "ручками" мы теряем гибкость. Как только мы добавляем в код гибкость, мы получаем что? Правильно — jQuery, prototype.js, mochikit, dojo или какую иную библиотеку.

Что произойдет, когда "a.ajax" превратится в "#ajax a"?

M>>Еще раз повторю — вызовы функций — это не самая большая проблема в jQuery. Они занимают хорошо, если 1/10 часть от всего другого на странице.
Z>Ну, значит, ещё хуже дела обстоят, чем я думал.

Рассказываю саму большую проблему jQuery. http://dev.jquery.com/~john/speed/

На вырожденных запросах типа $('body > div.dialog div:nth-child(even)') выборка может идти достаточно долго. Хотя на новых версиях в тесте эта выборка длится умопомрачительное время — 34-35 тысячных секунды. Это быстрее, чем мы моргаем (один "морг" — это порядка 200-250 миллисекунд).

M>>Попрошу привести мне, например, реализацию следующего кода на чистом JS
M>>Покажи мне JS для показа тултипа

Z>Беспроигрышная позиция — иди, Zeroglif, пиши тултипы и прочее, а я буду сидеть и оценивать, не напишешь — не доказал. Мне недосуг, написался уже выше головы, да и чего тут кодить, если и ёжику понятно, код отдельно взятой задачи всегда будет проще/адекватнее, чем весь код jQuery вместе взятый

Нет такого понятия, как "отдельно взятая задача". Есть такое понятие, как "отдельно взятый проект". Прикажешь для каждой страницы писатьотдельно ручками с нуля? Это ж сколько кода ты понапишешь? Намного больше, чем 20 килобайт. И намного менее гибкого. И намного менее "reusable" (ключевое слово, кстати).

Тот же tooltip. Я не зря попросил его написать. Потому что изначально было

В результате таких вот "рекламных кампаний в массы о простоте" фреймворки начинают пользовать почём зря, тултипчики показать, раскрасить чего и т.п., то есть там, где 10-20-30 строк понятного кода были бы уже достаточным (идеальным) решением.

Я привел пример тултипа, написанного с помощью jQuery. Пожалуйста, вот "20-30 строчек" с похожей функциональностью: http://www.walterzorn.com/tooltip/tooltip_e.htm 36.8КБ
jQuery + предложенный мной тултип — 29.7КБ. Причем из них 20 — это jQuery, которая помимо помощи в показе тултипа позволяет мне еще много чего.

Z>и прекратите уже, наконец, хитро популизировать jQuery, выдавая вызовы неких функций за весь его код, это вводит в заблуждение ньюбов. Почитал туториалы, "New JavaScript", "magic сhaining", дичь какая-то... Если и сравнивать, так библиотеку против библиотеки, где более-менее равная функциональность, это полезно для профи, делающего выбор. Отдельные же задачи всегда выиграют по всем статьям, или говоря лозунгами — "Чистый javascript рулит!"...

См. выше про тултипы. Рулит не чистый javascript, а библиотеки, позволяющие быстро и эффективно достигать функциональности, которые с помощью чистого JS достижимы с трудом. Особенно для ньюбов.

Покажи мне ньюба, который сможет без подсказки написать приведенный в самом начале аналог $('a.ajax'). Или ньюба, который сможет написать кроссбраузерный Ajax. А если делать его грамотно, то меньше кода, чем здесь особо и не напишешь. Ты готов весь этот код писать сам, ручками? Я — нет. Мне достаточно того, что он есть в jQuery, и я им могу пользоваться.

M>>Да, вызовов этих функций будет много. Но. Разве их будет меньше, если мы реализуем то же на "чистом" JS?

Z>Взгляни ещё раз на свою статью, где пример раскраски таблицы, что уж может быть проще. Неужели ты никогда не открывал страницы, где типа 2-3-4 красивых фишечки, и вся эта ерундистика стоит аж на prototype.js, это сделали люди, у которых a)нет времени; б)нет знаний; c)нет сил отказаться от лапши, что так проще...

Z>p.s. prototype.js привёл просто как типичный пример бездумного использования популярного фреймворка

Ну так это — проблема тех, кто его так использует. Тот же jQuery можно с легкостью использовать на страницах с суммарным объемом (картинки+css+сама страница) от 15-20КБ и выше.

Кстати. Насчет раскраски таблицы. У нас в проекте есть страница, где таблица раскрашивается с помощью jQuery. Знаешь, почему? Потому что jQuery браузером кэшируется и потом сервером не дергается, а для каждого ряда передавать class="even" мы посчитали накладным. Тем более, что у нас не столько раскрашивается, сколько вот: http://dmitriid.com/files/rsdn/jquery/table.html

Почему? ПОтому что jQuery закэшировано, и браузер ее все равно из кэша поднимает. Код на подсветку рядов в таблице занимает 229 вызовов за гигантское время в 14 миллисекунд — все равно быстрее, чем я могу моргнуть.

M>90% функциональности jQuery указана в статье. Мы, например, ее всю используем. За 20KB исходников мы получили невероятно гибкий и удобный в использовании инструмент, покрывающий 100% наших нужд.

Вопрос — если так нужно вовсю использовать javascript в ваших проектах, то где вы тогда потеряли javascript-программиста? Это принципиальная позиция (работать с чужим кодом), или вынужденная (не умеем, нет времени...)? А этими 20-тью KB исходников можно только гвозди забивать, для работы 60 KB будем читати (исходник, кстати, есть с комментами вдоль и поперёк?).

M>>>Потому что jQuery — это фреймворк, который действительно упрощает решение проблем. Ты же не будешь спорить с тем, что $('div.items :nth(odd)') проще, чем 5-10 килобайтов кода, пытающегося достигнуть той же функциональности?

Z>>Конечно буду, ты почему-то всё время демонстрируешь какой-то отдельно взятый левый вызов, хитро обзывая это простым кодом. This is передёргивание.

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

Ну, да, общие фразы... Термины "задачи" и "проще" не раскрыты. Лично мои задачи решаются проще мною же лично, как ты говоришь, ручками. И масса людей со мной солидарны, благо jQuery и проч. пока ещё не захватили мир (не удалось это ни DHTML библиотекам, не выйдет это и у нынешних новомодных). Чтобы я головой отвечал за свою работу на базе чужого фреймворка, я должен знать досконально не только все эти детско-садовские туториалы про нанизывание вызовов и проч., а предназначение каждой из 2345 строк jQuery, что и зачем там делается (потому что это javascript, стеклянные замки на зыбучем песке). К тому же мне нужно оттянуть время на изучение, потом на сопровождение развития всего этого дела, каждый фреймворк развивается и поддерживается по-разному, нужно следить, вычитывать, увольте. Мораль — не всем проще и удобнее с фреймворком.

Z>>Почему не пишешь ниже код всей т.н. фабрики рядом? А весь остальной код, что будет участвовать в решении задачи? Посмотри в профайлере, кто работает и рядышком их, рядышком, это и есть код, который можно справедливо противопоставлять 'чистому' javascript.

M>Зачем? Любой фреймворк — это всегда overhead. Цель люого фреймворка — упростить разработку, спрятав "чистый" код от разработчика. Кому надо, посмотрит в код фреймворка, благо в jQuery его не так уж и много. Заметь, что если ты будешь реализовывать ту же функциональность на чистом JS — то есть настолько же гибкую, легкую и т.п., то все равно ты придешь к тому же, если не большему, количеству кода и вызовов.

Кому надо посмотрит? И чего он там увидит? Если взгляд его будет осмыслен, то какого рожна он не потратил пару-тройку дней, чтобы этот смысл вложить в свой собственный код? Ну, не идеализируй пожалуйста, своего любимца, не такой уж он и гибкий, не такой уж и лёгкий и т.д. Если я буду реализовать такую же функциональность, то я приду совершенно к другому результату, он может быть и хуже, а может и лучше, who knows. Единственное, что меня раздражает в твоём посыле — это то, что jQuery позиционируется, как сгусток идеальных простых решений, дескать, проще уже не бывает. Рискну предположить обратное.

M>Ключевое здесь — гибкое и легкое.
M>При этом "ручками" мы теряем гибкость. Как только мы добавляем в код гибкость, мы получаем что? Правильно — jQuery, prototype.js, mochikit, dojo или какую иную библиотеку.

Неправильно. Если подразумевается re-use, то нормальный программист всегда будет писать в таком ключе, ничего в этом нет революционного, он сделает себе пакет, под себя, без мусора и избыточной функциональности. И то, что он сделает, просто останется вне зоны твоего/моего/мирового внимания, что никак не говорит о том, что этот код хоть чем-то проигрывает в гибкости и т.п. фреймворкам.

Z>>Беспроигрышная позиция — иди, Zeroglif, пиши тултипы и прочее, а я буду сидеть и оценивать, не напишешь — не доказал. Мне недосуг, написался уже выше головы, да и чего тут кодить, если и ёжику понятно, код отдельно взятой задачи всегда будет проще/адекватнее, чем весь код jQuery вместе взятый

M>Нет такого понятия, как "отдельно взятая задача". Есть такое понятие, как "отдельно взятый проект". Прикажешь для каждой страницы писатьотдельно ручками с нуля? Это ж сколько кода ты понапишешь? Намного больше, чем 20 килобайт. И намного менее гибкого. И намного менее "reusable" (ключевое слово, кстати).

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

Z>>и прекратите уже, наконец, хитро популизировать jQuery, выдавая вызовы неких функций за весь его код, это вводит в заблуждение ньюбов. Почитал туториалы, "New JavaScript", "magic сhaining", дичь какая-то... Если и сравнивать, так библиотеку против библиотеки, где более-менее равная функциональность, это полезно для профи, делающего выбор. Отдельные же задачи всегда выиграют по всем статьям, или говоря лозунгами — "Чистый javascript рулит!"...

M>См. выше про тултипы. Рулит не чистый javascript, а библиотеки, позволяющие быстро и эффективно достигать функциональности, которые с помощью чистого JS достижимы с трудом. Особенно для ньюбов.

M>Покажи мне ньюба, который сможет без подсказки написать приведенный в самом начале аналог $('a.ajax'). Или ньюба, который сможет написать кроссбраузерный Ajax. А если делать его грамотно, то меньше кода, чем здесь особо и не напишешь. Ты готов весь этот код писать сам, ручками? Я — нет. Мне достаточно того, что он есть в jQuery, и я им могу пользоваться.

Что же за пренебрежение к ручкам-то? Я готов ко всему, было бы желание. Про "меньше кода не напишешь" повторюсь — сие нам не ведомо.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:

А>>У меня 139 calls (110 — при загрузке) на jquery-1.1.3.1.js. Дело-то совсем не во времени, а в кажущейся простоте, которую приписывают jQuery. Вот цитата из вашей статьи:
S>Налицо терминологическая путаница.
S>Под простотой обычно понимают простоту применения. Никто не пытался убедить, что jQuery сведет все NP-проблемы к P-проблемам.
S>Поэтому никакой "кажущести" нет. Простой код — он и есть простой. Простота кода обеспечивает скорость разработки и дешевизну отладки .

Какая ещё терминологическая путаница, в каком месте код jQuery проще?

S>Если мы говорим о вычислительной сложности, то оперировать количеством вызовов — бессмысленно. Потому что нас интересуют наблюдаемые характеристики. Простота прикладного кода — одна из таких наблюдаемых характеристик. Ее наблюдает программист, тестер, и менеджер проекта.

А мы разве говорили о вычислительной сложности? Мой посыл был продемонстрировать, что за обыкновенным тупым алертом стоит работа многих-многих-многих функций, которые при этом 139!!! раз вызываются. Чтобы обсчитать фреймворк и показать 1 алерт. Налицо сумасшедший контраст между задачей отобразить алерт и работой интерпретатора. И самое смешное, что такие контрастные примеры неоптимальной работы приводят сами популяризаторы фреймворков, вместо того, чтобы в узком профессиональном кругу обсуждать плюсы/минусы и демонстрировать действительно многомерные примеры прикладного использования, идёт рекламная кампания, направленная прежде всего на непрофессиональную часть javascript-сообщества (ньюбов) в стиле "проще-проще-проще" с соответствующими примитивными копипастными примерами.

S>Пользователь ничего этого не видит. Впрочем, он не видит и вызовов — все, что он видит — это производительность.
S>Производительность имеет очень мало общего с количеством вызовов. Она мерится в миллисекундах.

ОК, ещё раз повторю, может кто и услышит — не во времени дело, а в соответствии кода задаче.

S>Неужели это неочевидно? Неужели есть иллюзия, что код с одним вызовом, который выполняется 1600ms, чем-то лучше, чем код с 200 вызовами, исполняющийся за 160ms?

Ой, мама, дорогая, мне нужно было только показать 1 алерт с текстом "Превед вам, медведы, от jQuery?", ты мне советуешь для этого использовать jQuery? А что, подумаешь, куча работы в фоне, зато милисекунды никто не заметит. Извращённое несоответствие кода задаче. По всем статьям: загрузка, излишняя работа интерпретатора, создание сотни объектов, 139 вызовов и проч. Этот пример — квинтэссенция бездумного javascript. C такими примерами нужно бороться, а не пропагандировать похожее примитивное использование библиотек. Так, как пока безуспешно стараются побороть с "bad practice" (eval, with и т.п.) в javascript, пользователь хреновый код без ошибок тоже не заметит, но это ж не отменяет тот факт, что код хреновый. Неужели это неочевидно?

M>>90% функциональности jQuery указана в статье. Мы, например, ее всю используем. За 20KB исходников мы получили невероятно гибкий и удобный в использовании инструмент, покрывающий 100% наших нужд.

Z>Вопрос — если так нужно вовсю использовать javascript в ваших проектах, то где вы тогда потеряли javascript-программиста? Это принципиальная позиция (работать с чужим кодом), или вынужденная (не умеем, нет времени...)? А этими 20-тью KB исходников можно только гвозди забивать, для работы 60 KB будем читати (исходник, кстати, есть с комментами вдоль и поперёк?).

Ну я Javascript-программист. Я увидел, что у мнея появился инструмент, который позволяет мне без геморроя решать огромное количество задач.

Зачем мне читать исходник? Исходник я читал два раза — когда дебагил Ajax + XML (оказалось, проблема не в jQuery, а на серваке была) и когда смотрел, как реализована jQuery.extend.

Рассказываю по порядку. Это истина жизни, странно, что ее не все понимают.

Имеется, например, javascript-программист на зарплате за 1000 баксов в месяц. Нужна функциональность, равная по возможностям хотя бы половине jQuery. За сколько этот программист напишет подобную функциональность? За два месяца? За три? А выявлять ошибки? А тестировать на самых популярных браузерах? Еще, допустим месяц-полтора. Итого 4500 баксов вылетели в трубу.

За эти же 4,5 месяца я с помощью jQuery, используя только два сторонних плагина (datePicker и Taconite) написал всю требуемую мне админ-часть. С Аяксом, кучей интересных (и — главное! — нужных) формочек по сложным правилам и прочая и прочая.

Смотри. Что тебе нужно для любого проекта размером большего, чем домашняя страничка?

Тебе нужен кроссплатформенный Аякс. Гибкий в использовании, чтобы можно было писать:

ajaxPost(
    url,
    {params},
    callback
)

Для реализации этого ты напишешь ненамного меньше кода, чем http://jqueryjs.googlecode.com/svn/trunk/jquery/src/ajax/ajax.js и, возможно, даже больше.

Что еще нужно? Нужна быстрая выборка элементов. getElementById + getElementsByTagName — это неудобно, я показывал это на примере "a.ajax". Что-нибудь хитрее, вроде "#news div.items > h1" — и любой чистый JS в пролете. Как минимум, надо писать общие функции типа http://jqueryjs.googlecode.com/svn/trunk/jquery/src/selector/selector.js (ну или там DomQuery).

Простейшая анимация будет удобной. http://jqueryjs.googlecode.com/svn/trunk/jquery/src/fx/fx.js

И так далее. Если писать свой собственный велосипед, да такой, чтобы он был удобен, гибок, расширяем и так далее, все равно в итоге получаешь свой собственный фреймворк, который не факт, что удобнее/гибче/стабильнее, чем существующие.

Z>>>Конечно буду, ты почему-то всё время демонстрируешь какой-то отдельно взятый левый вызов, хитро обзывая это простым кодом. This is передёргивание.
M>>Ни в коем случае не передергивание. Я описываю фреймворк. С его использованием задачи решаются проще, чем написание того же ручками с нуля.
Z>Ну, да, общие фразы... Термины "задачи" и "проще" не раскрыты.

Реализацию тултипа на jQuery ты мне так и не привел

Ну и поцитирую себя же:

// jQuery
$('a.ajax');

// аналог
var links = getElementsByTagName('a');
var selectedLinks = [];
for(i = 0; i < links.length; i++)
{
    // split потому что может быть class="ajax links other_class"
    elemClasses = links[i].className.split(/\s+/);
    if(inArray(elemClasses, "ajax") > -1)
    {
        selectedLinks.push(links[i]);
    }
}

// функция взята из jQuery
function inArray(a, и)
{
    for ( var i = 0, al = a.length; i < al; i++ )
        if ( a[i] == b )
            return i;

    return -1;
}
При этом "ручками" мы теряем гибкость. Как только мы добавляем в код гибкость, мы получаем что? Правильно — jQuery, prototype.js, mochikit, dojo или какую иную библиотеку.

Что произойдет, когда "a.ajax" превратится в "#ajax a"?

Приведенный пример не надуманный. Что-то вроде "$('a.ajax')" используется у меня на http://dmitriid.com/jquery

Z>Лично мои задачи решаются проще мною же лично, как ты говоришь, ручками. И масса людей со мной солидарны, благо jQuery и проч. пока ещё не захватили мир (не удалось это ни DHTML библиотекам, не выйдет это и у нынешних новомодных).

Не завоевывают именно из-за таких людей, которые готовы тратить уймы времени и писать тонны кода, когда можно в десятки раз увеличить свою производительность

Z>Чтобы я головой отвечал за свою работу на базе чужого фреймворка, я должен знать досконально не только все эти детско-садовские туториалы про нанизывание вызовов и проч., а предназначение каждой из 2345 строк jQuery, что и зачем там делается (потому что это javascript, стеклянные замки на зыбучем песке).

Посмотри на список сайтов, которые пользуются jQuery: http://docs.jquery.com/Sites_Using_jQuery По-моему, это — достаточный аргумент в пользу библиотеки.
Исходников там не так уж и много, их можно наискосок, не вдаваясь в детали, прочитать минут за 15, а то и меньше. Почитай, советую. Потом посмотри на тонны своего собственного кода и задайся вопросом: а почему у меня не так.
Более того, цитирую

Из всего этого следуют Правила большого пальца:
1. Все, что можно купить, нужно покупать (cюда же входит подбор бесплатных компонентов, при их наличии)
2. Все, что нельзя купить, нужно аутсорсить
3. Нельзя аутсорсить "core" — то, за что тебе платят деньги.

Т.е., если ты продаешь программу для бухгалтерии:
1. СУБД, компилятор, визуальные компоненты, инсталлер, хелп вьювер и т.п. — приобретаются
2. Документация, саппорт, скины, кастомные кофигурации — аутсорсятся.
3. Ядро пишется твоей командой высококлассных специалистов, проверяется твоей командой профессионального QA.

Сейчас большинство народу, не принявшего п.1, уже вышли из бизнеса. Сейчас идет освоение п.2.

И это — так. Пока ты на каждый чих пишешь 10-20-30 строк "чистого JS", мы уже написали весь необходимый функционал и продаем свой продукт

Еще советую здесь: http://www.rsdn.ru/Forum/?mid=2027495

Z>К тому же мне нужно оттянуть время на изучение, потом на сопровождение развития всего этого дела, каждый фреймворк развивается и поддерживается по-разному, нужно следить, вычитывать, увольте. Мораль — не всем проще и удобнее с фреймворком.

Знаешь среднее время выучивания jQuery? 2-5 дней

Проверено на 11 людях, включая меня

Учти, что твой код тоже надо учить. Особенно, если ты, напимер, уволишься или перейдешь на другой проект, а твой код кому-то придется сопровождать и/или править.

Более того, фреймворки не меняют по десять раз на дню. Раз выбрав один, разработка обычно продолжается, с использованием именно его. Твой собственный фреймворк и/или набор собственного кода тоже развивается, изменяется и проч. В команде из более, чем одного человека это значит, что кому-то все равно придется следить, вычитывать и проч.

Z>>>Почему не пишешь ниже код всей т.н. фабрики рядом? А весь остальной код, что будет участвовать в решении задачи? Посмотри в профайлере, кто работает и рядышком их, рядышком, это и есть код, который можно справедливо противопоставлять 'чистому' javascript.

M>>Зачем? Любой фреймворк — это всегда overhead. Цель люого фреймворка — упростить разработку, спрятав "чистый" код от разработчика. Кому надо, посмотрит в код фреймворка, благо в jQuery его не так уж и много. Заметь, что если ты будешь реализовывать ту же функциональность на чистом JS — то есть настолько же гибкую, легкую и т.п., то все равно ты придешь к тому же, если не большему, количеству кода и вызовов.

Z>Кому надо посмотрит? И чего он там увидит? Если взгляд его будет осмыслен, то какого рожна он не потратил пару-тройку дней, чтобы этот смысл вложить в свой собственный код?

Ну-ну. Я очнеь хочу посмотреть на того человека, который с нуля ручками за 2-3 дня напишет функционал, равный jQuery. Кстати, я из jQuery уже выдирал куски кода (типа extend, например), для использования в "чистом JS". Ничего, не умер. Во всех остальных случаях, когда надо было использовать хотя бы три-четыре функции, аналогичные jQuery, легче (и оправданнее) использовать jQuery.

Z>Ну, не идеализируй пожалуйста, своего любимца, не такой уж он и гибкий, не такой уж и лёгкий и т.д.

Аргументы, пожалуйста. Мой аргумент вот:

$("a.ajax").click(
    function(){
        $.get(
            $(this).attr("href"),
            {},
            callback
        )
    }
);

function callback(result){
    $("#mydiv").append(result);
}

Этот код понятен даже человеку, который jQuery в глаза не видел. Для того, чтобы написать такой код, надо прочитать статью — и все.
Аналог на JS я уже приводил: http://jqueryjs.googlecode.com/svn/trunk/jquery/src/ajax/ajax.js, функция ajax. Попрошу обратить внимание на такие строчки, как:

// IE likes to send both get and post data, prevent this

// Create the request object; Microsoft failed to properly
// implement the XMLHttpRequest in IE7, so we use the ActiveXObject when it is available

// Set the correct header, if data is being sent
// Set the If-Modified-Since header, if ifModified mode.

и так далее. Ты уверен, что твой код будет все это делать и делать правильно?

Z>Если я буду реализовать такую же функциональность, то я приду совершенно к другому результату, он может быть и хуже, а может и лучше, who knows. Единственное, что меня раздражает в твоём посыле — это то, что jQuery позиционируется, как сгусток идеальных простых решений, дескать, проще уже не бывает. Рискну предположить обратное.

Аргументируй, плиз. На данный момент по соотношению размер/качество jQuery действительно является таковым.

M>>Ключевое здесь — гибкое и легкое.
M>>При этом "ручками" мы теряем гибкость. Как только мы добавляем в код гибкость, мы получаем что? Правильно — jQuery, prototype.js, mochikit, dojo или какую иную библиотеку.

Z>Неправильно. Если подразумевается re-use, то нормальный программист всегда будет писать в таком ключе, ничего в этом нет революционного, он сделает себе пакет, под себя, без мусора и избыточной функциональности. И то, что он сделает, просто останется вне зоны твоего/моего/мирового внимания, что никак не говорит о том, что этот код хоть чем-то проигрывает в гибкости и т.п. фреймворкам.

Правильно. И нанаписание и отладку такого кода у него уйдет сколько? Месяц? Два? А работать в это время кто будет?

M>>Нет такого понятия, как "отдельно взятая задача". Есть такое понятие, как "отдельно взятый проект". Прикажешь для каждой страницы писатьотдельно ручками с нуля? Это ж сколько кода ты понапишешь? Намного больше, чем 20 килобайт. И намного менее гибкого. И намного менее "reusable" (ключевое слово, кстати).

Z>Дружище, я же тебя не уговариваю писать код, завязанный на страницу, смешно право. У каждого, кто пишет много на javascript-е, есть свой собственный типа-фреймворк, он может быть в виде проверенных сниппетов, в виде алгоритмов внутри головы, в виде библиотеки и т.п. Вот где гибкость, взял, что нужно и используешь, и будет этого кода точно меньше, и будешь ты его точно знать, и не будешь лишний раз учить язык фреймворков, и не будешь рабом чужих кривых идей и т.д. и т.п.

Так вот. jQuery — это точно такой же "типа-фреймворк". Только его предложили использовать не только внутри отдельно взятой компании, а всему миру. Это — плохо? Учитывая, что этот фреймворк — компактный и быстрый.

M>>Покажи мне ньюба, который сможет без подсказки написать приведенный в самом начале аналог $('a.ajax'). Или ньюба, который сможет написать кроссбраузерный Ajax. А если делать его грамотно, то меньше кода, чем здесь особо и не напишешь. Ты готов весь этот код писать сам, ручками? Я — нет. Мне достаточно того, что он есть в jQuery, и я им могу пользоваться.

Z>Что же за пренебрежение к ручкам-то? Я готов ко всему, было бы желание. Про "меньше кода не напишешь" повторюсь — сие нам не ведомо.

А у тебя что за пренебрежение к фреймворкам? :

Лично мои задачи решаются проще мною же лично, как ты говоришь, ручками. И масса людей со мной солидарны, благо jQuery и проч. пока ещё не захватили мир (не удалось это ни DHTML библиотекам, не выйдет это и у нынешних новомодных)

Чем твой собственный фреймворк лучше, чем jQuery? Я тебе сразу скажу, чем он хуже:
— У тебя нет возможности протестировать его на всех комбинациях популярных браузераов
— У тебя нет возможности проводить интенсивное выявление ошибок: http://dev.jquery.com/report/16, потому что у тебя просто нет такого количества пользователей (например, у тебя есть закрытый баг репорт типа такого: http://dev.jquery.com/ticket/1341

). Под пользователями я имею в виду не посетителей сайта, а разработчиков, использующих твой код.
— У тебя нет возможности привлечь к разработке других разработчиков: http://groups.google.com/group/jquery-dev

Чувствую, что что-то еще упустил.

ЗЫ. Разработчики всегда будут пользоваться сторонними библиотеками. Потому что это повышает производительность. Потому что обычно нет времени на разработку аналогичного функционала. Потому что проекты надо здавать завтра, а не через полгода. Потому что велосипеды интересно писать, когда только изучаешь технологию, потом велосипеды просто не оправдывают себя.

	От:	ionicman
	Дата:	30.07.07 04:48
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	30.07.07 05:32
Оценка:

	От:	ionicman
	Дата:	30.07.07 06:07
	Оценка:

От:	Mamut	http://dmitriid.com
Дата:	30.07.07 08:27
Оценка:

	От:	.
	Дата:	30.07.07 09:01
	Оценка:

	От:	explode
	Дата:	06.08.07 13:57
	Оценка:	34 (1)

	От:	Zeroglif
	Дата:	07.08.07 14:23
	Оценка:

	От:	Аноним
	Дата:	08.08.07 09:30
	Оценка:

	От:	Zeroglif
	Дата:	08.08.07 09:33
	Оценка: