Да, нужно уточнение! Вы сказали: «без backend'а будет туго». Да, это так и есть! Если потребуется изменить или добавить, например, какой-либо пункт меню или ещё что, то придётся редактировать каждый файл.
Из высказывания «без backend'а будет туго» следует, что лучшим решением будет завести сервер, который будет при каждом запросе генерировать необходимое содержимое, основываясь на запросе, данных подходящих под этот запрос и шаблоне. И это хорошо!
Но на самом ли деле нужен такой сервер?
Не достаточно ли этого? (файл index.html)
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
</head>
<body>
<script src="app.js"></script>
</body>
</html>
Конечно же оно может и не так радикально (так мало HTML) выглядеть, там могут быть естественно <template> или сразу подготовлены элементы, в которые будут вставляться данные, или сами элементы меняться. Суть в том, что это и есть шаблон, который меняется в одном месте! А в скрипте или в коде программы, описано, что и как показывать (например, это может зависеть от URL(в котором меняется только #hash, т. е. изменения внедряются тогда, когда происходит событие hashchange))
Данные тогда не нужно запихивать в HTML на сервере, поскольку данные в чистом виде могут быть загружены с сервера. Их легко обрабатывать и выводить (а не так, что сервер возвращает отрисованную страницу, и затем скрипт в клиентской части что-то ещё пытается делать с той страницей, и потом уже совсем не понятно, а это на клиенте поменялось или на сервере так отрисовалось.)
Чистые данные? Какие бы данные не были (справочные материалы или документация или товары в магазине или покемоны с их местоположением и временем появления или расписание транспорта или ещё что), то они должны быть представлены без разметки. Т. е. данные представлены так, что их легко анализировать (не из извлекать из DOM, который может сильно завязан на том, как данные визуально выглядят) Таким форматом может быть
markdown,
json-p,
json,
csv, или какой либо свой собственный бинарный формат (вам придётся написать свой парсер)
В большинстве случаев подходит JSON, но если вы захотели клиенту отдать сразу всю базу данных, то JSON может быть слишком многословен, и вы захотите отдавать данные в csv или бинарном формате!
Вот пример: (характерный код, обрабатывающий уже отрисованную страницу, код взят с сайта
govnokod.ru c незначительным изменением, вся проблема в том, что данные извлекаются из DOM)
var text_message = "";
for(var i = 0, i <= 5; i++) {
text_message += "\n Вопрос №" + (i + 1) + ": " + $('input[name=question_' + i +']:checked').parent().parent().parent().find(".title").text() + " Ответ: " + $('input[name=question_' + i +']:checked').val();
}
Вот тот же пример, но с чистыми данными!
var data = [];
var text_message = data.map(({ question, answer }, i) => `Вопрос №${i + 1}: ${question} Ответ: ${answer}`).join("\n");
Вы правда можете спросить, а какая разница, извлечь данные из DOM или скачать с сервера? Для того, чтобы их туда поместить, требуется лишняя операция по размещению их там! (Не говоря о том, что такой код получается запутанней) Более практичней было бы размещение в DOM <script> c необходимым объектом. Например, объект со статичными текстами приложения могут быть сразу вставлены на страницу, а затем по мере необходимости, когда пользователь выберет другой язык, будет подгружен скрипт со данными нового языка по принципу json-p, все такие скрипты могут быть заранее
сгенерированы!
Польза? Вместо того, чтобы всё время дёргать сервер, мы сразу получаем данные, которые во время сессии не поменяются. И даже интерактивные данные тоже, они должны быть чистыми! Пример сайта с таким подходом
https://transport.tallinn.ee/
Кто-то может сказать, что с таким #hash Google сайт не видит, это обман, всё работает нормально. На этом форуме обсуждалось про #hash!
https://javascript.ru/forum/misc/639...7parse%27.html
