Там обсуждается не авторитетность Jquery, а его (и не только его) необходимость. Хочешь похоливарить на эту тему?
Тогда без меня.

"jQuery - либа, которая почти 3 года определяла браузер по UA-строчке, это супер-мега-кросс-браузерно..."
"Ну, да... косяков полно до сих пор..."
http://groups.google.ru/group/comp.l...cb11852d7ca75c
p.s. не собирался я холиварить, просто сказал, что ее авторитетность сомнительна

И сомнительно то, что плагины на ней работают заметно быстрей чем на PrototypeJs?

Я читаю предельно внимательно. Вы понимаете, что такое innerHTML? ;)

Есть оптимизация, а есть ошибки логики.

innerHTML в отличии от nodeValue, innerText и createTextNode не экранирует теги и в данном случае это важно.

Очень хочется увидеть ваш вариант без ошибок.

Вероятно, вы хотите видеть это:

var TextNode = {
	each: function(callback, parent) {
		for (var childNodes = (parent || document.body).childNodes, i = 0; i < childNodes.length; i++) {
			var I = childNodes[i];
			I.nodeType == 1
				? arguments.callee(callback, I)
				: I.nodeType == 3 && callback(I, i);
		}
	}
};

window.onload = function() {
	TextNode.each(function(noda) {
		var v = noda.nodeValue.replace(/(http\:\/\/www\.youtube\.com\/watch\?v\=[0-9a-z]{11})/gi, '<a href="$1">$1</a>');
		if (v != noda.nodeValue) {
			var div = document.createElement('div');
			div.innerHTML = v;
			if (div.firstChild) {
				var f = document.createDocumentFragment();
				do f.appendChild(div.firstChild);
				while (div.firstChild);
				noda.parentNode.replaceChild(f, noda);
			}
		}
	});
};

Свойство 'innerHTML' стандартизировано? Нет. Согласно спекам MS (как пример) это свойство "sets or retrieves the HTML between the start and end tags of the object", никаких точных деталей о представлении. Сначала вы приводите НЕИЗВЕСТНУЮ строку в контент, браузер по своим законам парсит её, форматирует и т.д., затем делаете обратное действие, которое точно также зависит от представления браузера(ом). Почему вы решили, что в этом случае можно гарантировать равенство неизвестных вам заранее строк (innerHTML==nodeValue/data)? Ради интереса попробуйте добавить в текст что-нибудь вроде <p&gt... ;)

Тем более жутко, что нет вообще никакой необходимости replace-ить все текстовые ноды без разбора (на кой ляд это делается?), создавать для каждой ноды элемент, изменять его контент через innerHTML, потом "проверять".

Так я увижу ваш вариант или нет? Может и правда есть какой-то более простой способ.

И во всю применяется во всех известных фреймворках:
prototype-1.6.0.3, uncompressed версия, стр. 411, метод String.prototype.unescapeHTML
Подобная ситуация решена тем же способом.

Думаете, разработчик PrototypeJs плохо ее протестировал?
Тогда яркий пример: стр. 1022, метод get класса Hash. Чувак до сих пор беспокоится о возможности отсутствия метода hasOwnProperty, хотя все адекватные яваскриптеры уже забыли давно об этом. Неужели вы думаете, что при этом он вдруг внезапно забыл качественно протестировать innerHTML. К тому же метод String.prototype.unescapeHTML уже не раз менялся, и каждый раз причиной указывалась кроссбраузерность.

Вы думаете, что разработчики, какого ни будь браузера, вдруг реализуют его (innerHTML) работу по-своему? Ну, если только они задумают его (браузер) утопить.

Беспокоитесь о кустарном браузере, изобретенном студентом Васей? Не забудьте еще о IE5.5, netscape, и Петя еще что-то изобретает.

Впервые слышу. Если бы это было так, то об этом трубили бы на каждом углу.
w3c много, что перенял из стандарта ms.
Я тоже обеими руками за соблюдение стандартов, но в данном случае, даже если это так, то я сделаю исключение.

Попробовал. Все норм.

Кто ж против применения. В вашем конкретном случае равенство строк не гарантировано. Неужели так сложно проверить? Чего будет на странице до и чего после:

text 
<p&gt
alone

http://msdn.microsoft.com/en-us/library/ms533897.aspx
https://developer.mozilla.org/En/DOM/Element.innerHTML

Ну, прям, норм. Ага.

А я уж подумал, что вы против.


Я еще раз проверил в разных браузерах. Я очень всматривался пытаясь увидеть разницу. И ее нет.
Вероятно вы используете старый вариант. Я же приводил исправленный вариант уже:

