Как мне обрабатывать большие объемы HTML-данных в приложениях, насыщенных AJAX?

Question

Должен ли мой сервер возвращать данные JSON, а затем JavaScript анализировать их для непосредственного создания / рендеринга HTML, или же мой серверный код должен возвращать напрямую HTML, который может быть непосредственно размещен JavaScript.

Мысли

Answer 1

Я не фанат возврата сгенерированного HTML.ИМХО, я бы вернул JSON и использовал что-то вроде JQOTE 2 для обработки рендеринга.Пусть клиентские ресурсы справятся с этой работой.

(Примечание: JQOTE - удивительный инструмент!)

Answer 2

Визуализируйте код серверной стороны (например, как это делается в AJAX Rails), затем верните представление клиенту, где оно будет просто размещено.
Затем профилируйте ваш код.Если он окажется слишком медленным, верните JSON и подумайте, как сделать его на стороне клиента.

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

Answer 3

Я думаю, что если вам не понадобятся данные позже, например, для фильтрации, поиска на лету и т. д., затем вы должны вернуть HTML.

Answer 4

Нет правильного ответа; это зависит от ваших ожиданий.

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

OTOH, создание JSON, которое визуализируется клиентом с использованием некоторой библиотеки JS, может реально помочь вашему серверу снизить нагрузку. Вы распределяете работу по рендерингу для клиента, но это действительно берет контроль над вашими руками. Если у вас есть тяжелое решение JS и клиент не может обрабатывать JS (программы чтения с экрана, роботы поисковых систем и т. Д.), То сайт должен изящно деградировать или ожидать, что какая-то аудитория не сможет его просмотреть. Эта аудитория может быть незначительной для вас, но это то, что нужно знать. Пока вы хорошо управляете рендерингом (задайте минимальный размер для областей, значки ожидания и т. Д.), Вы можете сделать рендеринг на стороне клиента таким же плавным, как на стороне сервера (при сравнении шагов визуального рендеринга). Создание JSOn также дает вам больше гибкости, так как определяется больше интерфейсов или становятся важными другие клиенты без пользовательского интерфейса.

Answer 5

Я проголосую за ваш первый предложенный подход.

Размер сериализованных данных JSON меньше, чем (X) HTML, и ваш первый подход экономит много циклов ЦП, сетевого трафика, памяти и ускоряет работу вашего клиента, что заканчивается гибким пользовательским интерфейсом.

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

Answer 6

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

Если вам не легче, чем другому, переходите на сторону сервера. Я не могу представить себе обстоятельства, когда работа скриптового языка на стороне сервера была бы медленнее, чем в браузере javascript.

Если все, что вам нужно сделать, это визуализировать HTML, то, вероятно, гораздо проще сделать это напрямую с сервером (php). В противном случае вам нужно сначала преобразовать его в JSON с помощью php, а затем преобразовать обратно в JS. Это как минимум один дополнительный шаг и дополнительная работа для стороны javascript.

Answer 7

На мой взгляд, все дело в отзывчивости. Ваш сервер ВСЕГДА сможет обрабатывать данные быстрее, чем UA, однако разница между ними может быть незначительной. Если это так, то я бы рекомендовал передать JSON в UA, а затем использовать код на стороне клиента, чтобы выполнить грязную работу. Таким образом, у вас будет четкое разделение проблем между сервером и клиентом, что позволит вам в будущем доставлять данные JSON на разные конечные точки клиента без необходимости изменения кода на стороне сервера.

Однако, если при обработке данных на стороне клиента происходит существенное снижение производительности, возможно, имеет смысл доставлять HTML напрямую клиенту. ОДНАКО Я настоятельно рекомендую вам по-прежнему предоставлять JSON только для функции создания HTML-кода на стороне сервера (а не для UA), чтобы вы все равно могли доставлять данные JSON на несколько конечных точек, не изменяя основной код в будущее.

Answer 8

Это зависит от того, чего вы пытаетесь достичь.Если вы пишете мобильное приложение, вы можете сэкономить пропускную способность и работать с клиентскими шаблонами (например, Микро-шаблоны Джона Резига ).Если пропускная способность не так важна для вас, я бы просто использовал шаблоны на стороне сервера для генерации необходимого вам HTML.