богатый веб-клиент против тонкого веб-клиента - PullRequest
2 голосов
/ 30 января 2011

У меня есть одно дизайнерское решение.

В моем веб-приложении (ajax) нам нужно решить, куда поместить логику пользовательского интерфейса?

Должен ли он быть полностью загружен через javascript (чистая страница). и только данные приходят и уходят.

или

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

Какой вариант лучше? (скорость, простота разработки, независимость от платформы)

Спасибо.

Ответы [ 4 ]

2 голосов
/ 30 января 2011

IMO, это зависит главным образом от того, какое приложение это.Используется ли оно больше как настольное приложение?Тогда одна страница может работать хорошо.Наличие Ajax-клиента в значительной степени имеет те же недостатки, что и использование фреймов , но это не является большой проблемой в приложениях в стиле рабочего стола.

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

2 голосов
/ 30 января 2011

Я столкнулся с подобной дилеммой несколько месяцев назад. Как говорит Леннарт (выше), имеет смысл пойти на пижаму или подобную библиотеку, если ваше приложение более настольное. Кроме того, одним из самых больших преимуществ пижам является логически хорошо разделенный внутренний и внешний код. ИМО, это очень важно.

Если ваше приложение не похоже на приложение для настольного компьютера (как у нас), то многостраничность дает больше преимуществ, таких как одно изменение, не нарушает целостность приложения, не требует сложного обслуживания и т. Д. Возможно, вы захотите подумать, может ли ваш сервер приложений служить json и другой веб-сервер обслуживает статический контент и JS. Js запросит у сервера приложений json данные. Таким образом, нам удалось отделить внешний интерфейс и внутренний интерфейс. Далее мы выбрали mootools как js lib вместо пижамы. Конечно, это зависит от вашего вкуса и необходимости применения. Мы использовали шаблоны на стороне сервера шаблонов Python, но во время компиляции, а не во время выполнения, как обычный подход. Это должно было немного изменить наше мышление, но предлагало много преимуществ.

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

1 голос
/ 30 января 2011

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

КакойКурс, который вы выбираете, должен зависеть от поставленной задачи.Не все запросы должны обрабатываться одинаково.

0 голосов
/ 03 февраля 2011

Какой вариант лучше?(скорость, простота разработки, независимость от платформы)

Независимость от платформы, если вы имеете в виду кросс-браузерную совместимость, является ОГРОМНОЙ причиной для использования пижам, потому что код Python включает в себя инфраструктуру переопределения, которая обрабатывает всевы.Больше нет классов совместимости с JS.

В любом случае, пижама - это загрузка клиентского приложения, а затем использование json-rpc только для данных.Это потому, что он быстрее (после загрузки приложения), легче отделить сервер и клиент, проще в обслуживании, поскольку весь код пользовательского интерфейса находится в виджетах в одном месте.

Я видел такие вещи, как DokuWiki, которые используютPHP скрипт для обслуживания JavaScript, и моя первая мысль была "ПОЧЕМУ?"но это работает довольно хорошо, я думаю.Это, вероятно, имеет смысл, если у вас в основном статические страницы с небольшим количеством JS для оформления.

...