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

недостатки JS ориентированного интерфейса

Метки: [без меток]
2009-02-11 11:17:46 [обр] Михаил(0/17)[досье]
Была поставлена задача, на разработку определенного веб-приложения.
Есть идея следующей модели клиента: server <-(JSON|XML)-> client
Клиент и сервер обмениваются только данными. Генерирование всей страницы ложится на плечи JS, а именно, решил выбрать фреймворк ExtJS (других нормальных, такого уровня визуализации, не наблюдал).
Сразу же хочу оговорится, что приложение будет достаточно сложным, и должно по сути напоминать винь прилаги.
Если чесно, мысли больше не за что не цепляются, и незнаю чего ещё можно рассказать.
А вот вопросов море.
Кто может вообще чего посоветовать по этому поводу. Хорошо ли заставлять генерить весь HTML на клиенте? Получистя ли от этого выигрыш, или мы получим только головную боль?
Насколько труднее разробатывать и поддерживать прилождения такого типа?
Да и в целом, есть ли какие либо советы на эту тему?
спустя 17 минут [обр] MiRacLe(0/77)[досье]
Когда я стоял перед таким же выбором, то пришёл к схеме, когда сервер отдаёт готовый js-код (например object.innerHTML = '<code>html</code>';) - это оказалось несколько быстрее в работе чем генерация этого html на клиенте (тут наверное стоит упомянуть что реально большой выигрыш был лишь в случае с IE6+), позволяет не только менять html но и много чего ещё, контролируя приложение "с серверной стороны".
спустя 15 минут [обр] Михаил(0/17)[досье]

MiRacLe[досье]
Задача такова, что IE6 можно исключить. Основные браузеры: IE7 и FF.
В отдаче целикового кода, мне сильно не нравится, то что получается вся прилага завязана на сервере. Т.е. если захочется сделать другой клиент, то придется переписывать сервер. В подходе который я предложил, мне нравится, что сервер незнает, "кто" с ним работает. Толи это JS клиент, толи это win-клиент, толи вообще Flash клиент дергает с него данные.
Так же рассматривается такой вариант реализации как: server <-(JSON|XML)-> visualisation server <-(HTML)-> client
Таким образом мы всю логику выносим на server, и в зависимости от того какой вариант будет выбран, всё "визуализацию" выносим либо в "visualisation server" либо в JS клиент.

Опять же чего смущает в том, чтобы гнать с сервера весь хтмл в готовом виде, то, что это много трафика для клиента. Например, существует дерево, скажем с каталогами на сервере. Его нужно отобразить на клиенте. Если мы пригоним это всё в виде хтмл, то у нас получается для одного узла, как минимум:

<img src="corner.gif" class="corner"><div id="root_00" class="node00">name folder</div>

а если это в виде JSON:

{node_level: 00, node_name: "name folder"}

Итого: html - 88 байт, json - 43 байта.
Экономия как минимум на 50%. И это ещё не самый ярко выраженный пример.

спустя 40 минут [обр] MiRacLe(0/77)[досье]

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

Про дерево пример несколько неудачный - визуальную часть проще делать css-ом, т.е. img и class-ы в вашем примере будут лишними..., ну а вообще да, трафика больше.

спустя 59 минут [обр] Сергеев Александр(0/34)[досье]
Михаил[досье]ну чисто теоретически никто не мешает на сервере разнести "генерилку" и "оформлялку" данных. И для нового проекта нужно будет только "оформлялку" новую сделать.
На мой взгляд на сервере... удобнее что-ли с оформлением работать, хоть и данные на клиент будут избыточные уходить.
Но повторюсь — это лишь мое мое мнение.
спустя 22 минуты [обр] Михаил(0/17)[досье]
Значит ли всё вышесказанное Вами, то, что библиотеки типа ExtJS, использовать не стоит?
спустя 36 минут [обр] Thirteensmay(2/157)[досье]

Михаил[досье] С др. стороны, большие массивы гнать на клиента в любом случае глупо, а разницы между 30 и 60 КБ практически нет, в дополнение подумайте о затратах ресурсов на преобразование.

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

Если же конъюнктуру откинуть, то по большому счету разница лишь в переносе процесса с сервера на клиент, выгода от которого мягко говоря не бесспорна. Конечно, мы имеем небольшую экономию трафика, и слегка разгружаем сервер, но с др. стороны предъявляем к клиенту повышенные требования, а он у нас один, физически, как правило мы его не выбираем, он может оказаться достаточно простым и дешевым, что несомненно плюс, так что не факт что попрет. В тоже время серверы как правило нам более податливы, и даже если мощности одного недостаточно, всегда можно задействовать несколько и распределить задачи между ними.

Значит ли всё вышесказанное Вами, то, что библиотеки типа ExtJS, использовать не стоит ?

Нет, не значит. Пользуйте на здоровье там где это может быть выгодно.

спустя 17 минут [обр] Михаил(0/17)[досье]
Нет, не значит. Пользуйте на здоровье там где это может быть выгодно.
И где тогда это может быть выгодно? Использовать для создания нескольких "окошек" и двух "алертов" ? Тогда я смысла невижу тянуть такую большую библиотеку для этого. Есть более легкие. Например та же jQuery весит в 5 раз меньше (100кб против 500кб).
спустя 12 минут [обр] Thirteensmay(2/157)[досье]

Ну я ж откуда знаю где она у вас вылезет ? Вот придет допустим завтра к вам заказчик и скажет хочу ExtJS, плачу мегабабки, вот тут то и будет выгодно ;)

А вообще, ну почему сразу 2 алерта ? К примеру если задача - вполне себе не маленький портал в локалке немаленькой конторы, при этом хочется красоты и небольшие тормоза не в счет, то почему бы и нет.

спустя 2 часа [обр] Давид Мзареулян(0/1003)[досье]

> Сразу же хочу оговорится, что приложение будет достаточно сложным, и должно по сути напоминать винь прилаги.

> Использовать для создания нескольких "окошек" и двух "алертов" ?

Ну Вы уж определитесь. Для первого — Ext или вовсе Flex. Для второго — пара плагинов к jQuery.

спустя 5 часов [обр] Василий Свиридов(0/175)[досье]

http://jsonml.org/BST/ посмотрите на вот эту штуку - JS Databound templates на клиенте. Пишется HTML template в файл, который потом "компилируется" в JS кусок, и внутрь можно передавать параметры. Таким образом генерация идёт на клиенте, темплейты пишутся один раз, и между серевером и клиентом гоняются только данные.

Да и в HTML делать темплейт проще чем писать new Element("div", styles: {border: '1px solid red'}}).setText("blah") (MooTools)

спустя 5 минут [обр] Михаил(0/17)[досье]
Василий Свиридов[досье]
Завтра её покурю конечно, но на первый взгляд очень даже ничего.
Но тут конечно проблема в том, что это не сильно облегчает разработку всяких красивых формочек, попапов и тд и тп.
Powered by POEM™ Engine Copyright © 2002-2005