Xpoint
   [напомнить пароль]

Где генерировать однотипный HTML? На сервере или на клиенте?

Метки: [без меток]
[арх]
2006-01-02 21:33:07 [обр] Василий М.+(1/171)[досье]

Сейчас DOM и новые браузеры позволяют достаточно легко генерировать HTML на стороне клиента, хотя, конечно, реализация DOM не идеальна, что бы использовать его на всю катушку. Как вы считаете, стоит ли уже сейчас отказаться от генерации некоторого процента однотипного HTML на сервере и генерировать его на клиенте?

Банальный пример такой однотипной генерации - то, что выводится циклом. Типа сообщении в гостбуке и всё такое.

спустя 1 час 24 минуты [обр] Сергей Круглов(35/2057)[досье]
а поисковики это будут хорошо индексировать?
спустя 5 минут [обр] Василий М.+(1/171)[досье]
Не, я имел в виду те элементы, которые совершенно незначительны для поиковиков. Элементы управления, визуальные эффекты, кнопочки-формочки...
спустя 15 минут [обр] wiktar(1/20)[досье]

Ну помню что eBay раньше так и делал (а может быть и сейчас под IE): генерация item-ов осуществлялась JavaScript-ом в цикле.

Однозначно, что поисковики не будут индексировать контент, сгенерированный JavaScript-ом. Но если его применять для незначительных поисковику вещей, такие как кнопочки... формочки... То...

Это будет выглядеть так? : В нужном месте страницы будет вызываться create_button ('ОК', 'ok.php'); create_button ('Cancel', 'cancel.php'); ?

Пока не вижу смысла ).

спустя 14 часов [обр] Сергей Круглов(35/2057)[досье]
Вообще, некоторые форумы уже давно по этому принципу работают, тот же forum.ixbt.com, посмотрите http://forum.ixbt.com/?id=24 и его исходный код.
спустя 5 часов [обр] Сергей Чернышев(39/589)[досье]
А зачем это все? Экономия трафика? Или еще что?
спустя 3 часа 42 минуты [обр] Алексей В. Иванов(28/2861)[досье]
Защита от поисковиков, видимо. Это единственный смысл всего этого. Создание тайных обществ, которые невозможно найти через поиск. Вход только по приглашениям.
спустя 3 часа 7 минут [обр] Сергей Круглов(35/2057)[досье]

Экономия траффика и процессорного времени на гзип.
Борьба с баннерорезками.
Борьба с "выкачивателями".

(По материалам тамощнего "О форуме")

спустя 1 минуту [обр] Сергей Круглов(35/2057)[досье]
Да, еще экономия ОЗУ сервера
спустя 34 минуты [обр] Алексей В. Иванов(28/2861)[досье]
сообщение промодерировано
Не вижу никакой связи вышеперечисленного с генерацией JS.
Обычный текст/html хорошо и модемы сжимают, так что с gzip можно и не заморачиваться. Экономии ОЗУ никакой gzip не требует много памяти (единицы килобайт, не более для обычных страниц).
спустя 29 минут [обр] Сергей Круглов(35/2057)[досье]
сообщение промодерировано
Не вижу никакой связи вышеперечисленного с генерацией JS.

Ээ.. Вырезал баннер - получи JS error и пустую страницу. Нефиг нахаляву трафик гонять.

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

Обычный текст/html хорошо и модемы сжимают

Что-то мой ADSL Zyxel в таком не замечен...;) Dialup-модемы давно mustdie, вся Москва уже "обстрималась" поди, а контору с диалапом днем с огнем...

К тому же, они экономят не трафик пользователей, а свой канал.

никакой gzip не требует много памяти

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

В общем, интернет-browsing уверенно идет в сторону "утолщения клиента", и это правильно... Если у клиентов компы помощнее иных серверов, что ж им простаивать?

спустя 1 день 15 часов [обр] Сергей Чернышев(39/589)[досье]

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

Они бы лучше эти усилия на пользу общества или себя тратили, а эти извращения - это скорее в пользу бедных...

