ахахх... насмешил... если тебя послушать, то вообще какой смысл ты вообще поднял эту тему. Если ты считаешь что нужно освободить сервак от нагрузки, то шаблонная система на темплейтах поверь нагружает сервер куда сильнее, нежели 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'ом, шабонизатор используем клиентский (тентаклик, лицокнига). Но речь вроде бы не про это, а именно про первый вариант поведения.