Рендеринг HTML на стороне клиента. Стоит ли?

Идея не нова, но сам рендеринг будет более проблемным. Просто посмотри как люди жалуются на проблемы с FF, а конкретнее - тормоза. Что же будет если браузеру придётся не просто обрабатывать HTML и небольшой набор виджетов на JQuery, но ещё и генерировать тот HTML средствами JS-движка?
Хромиум справился бы, возможно. Вообще погугли на тему JS-template engine or something like that.

tia (30.06.2010 22:58:23)

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

archimag (30.06.2010 23:20:54)

>скармливтаь браузеру исключительно JSON, который на стороне клиента будет представляться как клиентской душе будет угодно.

Давно делается и работает, на некоторых задачах это будет работать быстрее чем просто html

wfrr (30.06.2010 23:21:38)

Если честно, то тормозов я не заметил. Взять тот же visualjquery.com

Кроме того, компы мощные, практически ненагруженные, среда корпоративная. И тормоза как на стороне клиента, так и на стороне сервера не в счет.

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

Macil (30.06.2010 23:26:07)

>Главное использовать на клиенте какую-либо библиотеку шаблонов

Например?

Macil (30.06.2010 23:27:02)

Я тоже так думал делать. Или немного по-другому. У меня стандартный шаблон на divах. Все div наполняются по-принципу HTML-over-Ajax. Есть ли смысл? Получается что трафик очень уменьшается, потому что все оформление, картинки и css грузится один раз в кеш. Меняется только контент, который представляет собой почти просто текст, иногда картинки.

vertexua (30.06.2010 23:30:57)

Плюсы:
Экономия на производительности сервера, на памяти сервера, на трафике, на сложности разработки серверной части.
Минусы:
Сложность разработки клиентской части(смотря как оно будет писаться и юзаться).
Нет IE(хотя чуть спорно, но... вы понимаете).
Нет слабым машинам(и более чем слабым, в конце концов пользователи хотят юзать не только один браузер с одной страницей).

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

tia (30.06.2010 23:42:15)

By the way, как сабж индексировался бы Google?

vertexua (30.06.2010 23:43:23)

Кстати да. Если так, как это делают многие индексаторы(ну не сеошник я, по сему только "слышал"), то никак.

tia (30.06.2010 23:47:24)

>и не имеешь много времени - лучше отложи в копилку идей

А в чем причина.

Все равно, это нужно делать, ибо иначе придется это же делать руками, и мне же.

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

Существенно упрощается веб-фреймворк. Формализуется процедура разработки. Упрощается автоматическое тестирование. Появляется возможность создания REST/JSON API для интеграции с компонентами, труднореализуемыми в рамках веб-приложений.

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

>Другое дело что я бы посоветовал найти готовые решения. Уверяю, они должны быть.

Есть. Но дорого. И криииииво. Предметная область специфическая.

Macil (30.06.2010 23:53:34)

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

>Все равно, это нужно делать, ибо иначе придется это же делать руками, и мне же.
Делать - да, но следует исследовать все вопросы, в т.ч. с индексированием. А одним тредом на ЛОРе это не обойдётся.
>Веб приложение - как средство, чтобы не тархаться с развертыванием.
Средства развёртывания веб-приложений - как средство, чтобы не трахаться с развёртыванием. Веб-приложение можно написать и трахаться с развёртыванием.
В общем, не понял мысли.
>Существенно упрощается веб-фреймворк.
Серверная часть, за счёт клиентской, которая усложняется.
>Формализуется процедура разработки. Упрощается автоматическое тестирование. Появляется возможность создания REST/JSON API для интеграции с компонентами, труднореализуемыми в рамках веб-приложений.
Ты так говоришь, как-будто мы в каменном веке.
>Клиентский интерфейс можно пилить в горячем режиме и независимо от серверной части.
А сейчас для написания темплейтов нужна готовая логика?
>Есть. Но дорого. И криииииво. Предметная область специфическая.
Уверен что напишешь лучше?