спустя 8 минут [обр] Алексей В. Иванов(28/2861)[досье]
Сергей Круглов[досье] сжатие данных, кажется, есть во всех модемах.
...Но все это беседа ни о чем. Не понимаю какие могут быть аргументы против того, что для поисковиков данного сайта не существует.
Если сайта нет в поисковиках, значит, его не существует. Для меня никогда не было форума на ixbt и не будет, пока мой любимый поисковик на него ссылки не станет давать.
спустя 2 часа 2 минуты [обр] Сергей Круглов(35/2057)[досье]

Сергей Чернышев[досье]
У них там и так многопроцессорный оптерон на самом толстом канале. Оказывается, мало. Что дальше? Кластеры как у гугеля? А вообще, я их вовсе не защищаю, просто мне кажется, что они гораздо больше думали над возможностями оптимизации, а мы тут "со своей колокольни" - "это все фигня, железный gzip спасет их 100%, и нефиг извращаться".

Алексей В. Иванов[досье]
Сжатие данных есть только у dialup-модемов. И, опять повторюсь, это экономия на траффике клиента, а не хоста.

Видать, то, что сайта нет в поисковиках, их не смущает. А, может, поисковикам они отдают неоптимизированную версию.

спустя 3 минуты [обр] Сергей Круглов(35/2057)[досье]
Да, выкачал страницу wgetом с подделанным user-agent - скачался plain html без скриптов
спустя 1 час 43 минуты [обр] Сергей Чернышев(39/589)[досье]

Сергей Круглов[досье]
Архитекрута упирающаяся в одну машину - это не архитектура. Что у них там такое что они не могут две машины поставить? Зачем им кластер когда простейшего LB и двух машин им хватит позарез?

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

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

Своя колокольня должна быть у каждого - если мы не можем оценить чужое решение, то мы не сможем сделать своего.

спустя 3 часа 27 минут [обр] Сергей Круглов(35/2057)[досье]

Сергей Чернышев[досье]
Я не знаю, может у них и 20 машин будет мало. Может для генерации страницы негзипованного размера в 150 кб требуется 150 кб ОЗУ, а для генерации обычной страницы в 20 кб - 20. И они ОЗУ экономят.

Я уже как-то привык, видя странное решение, не говорить сразу "чепуха", а пытаться понять, чем оно продиктовано. Как оно "вымучено".

p.s. Бывало сам зайду в старую свою программу, вижу что-то эдакое, думаю, "нафига я это написал", исправляю, и какая-нить функциональность отваливается. Оказывается, я это неспроста придумал, а потом забыл.

p.p.s. нашел ихнюю конфигурацию: http://www.ixbt.com/pr/etegro-server.shtml

спустя 8 часов [обр] Сергей Чернышев(39/589)[досье]
Сергей Круглов[досье]
Ну, ну я же не говорю, что они просто так там код фигачал - я говорю, что решение такое явно требует много ресурсов при разработке и девелопменте, а прибыль приносит весьма мелкую - если бизнесу такая прибыль принципиальна до такой степени, что они предпочитают отклониться от легко поддерживаемого и масштабируемого подхода, то это не значит, что это хороший пример для подражания для остальных - на это должна быть веская причина.
спустя 2 часа 35 минут [обр] Сергей Круглов(35/2057)[досье]
Сергей Чернышев[досье]
Не факт, что разработка такого очень дорога. У форума этого шаблонов-то (основных) всего штуки 2-3. Переписат их на document.write - дешевле обеспечивающего нужную производительность "кластера" выйдет, видать...
спустя 2 часа 49 минут [обр] Александр Самойлов(5/342)[досье]

Сергей Чернышев[досье]
А чем разработка отличается от девелопмента?
Или разработка это типа дезигн, а девелопмент - имплементация?

К тому же, как мне кажется они вполне верно воспроизвели идею XML + XSLT на клиенте.
Только вместо XML у них свой javascript'овый формат, а вместо XSLT свои же скрипты.

спустя 3 часа 1 минуту [обр] Сергей Чернышев(39/589)[досье]