var TextNode = {
	each: function(callback, parent) {
		for (var childNodes = (parent || document.body).childNodes, i = 0; i < childNodes.length; i++) {
			var I = childNodes[i];
			I.nodeType == 1
				? arguments.callee(callback, I)
				: I.nodeType == 3 && callback(I, i);
		}
	}
};

window.onload = function() {
	TextNode.each(function(noda) {
		var v = noda.nodeValue.replace(/(http\:\/\/www\.youtube\.com\/watch\?v\=[0-9a-z]{11})/gi, '<a href="$1">$1</a>');
		if (v != noda.nodeValue) {
			var div = document.createElement('div');
			div.innerHTML = v;
			if (div.firstChild) {
				var f = document.createDocumentFragment();
				do f.appendChild(div.firstChild);
				while (div.firstChild);
				noda.parentNode.replaceChild(f, noda);
			}
		}
	});
};

Riim,

Можно один раз объявить, и записать свойством в функцию-коллбэк, иначе, они создаются каждый раз при вызове callback(I, i);.

Если не хотите приводить свой код, то хоть объясните подробней, как вы предполагаете это сделать, а я уж сам сделаю.

А стоит так мучиться для одноразового кода. Разве, что ради идеи:

window.onload = function() {
	var callback = function(noda) {
		var v = noda.nodeValue.replace(/(http\:\/\/www\.youtube\.com\/watch\?v\=[0-9a-z]{11})/gi, '<a href="$1">$1</a>');
		if (v != noda.nodeValue) {
			var div = arguments.callee.div;
			div.innerHTML = v;
			if (div.firstChild) {
				var f = arguments.callee.fragment;
				do f.appendChild(div.firstChild);
				while (div.firstChild);
				noda.parentNode.replaceChild(f, noda);
			}
		}
	};
	callback.div = document.createElement('div');
	callback.fragment = document.createDocumentFragment();
	TextNode.each(callback);
};

Странно, что после строки "var f = arguments.callee.fragment;" не нужно отчищать этот самый фрагмент. Видимо после добавления в документ он сам очищается.

Riim, речь шла о сравнении innerHTML с nodeValue

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>blank</title>
    <script type="text/javascript">
var TextNode = {
    each: function(callback, parent) {
        for (var childNodes = (parent || document.body).childNodes, i = 0; i < childNodes.length; i++) {
            var I = childNodes[i];
            I.nodeType == 1
                ? arguments.callee(callback, I)
                : I.nodeType == 3 && callback(I, i);
        }
    }
};
 
window.onload = function() {
    TextNode.each(function(noda) {
        var div = document.createElement('div');
        div.innerHTML = noda.nodeValue.replace(/(http\:\/\/www\.youtube\.com\/watch\?v\=[0-9a-z]{11})/gi, '<a href="$1">$1</a>');
        if (div.firstChild && div.innerHTML != noda.nodeValue) {
            var f = document.createDocumentFragment();
            do f.appendChild(div.firstChild);
            while (div.firstChild);
            noda.parentNode.replaceChild(f, noda);
        }
    });
};
    </script>
</head>
<body>
 
text 
&lt;p&gt
alone
 
</body>
</html>

так ты определись, что мы обсуждаем. А то сначала ты говоришь про экономию операторов, а потом, что это одно разовый код. Давай тогда представим, что это супер-мега-быстрый фреймворк. Это твой окончательный вариант?
p.s. кто-нибудь может что-то сказать про экономию операторов, кроме Riim, он уже вроде высказался по этому поводу

Ну вы ж тут, вроде, об оптимизации беседуете (хотя, весь топик я не читал)? Поэтому, лучше один раз "помучиться", чем на каждый вызов.

У вас есть признак ноды, которая нужна (некий текст), проверяйте наличие этого текста и меняйте при наличии.

Вары через запятую - это нормально, много варов внутри 'for' - необычно, глаз не радует, строку удлиняет, обычно задают не больше двух. Объявление переменной внутри цикла - бессмысленная вешь, провоцирующая ньюбов на лишние вопросы. Условный оператор обязан быть читабелен среди профи (в меру простой, конечно), ничего не имею против, но чаще всего не читабелен для других. Кроме того, с ним не очень приятно дорабатывать код, расширяя список выражений. С логическими операторами картина та же, в отсутствии присваивания они теряют в читабельности, к тому же есть пуристы, которые используют их только в логическом контексте. Конструкция 'do-while' в примере может и была бы правильным выбором, если бы так нужно было проверять 'div.firstChild', а это не нужно, как и 'innerHTML' и проч.