tia (01.07.2010 0:01:56)

> Например?

Я знаю Google Closure Templates, но она для Java, мне нужно для Common Lisp я переписал - получилось cl-closure-template. Для других технологий не знаю, но наверняка должно быть.

archimag (01.07.2010 0:09:11)

>Уверен что напишешь лучше?

Да. По крайней мере я не буду хранить деньги во float как некоторые :)

У меня среда корпоративная. Многие вещи просто не важны, типа той же индексации. А многие - наоборот. Плюс еще добавляются определенные политические проблемы.

Кроме того. А как же фан? Без фана ведь никуда. А прикрутить веб-интерфейс к системе интеграции одной системы с другой - прикольно.

Macil (01.07.2010 0:23:54)

А есчё есть вариант отдавать данные в xml и рендерить через xslt.

Однако, практика показала что json+js использовать легче.

SV0L0CH (01.07.2010 0:28:27)

>но она для Java

Я как раз сколняюсь к Clojure. Главным образом из-за возможности использования инфраструктуры серверов приложений типа томката (типа аутентификации по клиентским сертификатам).

Хотя еще толком не решил что именно выбрать.

А CL мне однозначно ниасилить. Как-то у меня с ним знакомство не сложилось.

А вот еще вопрос. Стоит ли заморачиваться с routes а-ля ruby on rails. Или написать простейший разборщик URL, тем более, структура будет предельно простая?

Macil (01.07.2010 0:31:29)

> Стоит ли заморачиваться с routes а-ля ruby on rails.

а вы кстати не рассматривали вариант с RoR + jQuery?

Bad_Habit (01.07.2010 0:40:57)

> Стоит ли заморачиваться с routes

Конечно.

archimag (01.07.2010 0:55:48)

>а вы кстати не рассматривали вариант с RoR + jQuery?

Рассматриваю. Но, скорее как запасной.

Macil (01.07.2010 0:56:13)

> а вы кстати не рассматривали вариант с RoR + jQuery?

RoR + Prototype вы хотели сказать?

archimag (01.07.2010 0:56:52)

Есть jRails, это интеграция jQuery в RoR. Prototype не настолько популярен, по субъективным ощущениям :)

Bad_Habit (01.07.2010 1:06:46)

> А есчё есть вариант отдавать данные в xml и рендерить через xslt.

Через это уже прошёл и больше так делать не советую. Клиентские шаблоны рулят.

archimag (01.07.2010 1:20:58)

> By the way, как сабж индексировался бы Google?

В зависимости от реализации: от "никак" до "лучше, чем на обычном html".

лучше замутить что-то вроде отдачи клиенту xml с подключенным листом стилей, как, например, сделано вот тут: http://www.worldofwarcraft.com/

Проблемы:

• не будет индексироваться поисковиками,
• большая нагрузка на клиентский браузер,
• не будет работать в браузерах без js/с отключенным js.

Но зато ты снижаешь нагрузку на сервер и получишь потом возможность лёгкой интеграции различных приложений с сайтом.

Вообще, если ты пишешь именно веб-приложение, а не сайт, то это весьма неплохой вариант.

Что касается фреймворка, то разумеется jQuery.

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

если запасной вариант - ror, то имхо для простого внутрисетевого приложения это оверкилл и стоит посмотреть на http://www.sinatrarb.com/intro ( ну, или на padrinorb.com )

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

volh (01.07.2010 18:07:53)

Если не делать на клиенте какое-то незнамо что, то XSLT вполне себе вариант. В конце концов в результат тоже можно встроить JS, если очень надо что-то посчитать, что в XSLT сложно. Но ещё есть IE и как в нём всё заработает это интересный вопрос (хотя преобразование он и делает).

Mystra_x64 (01.07.2010 21:38:31)

>обязательно какие-нибудь грабли всплывут

Дык. Вот и мне интересно КАКИЕ грабли...


>почему по-твоему на клиенте его генерить должно быть проще чем на сервере?

