Загрузка веб-страницы исключительно из файла JavaScript

ProgramBox

Загрузка веб-страницы исключительно из файла JavaScript

Post author:admin
Запись опубликована:22 марта, 2023
Post category:Вопросы по программированию

#javascript #ecmascript-next

Вопрос:

У меня есть желание сделать что-то, чего я никогда не видел.

Я хотел бы создать веб-страницу, используя только javascript на стороне клиента. Например, я хочу поместить файл javascript в www.webpage.com/index.js и пусть браузер запустит этот файл javascript. В этом файле я буду генерировать html и css, но я бы хотел, чтобы точкой входа был исключительно этот файл javascript, а не HTML.

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

Я понимаю, что поисковые системы могут не знать, как индексировать страницы, где html генерируется клиентским javascript, но, опять же, я говорю, что они должны быть в состоянии это сделать и, вероятно, в конечном итоге сделают, если еще не сделали.

Я никогда не видел, чтобы это было сделано. Возможно ли это? Если да, не могли бы вы направить меня на любые ресурсы, охватывающие эту тему. Я ничего не смог найти.

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

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

3. Как сказал @CertainPerformance, невозможно запустить отдельный файл js в браузере (без расширений или дополнительного пользовательского ввода) . Чтобы минимизировать запросы html и загружать только один файл, вы могли бы использовать систему сборки для вставки всего вашего javascript между тегами скрипта в html-заглушке, но это означало бы, что вы не выиграете от кэширования браузера.

4. Дальнейшее обсуждение этого можно найти здесь .

5. Должен document ли объект быть доступен по умолчанию для скрипта, как это справедливо для традиционного HTML-документа, который обычно содержит скрипт? Если это так, то какой это будет документ ? Между сценарием и документом, который большинство людей любят писать, нет однозначной связи. Например, у вас могут быть документы SVG, которые запускают скрипты? Я имею в виду, если бы мы договорились о каком-то соглашении или прямо не определяли какие-либо window.document для таких «простых» скриптов, это могло бы сработать. Но в нынешнем виде вам сначала нужно предоставить документ.

Ответ №1:

Я написал много «страниц», которые просто

 <!DOCTYPE html>
<html>
   <head><meta charset="utf-8"></head>
   <body><script>

// The real stuff goes here, as inlined Javascript
// No need to make an extra roundtrip to the server
let d = document.body.appendChild(document.createElement("div"));
d.textContent = "Hello, world.";

   </body></script>
</html>

Таким образом, в основном единственное, что я помещаю в HTML-часть, — это исправление неправильного решения, принятого в прошлом (с кодировкой по умолчанию ISO-8859-1 вместо UTF-8).
Этот файл действительно является просто Javascript, с минимальной упаковкой, необходимой для его загрузки и выполнения браузером.

1. Точно, стандарты должны предлагать способ пропустить посредника: HTML. Файл javascript на стороне клиента, который генерирует html, должен быть такой же допустимой точкой входа, как и файл html в 2019 году.

2. @LonnieBest: «накладные расходы» действительно минимальны, и нет «дополнительного перехода на сервер»; браузер загружает и выполняет код. На мой взгляд, не стоило бы добавлять еще одно странное правило и, как следствие, несовместимость с браузером к и без того смущающе сложному набору правил ради такого небольшого выигрыша.

3. Я не вижу, чтобы сложность перевешивала преимущество здесь, потому что мне кажется очень простым разрешить javascript в качестве точки входа на веб-страницу. Движки уже знают, как запускать javascript, поэтому тот факт, что генерируется HTML-страница (вместо статического файла), должен быть прозрачным после того, как эта генерация произошла. Мало что меняется, кроме источника html. Мы все время делаем то же самое на стороне сервера. И сохранение этого перехода на сервер — не единственное преимущество. Я ненавижу создавать эти пустые html-файлы, и мне бы хотелось иметь возможность выполнить то же самое, не покидая свой JS.

4. @LonnieBest: В моем примере Javascript находится ВНУТРИ страницы… HTML-файл не является пустым, он содержит код в виде встроенного Javascript. Единственная «проблема» заключается в том, что основная часть файла (код javascript) завернута в крошечную пленку HTML. Никаких дополнительных поездок на сервер. Изменение стандарта браузеров таким образом, чтобы специально созданный ответ с сервера запускался непосредственно браузером вместо текущей обработки, было бы небольшим выигрышем. Также обратите внимание, что вы не хотите потерять возможность фактической загрузки файла Javascript вместо его выполнения.

5. Вам не нужно объяснять мне свой пример, я много раз использовал ту же технику. Не путайте мою защиту «того, как я хотел бы, чтобы все было» в качестве аргумента против вашего примера. Я понял. Я начал создавать веб-страницы в 1995 году. Я хочу иметь возможность выполнять то же самое, используя исключительно javascript; единственная «оболочка», которую я хочу, — это то, где javascript выполняет перенос. Я хочу, чтобы HTML находился внутри строки шаблона js, окруженной javascript! Я утверждаю, что файл javascript на стороне клиента должен быть поддерживаемой точкой входа на веб-сайт / веб-страницу. Кроме того, просмотр исходного кода все равно будет возможен.

Ответ №2:

Как упоминалось в другом месте, можно создать JavaScript, который также является допустимым файлом HTML.

 <!-- --><script>
console.log('Hello, World!');
// </script>

Это работает, потому что спецификация JavaScript имеет

B Дополнительные функции ECMAScript для веб-браузеров

B.1 Дополнительный синтаксис

B.1.3 HTML-подобные комментарии

…

SingleLineHTMLOpenComment ::
<!-- SingleLineCommentChars_opt

1. Это плохой дизайн —  используется с XML-документами, и если я не забыл о какой-то части спецификации, в которой говорится, что всякий раз, когда пользовательский агент сталкивается <!-- с ним, он должен предполагать, что это действительный HTML (в отличие от XML) документ, у нас есть двусмысленность — пользовательский агент можетправильно интерпретируйте ваш цитируемый фрагмент как application/xml ресурс (если no Content-Type предоставляется через HTTP или эквивалентный meta элемент).

2. И это только в тех случаях, когда тип содержимого не указан. Если указан тип содержимого, предполагая, что приведенный выше фрагмент является HTML-документом, для меня это выглядит как ошибка. Если origin говорит text/javascript , что это скрипт, и никакое количество хорошо разбираемых XML / HTML-подобных комментариев не исправит это, независимо от того, являются ли эти комментарии допустимыми в контексте файлов сценариев JavaScript или нет.

3. @amn Да, вы всегда должны указывать заголовок типа содержимого. Если вы хотите, чтобы страница обрабатывалась как интерактивное содержимое, подавайте ее с типом содержимого text / html. Легко устранить любую неоднозначность XML / HTML. Спецификация HTML разрешает маркеры комментариев раньше <!doctype html> .

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