Zeroglif, а с производительностью это как-то связано? Или вопрос стиля?

Это больше вопрос стиля, читабельности, удобства, краткости записи. О скорости можно рассуждать только с тестами в руках. Я не вижу иных причин отказываться от той же 'if-else' кроме как из-за экономии букв...

Я уже давно понял и написал исправленный вариант. Посты № 47 и 51.

Я так и думал, что вы про это. Если проверять БЕЗ regexp-а, то почему бы и нет.

Экономил операторы я в TextNode.each, а это уже НЕ одноразовый код.
Я давно определился и уже объяснял как именно.
Я говорю про:
1) производительность
2) объем кода
3) логичность кода
4) читабельность
Приоритеты меняются в зависимости от кода.
В TextNode.each на первом месте производительность (универсальный код).
В window.onload объем кода (одноразовый код).
Читабельность всегда на последнем.

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

Оптимизация одного часто делается в ущерб остальному. Вопрос в том, насколько эффективна эта оптимизация, и каков ущерб.
Дмитрий предложил вариант оптимизации производительности в ущерб объему кода. Ущерб слишком большой, а выигрыш в скорости мизерный (теоретически, не тестировал). Вариант предложенный Zeroglif (с проверкой до regexp-а), даст заметно большее увеличение производительности и меньший ущерб. Вполне приемлемый вариант.

Во всех случаях выше, где я отходил от своих приоритетов, я пояснял, почему это делаю.
В случае с предложенным Дмитрием вариантом, я пояснил, что делаю это просто что бы попробовать идею.
Надеюсь, что на этот раз я все достаточно подробно изложил, и вопросов на счет моих приоритетов больше не будет.

Я не хочу (без обид) вообще ни чего слышать про читабельность (в универсальном коде) в ущерб даже плюс одному байту кода после компрессора или плюс одному лишнему действию интерпретатора. Мой стиль не формируется, он уже сформирован, и до javascript2.0 я менять себя не собираюсь.


Как не нужно? Как же цикл тогда остановится?

Вы используете 'if' плюс 'do-while', если уйти от 'if', который не нужен вообще, то достаточно 'while'. Остановка цикла не при чём.

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

Логика ясна, но у вас же есть границы? Иначе, зачем создавать объект 'TextNode', зачем такие длинные названия, зачем так много 'var'-ов, ведь это много лишних байтов. ;)

Все локальные переменные компрессор сожмет до одного символа:
http://developer.yahoo.com/yui/compressor/
Про них можно не беспокоиться.

Что касается глобальных, то вы, верно, сказали "есть границы". Можно не создавать объекты и все переменные держать в window с именами "a", "b", "c", "d" и т. д. Хорошая помойка получится. Пожалуй, я действительно поспешил так однозначно заявив:
Что бы ни допустить такой помойки все же приходится мириться с незначительным увеличением объема кода и уменьшением производительности (за счет обращения к свойствам объектов).
Все эти методы с правильными именами, красиво разложенные по полочкам (по объектам) будут постоянно применяться, и это применение должно быть удобным. Но должно ли быть удобно (читабельно) написано содержимое этих методов? То есть я сначала пишу функцию читабельно в ущерб производительности, для того что бы потом, когда этот внесенный мной ущерб проявится, я мог зайти, удобно ее прочитать и исправить сделав нечитабельной. Глупо на мой взгляд.

Лишних 'var'-ов на первый взгляд вроде не вижу. Каждый в своем уровне вложенности. Можно, например, вынести "f" выше к "div", но тогда DocumentFragment будет создаваться и в тех случаях, когда он не понадобится.

Кстати, потестируйте. Теоретически, это уже будет быстрее в n раз. А если ещё учесть тормознутость каждой конкретной реализации .createElement и .createDocumentFragment - ещё прибавится. Хотя, Вам решать, что оптимизировать - скорость или объём кода, я лишь предложил.

Теоретически, процентов 10 максимум. Сейчас протестирую.

Протестировал на "идеальном" случае, т. е. кол-во текстовых узлов в документе равно кол-ву подходящих для замены текстовых узлов. В таком случае разница в производительности особенно заметна.

Код срабатывает множество раз, и каждый раз в документе появляются теги "а", которые сразу нужно убирать:

var text = 'ddffdfg [url]http://www.youtube.com/watch?v=iuOcLoqo5e0[/url] dsfsdfs';
var startTime = new Date();
for (var __i = 0; __i < 1001; __i++) {
	document.getElementById('div1').innerHTML =
	document.getElementById('div2').innerHTML =
	document.getElementById('div3').innerHTML = text;
	TextNode.each(callback);
}
alert((new Date()) - startTime);