Не проще. Даже сложнее, может быть. Но:

1. Получаю полнейшую развязанность между модель-контроллер и представление.
2. Возможность автоматического тестирования.
3. Возможность создавать REST/JSON API.
4. Возможность пилить клиента без вмешательства в работу сервера и наоборот.

Кроме того, есть офигительные наборы JS виджетов что от гугла, что от yahoo. Так что вроде бы и *мне* не нужно заморачиваться с генерацией HTML.

Macil (02.07.2010 0:56:28)

Кроме того, почему именно зацикливаться на чистом HTML? Есть еще и XUL. Есть еще и плагины для Chrome. Есть еще плагины для файрфокс.

А есть еще вполне себе трехзвенная архитектура.

Macil (02.07.2010 1:00:32)

>В конце концов в результат тоже можно встроить JS, если очень надо что-то посчитать, что в XSLT сложно.

Когда я заметил что мои XSLT обростают генераторами JSON фрагментов и в результате полно подключенyого JS кода, я понял что что-то делаю не так.

А сейчас, когда распостранён AJAX, сразу подгружаемый XML преобразую в удобный для меня JSON и уже потом с ним что-нибудь делаю. А ведь JSON в многих случаях можно отдавать сразу.

SV0L0CH (02.07.2010 10:47:40)

Я сначала так и работал: отдавал XML и использовал XSLT для генерации контента, но теперь я полностью перешёл на схему с JSON и клиентскими шаблонами - профита просто немерянно, всё стало проще, кода меньше, при том, что функционала стало больше.

> Но ещё есть IE и как в нём всё заработает это интересный вопрос

XSLT в IE работает нормально, проверено.

archimag (02.07.2010 12:25:37)

> Кроме того, почему именно зацикливаться на чистом HTML?
> Есть еще и XUL.

Я использовал XUL для корпоративного приложения и в итоге ушёл на HTML - так реально проще.

archimag (02.07.2010 12:26:57)

>XSLT обростают генераторами JSON фрагментов

(?_?)'

Mystra_x64 (02.07.2010 12:41:00)

>Я сначала так и работал: отдавал XML и использовал XSLT для генерации контента, но теперь я полностью перешёл на схему с JSON и клиентскими шаблонами

А разница? XSLT и есть «клиентский шаблон»

>XSLT в IE работает нормально, проверено.

Это ты просто в реальный XHTML выводить не пытался, ну да это другая история :)

Mystra_x64 (02.07.2010 12:42:18)

> А разница? XSLT и есть «клиентский шаблон»

Разница большая. При использовании xml уровень оверхеда зашкаливает. Работа с JSON в JavaScript является простой и удобной, чего не скажешь о работе с xml. Я как бы люблю XSLT, написал на нём несколько десятков тысяч строк кода, но был вынужден отказаться от его использования на стороне клиента ибо это жутко раздувает код и ведёт в тупик. Если что, вот скринкаст моего приложения, построенного на основе использования XSLT на клиенте: http://www.youtube.com/watch?v=5Pm5-TKmPYQ.

> Это ты просто в реальный XHTML выводить не пытался

Конечно, ведь IE не поддерживает XHTML ;)

archimag (02.07.2010 12:59:14)

По ссылке: XUL+SVG-editor shop's shelf. А при чём там XSLT? Подозреваю, что ты писал что-то нехорошее и страшным способом, ну да ладно :)

>Конечно, ведь IE не поддерживает XHTML ;)

Но преобразование то он делает. Т.е. вся его неподдержка заключается в нежелании Икрософта :) Хотя, говорят, в IE9 XHTML таки будет работать, но даже если и так, оно в XP всё равно не устанавливается.

Mystra_x64 (02.07.2010 13:10:33)

> А при чём там XSLT?

Там вся генерация разметки сделана с помощью XSLT, а JavaScript только рулит этим процессом.

> Подозреваю, что ты писал что-то нехорошее и страшным способом

Хм, на чём основанны подобные подозрения?

