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

[devote]

Но когда хтмл и пхп смешивается подобным образом

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

[Seva1986]

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

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

[da_ff]

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

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

[melky]

2) Пихать js в представление без веской на то необходимости - фейл.

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

3) Меню создается отдельно от контейнера, ОЧЕНЬ неочевидная ситуация - фейл.

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

4) Меню создается по подгрузке DOM-дерева (если создание меню вынесено в отдельный файл, а не следом за контейнером идет), если позникли проблемы с сетью и браузер никак не может получить часть страницы, меню тоже будет недоступно - фейл.

вся страница будет недоступна

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

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

[d-kaktus]

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

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

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

[trikadin]

Хорошая идея!
Да, и в целом, отличный пост! )

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

[da_ff]

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

его можно выводить через document.write

Так значит, вывести меню это веская причина чтобы пихать js в представление?

вся страница будет недоступна

Нет. Та часть, что уже получена и срендерена будет доступна.

уменьшение нагрузки на сервер, т.к. вывод массивов из БД

Вообще что-то пасмурное, вывод из БД вы в любом случае будете делать на сервере, в чем экономия то?!

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

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

[melky]

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

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

Так значит, вывести меню это веская причина чтобы пихать js в представление?

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

Нет. Та часть, что уже получена и срендерена будет доступна.

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

Вообще что-то пасмурное, вывод из БД вы в любом случае будете делать на сервере, в чем экономия то?!

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

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


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

[trikadin]

отличный пример - вконтакте.

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

[da_ff]

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

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