Результат:
IE +8.59%
FF +6.49%
Opera +10.56%
Chrome +13.04%

В среднем +9,67%

В реальном документе сотни, а часто и тысячи текстовых узлов (отступы/табы для форматирования html в большинстве браузеров тоже считаются текстовыми узлами), и максимум 5-10 подходящих, т. е. полученный результат можно смело делить минимум на сотню.

Получаем +0,0967%

Можно еще regexp вынести как свойство callback-а. Чтоб не создавался каждый раз.

Почти 100%.

У меня интерес всегда академический. Отрицать/не принимать очевидное - какой смысл? Есть разница - каждый раз создавать или один раз?

function test(callback) {
  callback();
}
var t1, t2;
function _callback1() {
  var div = document.createElement('div');
  var fragment = document.createDocumentFragment();
  var _div = div;
  var _fragment = fragment;
}
t1 = new Date().getTime();
for (var k = 0; k < 100000; k++) {
  test(_callback1);
}
t2 = new Date().getTime();
alert(t2 - t1);

function _callback2() {
  var _div = arguments.callee.div;
  var _fragment = arguments.callee.fragment;
}
_callback2.div = document.createElement('div');
_callback2.fragment = document.createDocumentFragment();
t1 = new Date().getTime();
for (var k = 0; k < 100000; k++) {
  test(_callback2);
}
t2 = new Date().getTime();
alert(t2 - t1);

Минимум в два раза быстрее (а где-то (IE6 на моей машине) в 5-8 раз).

Впрочем, повторю, Вы сами определяете приоритет.

Вы сравниваете обращение к свойству и вызов метода. Конечно второе медленней даже если метод пустой.
Т. е. вы удалили весь лишний шум. Но при реальном применении, этот шум будет, и его нужно учитывать.
Определитесь, что мы сравниваем два по разному написанных метода или "обращение к свойству" vs "вызов метода".

Riim, стоп. У вас операция document.createElement('div'); сколько раз вызывается? Один?

Не понял. И там - test(_callback1), и там - test(_callback2) - вызов test с своим коллбэком.

Первый коллбэк (Ваш, где Вы создаёте каждый раз div и fragment):

function _callback1() {
  var div = document.createElement('div');
  var fragment = document.createDocumentFragment();
  var _div = div;
  var _fragment = fragment;
}

Второй коллбэк (предложенный, где div и fragment создались единожды и записались свойствами в коллбэк):

function _callback2() {
  var _div = arguments.callee.div;
  var _fragment = arguments.callee.fragment;
}
_callback2.div = document.createElement('div');
_callback2.fragment = document.createDocumentFragment();

Какой ещё шум? До шума, действительно, и дела нет. Я Вам предложил заменить постоянное создание div и fragment на один раз. Другого я не касался.

О чём Вы продолжаете говорить (и отрицать?), я не понимаю? =) Какой вызов метода, какое свойство? Если Вы под "вызов метода" подразумеваете document.createElement('div'); и document.createDocumentFragment(); vs. arguments.callee.div; и arguments.callee.fragment; - так я Вам это и предложил.

P.S.: ещё раз - у Вас document.createElement('div'); и document.createDocumentFragment(); один раз вызываются? Нет? А почему? А! Вы говорите об оптимизации по объёму кода; что ж, Вам решать (я это третий раз говорю уже).

Нет не один. Я что-то говорил про один?

А внутри-то callback-ов что? Что мы сравниваем? Имена callback-ов что ли?

Шум - лишний код, который повторяется в обоих сравниваемых случаях. Можно удалить (раз уж он одинаков) что бы лучше разглядеть разницу. Но это не значит, что его производительность не следует учитывать в конечных вариантах (а именно их я сравниваю). Иначе получалось бы, что раз _callback2 работает в 5 раз быстрей, то и весь сайт заработает в 5 раз быстрей. Но это не так.

Именно это я и подразумеваю. Вы просто не хотите понять, что вы сравниваете работу этих кусков отдельно от остального кода, как, будто они сами по себе, я же смотрю на их работу в контексте реальной функции, которая обрабатывает реальный html. По комментарию №66 это можно было бы понять.

Изначально производительность рассматривалась на примере реальной функции. Вы же, не предупредив меня, начали рассматривать ее куски (arguments.callee.div, document.createElement('div'), ....) отдельно от нее самой. И пытаетесь еще из меня дурака лепить. Не надо этого делать.