archimag (02.07.2010 13:15:23)

>Там вся генерация разметки сделана с помощью XSLT, а JavaScript только рулит этим процессом.

?? Ты что за велосипед там изобрел? Браузер сам умеет XSLT делать, без жабоскрипта.

>Хм, на чём основанны подобные подозрения?

Ну вот возьмём XSLT: http://serenareem.net/transform/base.xsl
В чём принципиальная разница построения так или JS и JSON? Также выбираешь данные и вставляешь в нужные элементы.

Mystra_x64 (02.07.2010 13:44:04)

> ?? Ты что за велосипед там изобрел? Браузер сам умеет XSLT делать,
> без жабоскрипта.

Гы, ты видео посмотрел? Там имеет место динамика: идёт редактирование планограммы, которое должно быть отображенно в соответствующую модель. Обмен между сервером и клиентом на основе XML. Изменение модели должно приводить к изменению контента. Как это сделать без JavaScript? Может чего не понимаю...

> В чём принципиальная разница построения так или JS и JSON?

Если страница не будет меняться под "воздействием" пользователя, то использовать XSLT в качестве стиля вполне приемлемо. Но если нужно интерактивное взаимодействие, то нужно включать JavaScript, а работать в JavaScript с JSON намного, намного проще. Разве это не очевидно?

archimag (02.07.2010 13:51:55)

>ты видео посмотрел?

Нет конечно, ты за кого меня принимаешь :)

>дёт редактирование планограммы, которое должно быть отображенно в соответствующую модель
>Обмен между сервером и клиентом на основе XML

XSLT для этих целей использовать это какой-то извращение :) Можно также взять JS и XML, JSON тут не принципиален, разве что ты его лучше понимаешь.

Mystra_x64 (02.07.2010 14:02:38)

> XSLT для этих целей использовать это какой-то извращение :)

Ты предлагаешь генерить всю разметку с помощью JavaScript? Ты вероятно мужественный и очень трудоспособный человек. Почитай доки на http://code.google.com/p/closure-templates/, обрати внимание где используется эта библиотека, может поймёшь чего-нибудь.

archimag (02.07.2010 14:19:29)

А JSON тебе магически разметку даст что ли?

Mystra_x64 (02.07.2010 14:20:18)

> А JSON тебе магически разметку даст что ли?

Мля... Библиотека Closure Template компилирует шаблоны в JavaScript-функции, на вход которым даются JS-объекты (которые получаются в результате разбора JSON), а отдают они разметку, которую используют для непосредственной модификации страницы.

archimag (02.07.2010 14:33:25)

Очередной велосипед? Понятно.

Mystra_x64 (02.07.2010 14:35:00)

> Очередной велосипед? Понятно.

Это ты так про Gmail и Google Docs? Идиот или только притворяешься?

archimag (02.07.2010 14:45:24)

>Идиот
>Мля

Я запомню при случае тебе никогда не помогать с проблемами.

Mystra_x64 (02.07.2010 14:47:50)

> Я запомню при случае тебе никогда не помогать с проблемами.

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

archimag (02.07.2010 14:54:35)

Любителям использования ненужной JS лапши помогать всё равно бессмысленно, чего уж там.

Mystra_x64 (02.07.2010 14:58:00)

>>XSLT обростают генераторами JSON фрагментов

>(?_?)'

<script>
 <xslt:text>var my_var=</xslt:text>
 <xslt:apply-templates mode="json"/>
 <xslt:text>;</xslt:text>
</script>

^_^ фрагмент знакомый?

SV0L0CH (02.07.2010 15:24:15)

>А JSON тебе магически разметку даст что ли?

Разметка сгенерированная средствами jquery вполне нормально выглядит и работает.

SV0L0CH (02.07.2010 15:26:54)

> Разметка сгенерированная средствами jquery вполне
> нормально выглядит и работает.

Хм, в чём прикол? Как разметка выглядит и работает зависит от того, чем её генерили? ;)

archimag (02.07.2010 15:28:36)