LINUX.ORG.RU

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


0

0

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

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

А если оно того стоит, то каким JavaScript фреймворком пользоваться?

★★★★★

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

tia
()

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

archimag ★★★
()

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

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

wfrr ★★☆
()
Ответ на: комментарий от tia

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

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

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

Macil ★★★★★
() автор топика

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

vertexua ★★★★★
()
Ответ на: комментарий от Macil

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

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

tia
()
Ответ на: комментарий от vertexua

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

tia
()
Ответ на: комментарий от tia

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

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

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

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

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

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

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


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

Macil ★★★★★
() автор топика
Ответ на: комментарий от Macil

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

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

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

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

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

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

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

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

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

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

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

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

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

tia
()
Ответ на: комментарий от Macil

> Например?

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

archimag ★★★
()
Ответ на: комментарий от tia

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

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

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

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

Macil ★★★★★
() автор топика

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

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

SV0L0CH
()
Ответ на: комментарий от archimag

>но она для Java

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

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

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

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

Macil ★★★★★
() автор топика
Ответ на: комментарий от Bad_Habit

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

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

Macil ★★★★★
() автор топика
Ответ на: комментарий от archimag

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

Bad_Habit
()
Ответ на: комментарий от SV0L0CH

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

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

archimag ★★★
()
Ответ на: комментарий от vertexua

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

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

simple_best_world_web_master
()

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

anonymous
()

Проблемы:

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

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

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

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

Dobriy_i_Prostoy
()

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

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

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

volh ★★
()
Ответ на: комментарий от SV0L0CH

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

Deleted
()
Ответ на: комментарий от volh

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

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


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


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

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

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

Macil ★★★★★
() автор топика
Ответ на: комментарий от Macil

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

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

Macil ★★★★★
() автор топика
Ответ на: комментарий от Deleted

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

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

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

SV0L0CH
()
Ответ на: комментарий от Deleted

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

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


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

archimag ★★★
()
Ответ на: комментарий от Macil

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

Есть еще и XUL.


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

archimag ★★★
()
Ответ на: комментарий от archimag

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

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

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


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

Deleted
()
Ответ на: комментарий от Deleted

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

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

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


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

archimag ★★★
()
Ответ на: комментарий от archimag

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

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


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

Deleted
()
Ответ на: комментарий от Deleted

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

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

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


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

archimag ★★★
()
Ответ на: комментарий от archimag

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

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

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


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

Deleted
()
Ответ на: комментарий от Deleted

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

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


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

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


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

archimag ★★★
()
Ответ на: комментарий от archimag

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

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

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

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



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

Deleted
()
Ответ на: комментарий от Deleted

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

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

archimag ★★★
()
Ответ на: комментарий от Deleted

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

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

archimag ★★★
()
Ответ на: комментарий от Deleted

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

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

archimag ★★★
()
Ответ на: комментарий от archimag

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

Deleted
()
Ответ на: комментарий от Deleted

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

(?_?)'

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

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

SV0L0CH
()
Ответ на: комментарий от Deleted

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

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

SV0L0CH
()
Ответ на: комментарий от SV0L0CH

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

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


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

archimag ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.