Я реально не понимаю, какой смысл твердить "чёрное", когда видно, что "белое"?

Что за бессмысленная демагогия?

В этом конкретном месте Вашего большого кода - в 5 раз быстрее. Разве это хуже? Кто (?) может это отрицать? А самое главное - зачем? :)

Слушайте, не тратьте моё время, пожалуйста. Мне кажется, я очевидные вещи говорю. В это Вашей фразе нам надо поменяться местами. Вот объясните мне только одну вещь - как (как? реально, как? :) я это не могу осознать) можно продолжать говорить "чёрное", когда видно, что "белое"? Какой в этом смысл? Вы мне хотите что-то доказать? Или, может, не мне, а себе? Что именно?

Ойй... Только не надо демагогии, а? Иначе, я позволю себе не утруждаться с ответами.

Это вы про что?

Я хотел обратить внимание на содержимое этих callback-ов.

Вот именно. Я рад, что вы научились отличать "конкретное место" от "большого кода".

Так я и не спорю, что, по вашему способу тестирования, прирост производительности 100% и более. Это действительно так.
Я уже даже не пытаюсь доказать, что мой способ правильней. Просто создается ощущение, что вы до сих пор не осознали, что я тестирую Д-Р-У-Г-И-М способом. И именно поэтому результат у меня другой.

Давайте по хронологии:

Пост №66:
Мой способ тестирования становится очевидным, и я привожу результат тестирования.

Пост №68:
Вы приводите свой способ тестирования и пишите:
То есть оспариваете мой результат только лишь по тому, что он отличается от вашего.
Если бы вы понимали, что он отличается из-за того, что получен другим способом, вы бы и не пытались его оспорить. Вы бы оспаривали способ его получения.
Дальше я делаю логичный вывод, что вы еще не в курсе, что способ тестирования у меня другой, и пытаюсь вам это объяснить.

----

В общем, я как мог, попытался прояснить ситуацию. Надеюсь, вы меня услышите.
И еще раз (на всякий): я не спорю, что по вашему способу тестирования прирост производительности 100% и более.

Сбитая логика ;)

Ну, и славно. "Мой способ тестирования" - это часть Вашего кода. Если эта часть будет работать быстрее - код будет работать быстрее? Ну, вот и замечательно. Успехов!

Извините, я оставляю Вас наедине относительно этого топика. Смысл уже минусовой (даже не нулевой) мне что-то рассказывать в этом моменте.

Ну может немного и сбитая. Главное, что похоже вы меня услышали, чему я очень рад.

Согласен. Необходимости в продолжении дискуссии нет. Вроде все выяснили.
Вам также успехов.

ну я так вижу, Riim, смотрит на это дело с точки зрения функции на конкретной страничке, а Dmitry A. Soshnikov - этот момент можно оптимизировать? Он будет выполняться быстрее? Это особо ничего не усложнит - супер. Отсюда разные способы тестирования
Думаю, Riim в данном случае жертвует производительностью ради меньшего объема кода. Но мне не понятны критерии, как выбирать между производительностью и объемом кода :blink:

x-yuri,
да не начинай ты опять. И так кое-как разошлись.


пост №59

ты просто не рассказал, как сравнивать производительность с объемом кода. Как между ними выбирать? А в остальном твоя позиция ясна. Я же предпочитаю решать проблемы по мере возникновения или знать, зачем что-то делать
p.s. ты слишком серьзно относишься к общению на форуме, имхо ;-)

Ну, вот я писал:
и вот еще:
т. е. для начала следует оценить универсальность кода и если окажется, что он много где может оказаться полезен, то пусть он будет побыстрее, поскольку однажды он окажется полезен в месте требовательном к производительности.

Еще много, что можно учитывать, например, обработчики событий onmousemove и onscroll в любом случае лучше оптимизировать на производительность, т. к. они могут срабатывать очень часто. Тоже касается анимации.

Парни , спасибо за такое живое обсуждение моего вопроса. Прочитал всё , многое не понял :) .
Так всё-таки можно привести хотя бы 2 варианта кода .
Меня меньше интересует размер файла , больше интересует его производительность .
Так же видел в коде windows.onload , моих знаний не так много и наверно я чето не понимаю , но с этим бывают проблемы.
И если возможно ,то код который бы работал с библиотекой jQuery .
И большое спасибо всем кто участвовал в обсуждении этого вопроса.

P.S. Так же хотел спросить насколько просто/сложно , будет изменить код ,если потребуется искать не только по YouTube , но и по Google video и по другим видео....