Я не улавливаю разницы...
 

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

Приведу пример:

<ul>
<li class="style">Элемент списка 1</li>
<li class="style">Второй элемент</li>
<li class="style">Элемент номер три</li>
<li class="style">Ещё какая-то ерунда</li>
<li class="style">Бред сивой кобылы</li>
<li class="style">И всякая хрень</li>
</ul>

Это ерунда, если список такой, но зачастую элементов во много больше.
Почему не использовать такой подход:

<script>
var ul=["Элемент списка 1","Второй элемент","Элемент номер три","Ещё какая-то ерунда","Бред сивой кобылы","И всякая хрень"];
someDiv.innerHTML="<ul><li class='style'>"+ul.join("</li><li class='style'>")+"</li></ul>";
</script>

Я вижу только плюсы в js варианте - при длинном списке объём данных получится значительно меньше, упрощение работы с тэгами и их атрибутами, динамическое изменение списка и т.п.
Полагаю, продвинутые конторы по вэб разработкам не будут заниматься ерундой и прибегнут к оптимальному решению.
Почему же первый пример - без js используют в большинстве? Чем он превосходит js?
В чём заключается разница?

ну мне например на PHP куда проще сделать так:

<ul><?php echo '<li class="style">'.implode( '</li><li class="style">', $textList ).'</li>';?></ul>

чем делать так, где писанины больше:

<script>
var ul=["<?php echo implode( '", "', $textList );?>"];
someDiv.innerHTML="<ul><li class="style">"+ul.join("</li><li class="style">")+"</li></ul>";
</script>

И это не единственная причина

Думаю для лучшей индексации в поисковиках

Согласен, я тоже раньше так делал. Но это увеличивает трафик, а так же нагружает апач->пхп больше, чем с вариантом js. При большом количестве обращений к странице с использованием js, а не пхп в данном случае, сервер без тормозов выдержит гораздо больше одновременных запросов.
Какие же реальные существуют причины, основанные не на лени, а на технической особенности?

да это одна из важных причин

Согласен, но я буду удивлён, что только это и есть основная причина.

А если js отключен?

Если он отключен, те же сайты работать и не будут, т.к. используют js, но для других целей.

да одна простая причина, чистый HTML отделенный от JavaScript говорит о том что его писал нормальный программист, а не говнокодер, и такой код после этого программиста куда приятнее дописывать/дебажить, чем код в котором мешанина скриптов и тегов в одном. Лично я плююсь от таких сайтов написанных говнокодерами.

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

<ul><?php echo '<li class="style">'.implode( '</li><li class="style">', $textList ).'</li>';?></ul>

По смешиванию это напоминает js. Если это тоже творится говнокодерами, тогда сочувствую - ты написал о самом себе.

Браузеры работают с js, css, html... по сути это разные вещи, но объединены в браузере. Не с проста, наверно, как думаешь?

ахахх... насмешил... если тебя послушать, то вообще какой смысл ты вообще поднял эту тему. Если ты считаешь что нужно освободить сервак от нагрузки, то шаблонная система на темплейтах поверь нагружает сервер куда сильнее, нежели HTML с частичным внедрением PHP ( заметь с частичным, и только с уже подготовленными данными ). Вот если в PHP смешивают весь код, это говнокодерство, если же в PHP генерируют данные, делают запросы в БД и т.п. в отдельном файле а вывод в другом ( даже с частичным использованием PHP ) Это не считается говнокодерством.

Да нет тут ни одного плюса, каждая технология нужна для своих целей, как уже написали это чистейшей воды говнокод, я подобным образом заглушки для 6-7 ослов пихаю в условных коментариях скрипт который уже всё сделает.

1) В такой ситуации должна происходить деградация интерфейса, а не полная его недоступность - фейл.
2) Пихать js в представление без веской на то необходимости - фейл.
3) Меню создается отдельно от контейнера, ОЧЕНЬ неочевидная ситуация - фейл.
4) Меню создается по подгрузке DOM-дерева (если создание меню вынесено в отдельный файл, а не следом за контейнером идет), если позникли проблемы с сетью и браузер никак не может получить часть страницы, меню тоже будет недоступно - фейл.
Если подумать, можно нарыть еще кучу причин так не делать.

я не думаю, что AJAX является такой уж необходимой технологией.:yes:

его можно выводить через document.write
насчёт вывода - внизу.
вся страница будет недоступна

а мне нравится, когда так делают. единственное, это надо делать правильно.

1 отключенный js - решается киданием этого маленького процента на другую версию сайта, предназначенную для поисковиков. (да, это попахивает клоакингом, но можно что-нибудь придумать)
2 если использовать HTMLElement.appendChild и async=true, то это увеличит скорость загрузки страницы.
3 уменьшение нагрузки на сервер, т.к. вывод массивов из БД переводится на пользователя.
4 увеличение доли JS в разработке и в работе сайта. или же JS только для анимация и ajax используется до сих пор ???
5 зачем придуманы шаблонизаторы на JS ? только не говорите, что just for fun.