Сергей Круглов[досье], Александр Самойлов[досье]
Ну, все это еще включает поддержку и т.д. Если задача только принтануть JavaScript-ом, то ее решить-то не сложно - все перевел в него и все, но те же поисковики и прочие аспекты веба поддерживать, а также отладка работы скриптов в браузерах - тут и начинается геморой.

Я понимаю, конечно, что они просто кэшируют JS который делает непосредственный вывод данных и при этом избегает размеров кода XML и XSLT, а также более кросплатформенно чем XML/XSLT.

спустя 2 часа 35 минут [обр] Сергей Круглов(35/2057)[досье]

document.write отлаживать? ;)

p.s. В конце-концов, это бизнес по-русски - не деньги любой ценой, а еще и стремление к "великой цели". Может, у них идея искоренить пагубную привычку отключать JavaScript среди параноидальных админов и пользователей...

спустя 3 дня [обр] Григорий(0/8)[досье]
имхо, отладка document.write не столь великая проблема, если имеем дело с однотипными повторяющимся рендерингом из js.
спустя 1 день 20 часов [обр] ddd(3/36)[досье]

Алексей В. Иванов[досье]

Если сайта нет в поисковиках, значит, его не существует. Для меня никогда не было форума на ixbt и не будет, пока мой любимый поисковик на него ссылки не станет давать.

А с чем связана такая категоричность? Если на форуме есть с кем что-то обсудить, то какая разница индексируется он или нет? Вот уж никогда не обращал на это никакого внимания :)

спустя 48 минут [обр] Алексей В. Иванов(28/2861)[досье]
Чтобы обсудить, надо знать "где".
Когда я в поисковике искал ответы на свои вопросы, я находил обсуждения людей на xpoint, именно поэтому запомнил его и остался на нем.
И еще... не вижу смысла "вариться" в закрытом обществе, не принося пользы обществу (1-3 человека, участвующих в теме — не общество).
спустя 52 минуты [обр] Сергей Круглов(35/2057)[досье]
Алексей В. Иванов[досье]
Да индексируется он, индексируется...
спустя 6 минут [обр] Алексей В. Иванов(28/2861)[досье]
Да, прочитал уже, но все это, IMHO, горе от "ума".
спустя 6 дней [обр] Ярослав Федин(0/2)[досье]

Все дело в том, что для поисковиков отдается original код, а для юзеров - полуфабрикат.

Сравните:

Так видит форум поисковик:
http://64.233.183.104/search?q......t.com+forum&hl=ru&client=opera

А так юзер:
http://forum.ixbt.com/?id=29

спустя 2 часа 55 минут [обр] Сергей Круглов(35/2057)[досье]
про это в этой теме уже писалось недели 2 назад.
спустя 26 дней [обр] Даниэль Алиевский(9/125)[досье]

Почему-то весь вопрос свелся к экономии трафика и времени сервера. По-моему, довольно странно.

Попробуем применить аналогичные аргументы к написанию визуального интерфейса приложения. Можно весь интерфейс, со всеми формочками, меню и прочим "нарисовать" в некотором редакторе ресурсов (аналог plain html). Файл ресурсов не содержит никакой функциональности и прикомпилируется отдельно. Так изначально было в Windows.

А можно, как это принято в Java, весь интерфейс создавать динамически, вызовами некоторых методов и конструкторов компонент. У такого подхода, очевидно, есть свои достоинства. Не только читабельность и компактность получаемого кода, но и, например, высокая степень гибкости получаемого интерфейса (он может сильно зависеть от ситуации). Можно, скажем, применять все возможности ООП, чтобы систематизировать однотипные элементы интерфейса во всех окнах.

Применим к веб-страницам. Чем плохо, если все или почти все оформление страницы строится применением нескольких JavaScript-объектов ("компонентов"), соответствующим образом настроенных? Или даже вся страница, со всеми своими текстами?

