Когда JavaScript должен генерировать HTML?

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

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

Всякий раз, когда я сталкивался с тяжелой генерацией HTML в javascript, это было почти исключительно в автономном плагине пользовательского интерфейса. Это имеет смысл, поскольку позволяет инкапсулировать весь плагин в один файл .js (+ .css для настройки стилей), что позволяет легко использовать его повторно, распространять и не зависеть от инфраструктуры, используемой в приложении.

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

Я думаю, что проблема в том, что вы сравниваете чисто написанные шаблоны на стороне сервера с плохо написанными специальными средствами генерации HTML на стороне клиента. Конечно, чисто написанный код легче читать, поддерживать и отслеживать.

Вы называете код на стороне клиента «насыпи HTML», но, конечно, это тот же самый HTML, где бы он ни создавался. «Курган» - это действительно большой кусок кода.

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

Но это зависит от того, что именно вы делаете, предпочитаете ли вы JS своей серверной среде, какое шаблонное решение вы предпочитаете и т. Д.

Существует тенденция использовать шаблоны на стороне клиента, в крайнем случае вы будете иметь сервер, предоставляющий только RESTful API, например, в формате JSON, при выполнении всей визуализации на стороне клиента. Преимущество этого подхода заключается в том, что код и шаблоны JS являются статическими ресурсами, которые можно кэшировать, передавать и распространять через CDN. Что нельзя сделать, если у вас есть динамический HTML-код на стороне сервера. Кроме того, возврат только данных из RESTful API в облегченном формате требует гораздо меньше ресурсов на стороне сервера, что ускоряет ответ. Кроме того, он легче переносит сеть, что снова делает его быстрее. Таким образом, вы можете получить очень отзывчивое приложение с низкой задержкой даже на медленных соединениях, таких как 3G. Таким образом, этот подход популярен для мобильных страниц и приложений.

Есть многочисленные библиотеки , реализующие шаблоны JS, один из популярных из них являются чисто , Усы и dust.js . Позже используется LinkedIn, они описали преимущества в своей статье «Оставить JSP в мусоре: переместить LinkedIn в клиентские шаблоны dust.js» .

Преимущество генерации HTML на клиенте заключается в том, что вы перекладываете работу рендеринга на каждого клиента, который обычно простаивает в ожидании ответа. Освободить больше серверных ресурсов для доставки только данных JSON и статического контента (HTML, JS и CSS).

Мы делаем веб-приложение, которое генерирует исключительно HTML с Javascript. 87% обращений к серверу - это данные JSON, статический контент обычно загружается один раз, затем из кеша браузера.

Но вы не можете использовать его - по крайней мере, не легко - если вам нужен SEO. Или если вы нацелены на население, у которого отключен Javascript, но я не уверен, что этот по-прежнему актуален для Youtube, Twitter, Facebook, Gmail, ... естественно заставляя людей включать его.

Что касается динамической загрузки страниц, следует понимать, что за всем этим «JQuery AJAX Cloud!» магия, только две возможные вещи происходят:

1. Код элемента внедряется в div (плохо), или
2. Контент загружается в iframe (лучше, но это не то же самое ...)

Что касается исходного вопроса, я создаю HTML-контент только через Javascript, когда создаю какое-то веб-приложение, которое читает данные XML или JSON, хранящиеся на сервере, и оно сильно меняется.

Не имеет смысла загружать статический контент на страницу с помощью Javascript, поскольку всегда есть вероятность, что он не будет загружен правильно, или клиент отключит его («возьмите эту надоедливую рекламу!»). Кроме того, это действительно затрудняет изменение содержимого HTML, когда оно скрыто внутри уродливой document.write()или цепочки document.createElement().

Итак, вы правы; либо введите необработанный HTML-код, либо, если необходимо содержимое динамического вывода, используйте серверный сценарий для вывода того, что необходимо. Используйте Javascript для внедрения HTML, только если сайт предназначен для работы без подключения к Интернету или аналогичного случая.

И последнее замечание: если вы хотите внедрить xmlhttprequests, то есть AJAX, в веб-сайт, вероятно, лучший / самый безопасный способ сделать это - сохранить данные в формате данных (например, XML), загрузить и вывести их соответствующим образом. на клиенте. document.writeи на element.innerHTMLсамом деле это не лучший способ манипулировать контентом, и он неизбежно вызовет потенциальные головные боли в будущем (почему этот скрипт не работает? Мой сломанный <i>тег выделяет все курсивом! и т. д.).

Моя мантра об этом такова: когда легче и никто не заботится о разметке.

Вы также можете использовать оба и определить предел, когда слишком сложно заботиться о разметке, и вы предпочитаете сосредоточиться на дереве DOM. Например, форма с динамическими строками (например, «добавить другое вложение»), вам, вероятно, понадобится форма в HTML, кнопка «добавить строку» и кнопка отправки ... вы, вероятно, не хотите создавать HTML с вашим серверным языком или что-то.

Другим эмпирическим правилом может быть повторное использование. Если ваше решение может быть применено к другим проблемам на стороне клиента, инкапсулируйте его в js.

Мы создаем одностраничные приложения (например, Google Mail), и в наших приложениях буквально нет генерации HTML на стороне сервера. Вместо этого мы используем Backbone.js для структурирования клиентской части и Handlebars для рендеринга нашего JSON в шаблоны, которые идут на страницу. Он действительно работает очень хорошо, и мы подходим к концу нашего первого приложения, которое его использует, и в будущем мы займемся еще большим проектом.

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

Я генерирую html-код в jquery, потому что я использую портлет, и после выполнения jsp-кода мне нужно создать цикл с html-кодом, чтобы я не мог попасть в цикл java for с некоторым кодом javascript внутри. Поэтому я рендеринг Java-массив в массиве JavaScript и использование строк для генерации HTML.