Хорошая идея!
Да, и в целом, отличный пост! )
Достаточно часто на сайтах встречается подключение jquery, при чём в полноразмерном виде, что более 100кб. Если на своём сайте использовать свою библиотеку размером 10кб и упрощённый вариант - переадрессацию для поисковиков и браузеров с отключенным js, демается мне, должно получиться практичнее.
--------------

И вновь ставлю вопрос, но уже чуть иначе:
Какая действительно веская причина может служить для использования разметки взамен работы js (уже не учитывая поисковиков)?

Как люди всё-таки не любят критику и любят нравиться)

melky,
Шаблонизация на js требуется в первую очередь на проектах с высокой долей ajax-запросов для отделения бизнес-логики от представления.
Так значит, вывести меню это веская причина чтобы пихать js в представление?
Нет. Та часть, что уже получена и срендерена будет доступна.
Вообще что-то пасмурное, вывод из БД вы в любом случае будете делать на сервере, в чем экономия то?!
Это уже напоминает ситуацию "у меня в руках молоток, все кругом похоже на гвоздь". Меню это часть представления, зачем в представлении логика на ровном месте, а склеивание меню из массива это уже логика, зачем усложнять и делать не очевидные вещи?! Да еще делать вид, что это хорошая практика, нет, это плохая практика. Либо давайте аргументы в поддержку этого. Пока были только экономия траффика (какое надо меню чтобы хоть один кб сэкономить) и экономия серверных ресурсов на рендеринге пунктов меню (рендеринг js-массива видимо сервер будет делать бесплатно в подарок).

возможно второе, но ajax-проекты тут не при чём. к тому же, запутывания кода не будет происходить, если будет использоваться шаблонизатор (это я про js).
со стороны php : smarty против implode(или foreach).

нет, основные причины - это понижение нагрузки на сервер (доля серверного языка уменьшается, хоть и не намного) и повышение гибкости (массив данных, которых должен будет вывести JS и добавить на страницу, как вздумается, а не взаимодействовать уже с готовым HTML.

не понимаю, почему скрипты вдруг становятся недоступными, а страница отдаётся. всё ведь на одном хостинге, в одном месте.

в направленных на вывод php-шных циклах.

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


ЗЫ как я понял, единственная проблема - это поисковики.

Имхо - хреновый пример. Куча утечек памяти, и firebug постоянно пестрит сообщениями об ошибках.

melky,
Стоп, кажется мы немного про разные вещи говорим. Речь вроде бы про шаблонизаторы на серверной стороне. Шаблонизатор bмеет свою грамматику для вывода простых конструкций логигки (ветвление, цикл, вывод другого шаблона и тд).Чтобы срендерить кусок html шаблонизатору нужнем экземпляр модели с данными. В модели как правило есть коллекция (массив/хэш) ссылок и тайтлов пунктов меню (если упрощенно и только плоский список). У нас есть выбор, либо собрать из этого ul и на этом успокоиться, либо собрать конструкцию
<javascript>
(function () {
var _ = [коллекция_пунктов_меню];
document.write(renderMenu(_));
})();
</javascript>
В чем тут выигрыш в производительности? В любом случае нам нужна модель с данными, которая будет получена только на сервере и больше ни где.

Другой вариант, если у нас ajax во все поля. Тут два варианта, либо с сервера мы сразу получаем кусок html (этот вариант ничем не отличает от первого), пример quake live, либо модель мы получаем ajax'ом, шабонизатор используем клиентский (тентаклик, лицокнига). Но речь вроде бы не про это, а именно про первый вариант поведения.

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

мм?
согласен, но предупреждения у jquery видел?)

Как это? Коллекцию нам все равно надо будет обойти, только это будет скрыто от нас за синтаксисом языка.

её выводит уже сам пользователь.

ЗЫ что-то мне кажется, что делать так - дело вкуса, не более. ощутимых минусов и плюсов нет. мне просто нравится заменять JS'oм всё, что вижу. если бы смог написать комбайнер - он был бы сейчас готов :)

Открой вкладку на пару часов и посмотри на расход памяти. Где конкретно утечки происходят - сказать не могу, в код не смотрел))

там json раз в секунду принимается. вспомни, как кто-то жаловался на это (но не вконтакте)

хм. действительно, странная проблема.

Реже. Для стен - раз в десять, точно помню. Для сообщений они по-моему вообще long соединение держат. Хотя это не важно, по сути)

