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

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

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

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

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

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

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

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

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

Например?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Делать - да, но следует исследовать все вопросы, в т.ч. с индексированием. А одним тредом на ЛОРе это не обойдётся.

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

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

Существенно упрощается веб-фреймворк.

Серверная часть, за счёт клиентской, которая усложняется.

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

Ты так говоришь, как-будто мы в каменном веке.

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

А сейчас для написания темплейтов нужна готовая логика?

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

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

> Например?

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

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

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

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

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

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

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

>но она для Java

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

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

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

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

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

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

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

Конечно.

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

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

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

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

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

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

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

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

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

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

Проблемы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть еще и XUL.

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

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

(?_?)'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

без жабоскрипта.

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

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

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

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

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

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

Обмен между сервером и клиентом на основе XML

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

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

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

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

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

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

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

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

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

>Идиот

Мля

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

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

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

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

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

(?_?)'

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

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

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

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

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

нормально выглядит и работает.

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