Разработка пользовательского интерфейса - JavaScript против Ajax

Question

Это вопрос дизайна.Я нахожусь между двумя стилями дизайна пользовательского интерфейса.

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

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

Как я вижу, используя Ajax, вы получаете:

• Проще поддерживать (+)
• Более длительное время отклика пользовательского интерфейса (-)

И только с JavaScript вы получаете

• Более быстрый отклик пользовательского интерфейса (+)
• Проще обрабатывать ошибки на стороне сервера (+)
• Труднее поддерживать (-)

Итак, есть несколько вещей, на которые я хотел бы обратить вниманиеуслышать ваши комментарии:

1. Мне не нравится использование Ajax, если у меня нет необходимости в фактических данных по требованию.Я не прав?

2. Существуют ли фреймворки / библиотеки, которые бы упростили управление генерирующим HTML-код JavaScript?

3. Есть ли другие плюсы /минусы двух подходов, которые я пропустил?

Спасибо,

Answer 1

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

Для больших наборов данных я рекомендую использовать ваши частичные представления для рендеринга HTMLна сервере, чтобы уменьшить накладные расходы в клиенте, как упомянуто @bobince.

Для отслеживания состояния на стороне клиента посмотрите Knockout по адресу http://www.knockoutjs.com.. Используется подход MVVM с моделями данных, привязанными к элементам пользовательского интерфейса, ипозволяет очень просто отправлять данные обратно на сервер через AJAX.Он работает с библиотекой шаблонов jquery.tmpl "из коробки", или вы можете интегрировать другую библиотеку предпочтений с небольшим усилием.

Что касается управления шаблонами, то достаточно просто хранить общие шаблоны в объекте,либо на сервере, который нужно получить с помощью удаленных данных, либо в объекте javascript на клиенте.

Answer 2

Существуют библиотеки шаблонов для JavaScript, если вы хотите принять в этом участие.В общем, я бы избегал ручного склеивания строк HTML из JS, если только в этом нет особой необходимости (например, в некоторых случаях для повышения производительности при работе с очень большими таблицами).

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

Вместо этого начните с методов DOM и используйте DOM-подобные библиотеки манипулирования содержимым, чтобы упростить его.Например, если вы используете jQuery, сделайте следующее:

$('<a>', {href: somelink, text: sometext})

и , а не this:

$('<a href="'+somelink+'">'+sometext+'</a>')  // insecure mess

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

При включении данных вНа странице вам, как правило, нужно будет указать временную метку, которую они сгенерировали в любом случае, так что, если браузер вернется на страницу через некоторое время без перезагрузки, браузер сможет обнаружить, что информация устарела, и выполнить командувверх XMLHttpRequest для его обновления.

Обычный вопрос, когда вы создаете содержимое своей страницы из данных с помощью клиентского JavaScript, вы собираетесь заполнить исходную статическую HTML-версию с сервера?Если это так, вы будете дублировать большую часть своей работы по генерации контента как на клиентском JS, так и на серверном языке (*).Если нет, то вы делаете контент невидимым для пользовательских агентов, не являющихся JS, включая поисковые системы.Имеет ли это значение для вас, как правило, зависит от того, что делает приложение (т.е. нужно ли для поиска и доступности?)

(*: если вы не можете использовать серверный JavaScriptиз что-то вроде node.js и повторно используйте ваш код генерации контента. Это все еще довольно редкий подход.)

Answer 3

У меня нет личного опыта по этому поводу, но Закрытие выглядит многообещающе. Возможность использования шаблонов на стороне сервера и клиента может вас заинтересовать. Вот что было сказано о , использующем его в Google + :

Отличительная особенность шаблонов Closure в том, что они могут быть скомпилированы как в Java, так и в JavaScript. Поэтому мы используем серверную часть Java для преобразования шаблонов в HTML, но мы можем сделать то же самое в клиентской части JavaScript для динамического рендеринга. Например, если вы введете URL-адрес страницы профиля напрямую, мы отобразим его на стороне сервера, но если вы перейдете в поток, скажем и перейдете на чью-то страницу профиля, мы сделаем это с помощью AJAX и отобразим его на стороне клиента, используя точно такой же шаблон.

Answer 4

Почему бы не посмотреть на интеграцию require.js в ваш рабочий процесс?Я не совсем уверен, как это будет работать с шаблонами, но в их конвейер включена возможность упаковать все необходимые файлы сценариев в один файл .js, который будет обслуживаться одним сервером запрос / ответ.