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

I>>эээ ребяты.... а зачем это все? расскажите? ну мне просто интересно нахрена уменьшать скорость и так медленного js? или вы хотите сказать что синтаксис этой библиотеки проще чем стандартный? не, действительно реально ктото это использует и оно ему удобно?

M>Я это реально пользую и это мне реально удобно.
очень может быть. я по этому и написал чтобы выяснить кто и зачем пользуется.

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

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

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

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

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

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

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


M>Что такое jQuery? Это невероятно маленький (последняя версия — 20KB в сжатом виде) и один из самых быстрых доступных JS-фреймворков. То есть jQuery предлагает набор функций, облегчающих жизнь программисту.


M>Этот пример показывает некоторые проблемы, которые на голом JS решаются неудобно:
M>

M>// находим все элементы с классом ex и присваиваем им onclick
M>$(".ex").click(...

M>// аналог
M>var a = getElementsByTagName("a");
M>for(i = 0; i < a.length; i++)
M>{
M>    if(a.className == "ex")
M>    {
M>        a.onclick = ...
M>    }
M>}
M>

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

 function GetElementByProp( o, prop, propval ) {
  GetElementByProp.GEBarr = [];
  GetElementByProp.GEBprop = prop;
  GetElementByProp.GEBpropval = null;
  return GetElementByProp.internal( o )
 }

 function GetElementByProp.internal( o ) {
  if ( o.getAttribute && o.getAttribute( GEBprop ) == GEBpropval ) GetElementByProp.GEBarr.push( o );
  o = o.firstChild;
  while ( o != null ) {
   GetElementByProp.internal( o );
   o = o.nextSibling;
  }
 }

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

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

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

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

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

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

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