Во-первых, это очень компактно - даже смешно сравнивать с gzip. Чтобы оформить страницу, достаточно указать управляющим процедурам, в чем особенности этой страницы по сравнению с типовым дизайном. Даже самая правильно смакетированная страница, полностью задействующая CSS, если она сложная, может потребовать много килобайтов на описание своего дизайна (меню, всевозможные украшения, фоны, стандартные баннеры, счетчики и т.п.) На JavaScript же, по идее, это сведется к вызову одной процедуры типа "задать особенности этой страницы". Разница в объеме может достигать сотен раз. Эта компактность полезна вовсе не только в плане экономии трафика, но и во всех прочих отношениях (читабельность результата view source, объем, занятый проектом на диске разработчика - а это могут быть сотни мегабайтов, и т.д.)
 
Во-вторых, гибкость предельная: все оформление сайта сосредоточено в JavaScript-библиотеках. В любом случае, это больше, чем может обеспечить самый продвинутый CSS (хотя CSS, конечно же, облегчит и такое проектирование).

В-третьих, JavaScript совершенно элементарно может приспособить оформление к ситуации у пользователя: например, учесть размеры окна, шрифта, тип броузера. JavaScript абсолютно свободен в выборе способа подачи текста: если угодно, можно всю информацию подавать в виде динамически всплывающих окон, или постепенным "проявлением" текста, или менять порядок текста на странице по усмотрению пользователя, и т.д...

В-четвертых, можно использовать развитые сторонние библиотеки или Look&Feel (что часто делается в разработках обычных приложений).

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

Почему же это не использовать в мало-мальски нетривиальных проектах?

Да, есть возражения.

  1. JavaScript могут отключить. Это правда так важно? Меньше 1% пользователей, кажется. И всегда можно попросить включить. (Выключают-то его для безопасности, когда бродят по подозрительным сайтам и боятся "дыр" в своем броузере. Если у вашего сайта репутация подозрительного, то вряд ли что-то ему поможет.)
  2. Роботы. А разве это проблема сайтов, что роботы "не понимают" JavaScript? Может быть, не понимают, потому что просто не востребовано? В общем-то нет ничего сложного встроить в робот какой-нибудь броузерный движок, который в состоянии отработать JavaScript. А покуда роботы не любят JavaScript, можно им подсовывать только основную суть страницы в академическом дизайне.
  3. JavaScript и DHTML глюкавы. Да, но ведь и HTML+CSS пока весьма различно понимаются броузерами, и отлаживать статические страницы не слишком просто. Возможно, куда проще манипулировать готовыми отлаженными кроссброузерными JavaScript-компонентами, которые заранее отлажены под все броузеры?
спустя 3 часа 5 минут [обр] Александр Самойлов(5/342)[досье]
1 и 2. Нетрудно и на сервере отработать javascript и подсунуть роботу или клиенту без javascript сгенерированную страницу в html. Это к тому, чтобы не заморачиваться с синхронизацией страницы на javascript и статической страницы для робота.
  1. На мой взгляд, сделать сложный кроссбраузерный javascript гораздо проще, чем сложный кроссбраузерный css.
спустя 17 часов [обр] Даниэль Алиевский(9/125)[досье]

Александр Самойлов[досье]

  1. Клиент без JavaScript - это все-таки другое. Во-первых, мало ли что там нагенерирует JavaScript? Может быть, весь текст будет разбит на "закладки" (tab), а видима будет только первая? Роботу, по идее, должно быть наплевать на видимость элементов. А всего надежнее, если версия для робота - "академическая" по стилю. Можно и посетителю без JavaScript подсунуть академический дизайн... Проблемы-то нет поддерживать "академическую" ветку. И для печати пригодится.

Во-вторых, а как вы обычно подсовываете другую версию в случае отсутствия JavaScript? Я как-то не вижу идеальных решений. Разве что <noscript>-блок, но тогда получается неоправданное, как минимум, удвоение объема. Лично я обычно просто пишу <noscript>Включите JavaScript</noscript>. Можно добавить ссылку на "академическую" ветку.

2,3. Тут, вроде бы, мы согласны.

спустя 4 года 11 месяцев [обр] Василий М.+(1/171)[досье]
Защита от поисковиков, видимо. Это единственный смысл всего этого
Поисковики, кстати, индексируют контент этого (ixbt) форума.
Powered by POEM™ Engine Copyright © 2002-2005