Коли JavaScript повинен генерувати HTML?

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

Однак я бачив багато JS-коду, який генерує нарікання HTML, включаючи цілі форми та важкі для контенту модальні діалоги. Загалом, який метод вважається найкращою практикою? За яких обставин слід використовувати JavaScript для створення HTML, а коли він не повинен?

Кожного разу, коли я стикався з важким поколінням HTML в JavaScript, він лежав виключно в автономному плагіні інтерфейсу користувача. Це має сенс, оскільки дозволяє інкапсулювати весь плагін в один файл .js (+ a .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!" магія, відбуваються лише дві можливі речі:

1. Код елемента вводиться в div (bad) або
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 для структурування нашої клієнтської та рульової панелей для рендерингу нашого JSON у шаблони, які переходять на сторінку. Справді це дуже добре, і ми підходимо до закриття нашого першого додатка, який використовує його, і ми вирішимо ще більший проект у майбутньому.

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

Я генерую html-код у jquery, тому що я використовую портлет і після виконання коду jsp мені потрібно зробити цикл із кодом html, що я не можу потрапити у java for цикл із деяким кодом javascript у межах. Таким чином, я рендерую java arraylist в масиві javascript і використовую рядки для створення html.