А почему я должен любить то, что мне неприемлемо (это не касательно данной теме)?
Короче говоря, куча доводов и только один факт, к которому можно найти подход - поисковики. (сюда же и отключенный js можно отнести)
Я открыл главную страницу мэйл.ру - мне не впадлу стало подсчитать количество div`ов - 266. При чём это количество можно разбить на несколько групп с одинаковым классом. Меня посещает отличная идея - почему бы не озадачить js подобным образом:

function div(id,class,text){
   return "<div id='"+id+"' class='"+class+"'>"+text+"</div>";
}
var i,divs=['<?=implode("','",$someLongArray)?>'];
for(i=0;i<divs.length;i++){document.body.innerHTML+=div(divs[i][0],divs[i][1],divs[i][2]);}

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

Возвращаясь к говнокоду
То, что написано выше похоже на говнокод? Если да, то в каком месте?

Это называеться сборка страници на клиенте. туже задачу можно на xslt сделать на браузере... приходит xml и xslt и собираеться html. да и ещё какимто шаблонизатором можно да и без xml, главное чтобы браузер понял что с этим делать...

Действительно такие идеи есть, только зачем это выносить на клиент? если это прекрасно делается на сервере?

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

а почему бы и нет? экспериментируем и познаём.

а вы знаете, что Dart собирается так делать?

MVC, да-а... ответьте мне на вопрос, как быстрее будет вывести, так ?

$proto = "<div>{user} - {message}</div>";
foreach($long_array as $user => $messages) result .= strtr($proto, array($user => $messages));
# не уверен, что он будет работать. просто пример.

или же так :

var data = <? echo json_encode($long_array); ?>;
build(data);

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

а вот в это не могу поверить. это только начало появляться. есть ссылки, или что-нибудь в этом роде?

Я про подход раделения даныых отображения и т.д. я не про шаблонизаторы на клиенте...

ну а поисковики будут "рады" этому.. да и ещё куча проблем может вылезти.... тут куча нюансов может быть... хотя данный подход я не отрицаю...

чесно говоря до сегодня не знал, но не удивился, оно к тому и идёт что скоро будет называться не компьютер а гугл :)

melky,


Кстати по дарту вопрос, я немогу понять, это гугул в ответ кофескрипту замутила, тоесть посути надствройка транслирующаяся в яваскрипт. Или в планируеться как отдельный язык со своим интерпретатором?

Да.

Короче говоря, вариант с построением страницы на стороне клиента снимает эту нагрузку с сервера, уменьшается объём данных передаваемый от сервера клиенту, но появляется необходимость в разработке дополнения для поисковиков (но не играет решающую роль). Как вывод - лучше использовать js. Пусть это будет для кого-то неприемлемо, но весомых аргументов никто не смог привести.
Сразу же, будет уместно вспомнить, что есть сайты, хоть и не часто встречаются, на action script. Это разве более приемлемо, чем js? Нет...

Кстати яндекс умет индексировать AS но только второй версии, на сколько я знаю.

d-kaktus,
Создается впечатление, вы слышите только то, что хотите слышать, возникает подозрение, что вы просто троль.
Перечитайте еще раз ветку, была названа куча причин так не делать. Вы их все отмели совершенно не вдаваясь в аргументацию.
К примеру, отметите причину, что пихать в представление логику - херовая идея.
Либо, зачем изобретать велосипед, хотите шаблонизацию на клиенте, используйте xslt.
Как закончите с этими причинами, скажите пожалуйста в каком месте вы собрались располагать вызов функции, что будет создавать меню и добавлять его в DOM?
Это вообще пушка, сделайте пример и посчитайте эту "экономию"?

Это фимоз головного мозга. Поэтому тут уже никто не пишет, кроме автора и пары человек...

Можно было бы еще кеширование вспомнить. С JS-ом ведь страница в любом случае будет "пересобираться".

Как по мне, хочет кактус писать вывод HTML на JS - пусть пишет. Мне-то какое дело? Это исключительно его мнение и я сомневаюсь, что кто-то из присутствующих здесь вдруг схватится за голову и с криком "что же я делаю" потрет весь свой хтмл и начнет в спешке переписывать на JS, или будет делать это в дальнейшем.

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

Господа, не буду отрицать вашу правоту в том или ином выводе на счёт данной темы. Тему я создал не для пустых базаров. Мне интересно каждое мнение и каждый вывод. Конечно, опровержение идеи по js в данном вопросе даёт мне серьёзную почву для размышления.
Я далеко не профи в данных делах, а только любитель, по этому я сделаю два варианта - сайт на js и аналогию на html (мне это интересно) и обращу внимание на все моменты освещённые вами в данной теме.
Не буду обещать, но если мне в будущем удастся довести это дело до однозначного вывода, обязательно отпишусь с предоставлением фактов.
Всем спасибо!

Сделайте, пожалуйста, ещё замеры скорости. И сравнение выложите куда-нибудь.