专门从 JavaScript 文件直接加载网页答案

【问题标题】：Loading a Web Page Directly from a JavaScript File Exclusively专门从 JavaScript 文件直接加载网页
【发布时间】：2019-09-11 08:57:15
【问题描述】：

我渴望做一些我从未见过的事情。

我想创建一个网页只使用客户端javascript。例如，我想将一个 javascript 文件放在 www.webpage.com/index.js 并让浏览器运行该 javascript 文件。在该文件中，我将生成 html 和 css，但我希望入口点仅是该 javascript 文件而不是 HTML。

如果这是不可能的，我认为应该是。很多时候，我的 html 文件只是一个标题、标题和一个空正文。在这种情况下，必须先下载一个 html 文件，然后浏览器才能下载真正用内容填充空正文的 javascript 文件，这很愚蠢。

我意识到搜索引擎可能不知道如何索引由客户端 javascript 生成的 html 的页面，但我再说一遍，他们应该能够做到这一点，如果他们还没有的话，最终可能会做到。

我从未见过这样做过。这可能吗？如果是这样，请您指导我访问涵盖该主题的任何资源。我找不到任何东西。

【问题讨论】：

不可能，除非你想做一些事情，比如指示用户打开他们的浏览器控制台并复制粘贴到代码中
我预测有一天，这将成为标准的一部分。它节省了到服务器的额外行程。
正如@CertainPerformance 所说，无法在浏览器中运行独立的 js 文件（无需扩展或额外的用户输入）。为了最大限度地减少 html 请求并只下载单个文件，您可以使用构建系统在 html 存根中的脚本标记之间插入所有 javascript，但这意味着您不会从浏览器缓存中受益。
可以在here找到更多讨论。
脚本是否应该默认使用document 对象，因为它对于通常包含脚本的传统 HTML 文档来说是正确的？如果是这样，那会是什么文档？脚本和大多数人喜欢编写脚本的文档之间没有一对一的关系。例如，您可以拥有运行脚本的 SVG 文档？我的意思是，如果我们同意一些约定或完全不为此类“基本”脚本定义任何window.document，它可以工作。但就目前而言，现在您必须先提供一份文件。

标签： javascript ecmascript-next

【解决方案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，只需最少的包装即可让浏览器加载和执行它。

【讨论】：

确切地说，标准应该提供一种跳过中间人的方法：HTML。生成 html 的客户端 javascript 文件应该与 2019 年的 html 文件一样有效。
@LonnieBest：“开销”确实很小，没有“额外的服务器之旅”；浏览器加载并执行代码。在我看来，在已经非常复杂的规则集上添加另一个奇怪的规则和随之而来的浏览器不兼容以获取如此小的收益是不值得的。
我看不出这里的复杂性超过了好处，因为对我来说，允许 javascript 作为网页的入口点似乎很简单。引擎已经知道如何运行 javascript，因此生成 HTML 页面（而不是静态文件）这一事实在生成之后应该是透明的。除了 html 的来源，没有太大变化。我们一直在服务器端做同样的事情。节省到服务器的旅行并不是唯一的好处。我讨厌创建那些空的 html 文件，我希望能够在不离开我的 JS 的情况下完成同样的事情。
@LonnieBest：在我的示例中，Javascript 在页面内... HTML 文件不是空的，它包含作为内联 Javascript 的代码。唯一的“问题”是文件的内容（javascript 代码）被包裹在一小块 HTML 中。无需额外前往服务器。更改浏览器标准，以便浏览器直接运行来自服务器的特制回复，而不是当前的处理，这将是一个小小的收获。另请注意，您不想失去实际下载 Javascript 文件而不是执行它的能力。
您不必向我解释您的示例，我已经多次使用相同的技术。不要把我提倡的“我希望事情变成这样”作为反对你的例子的论据。我知道了。我从 1995 年开始制作网页。我希望能够只使用 javascript 来完成同样的事情；我想要的唯一“包装器”是javascript进行包装的地方。我希望 HTML 位于由 javascript 包围的 js 模板字符串中！我提倡客户端 javascript 文件应该是网站/网页的受支持入口点。此外，仍然可以查看源代码。

【解决方案2】：

作为mentioned elsewhere，可以创建同时也是有效 HTML 文件的 JavaScript。

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

这是因为the JavaScript spec 有

B 用于 Web 浏览器的额外 ECMAScript 功能

B.1 附加语法

B.1.3 类 HTML 注释

...

SingleLineHTMLOpenComment ::
<!-- SingleLineCommentChars_opt

【讨论】：

那是糟糕的设计—— 用于 XML 文档，除非我忘记了某些规范的某些部分，即每当用户代理遇到 <!--它应该假设它是一个有效的 HTML（而不是 XML）文档，我们手上有歧义——用户代理可能会正确地将您引用的 sn-p 解释为 application/xml 资源（如果没有通过 HTTP 提供 Content-Type或等效的meta 元素）。
并且仅在没有提供内容类型的情况下。如果提供了内容类型，假设上面的 sn-p 是一个 HTML 文档，对我来说就像一个错误。如果 origin 显示 text/javascript，那么这是一个脚本，并且无论这些 cmets 在 JavaScript 脚本文件的上下文中是否有效，都无法解决这个问题。
@amn 是的，您应该始终指定内容类型标头。如果您希望页面被视为交互式内容，请使用 text/html 内容类型来提供它。很容易解决任何 XML/HTML 歧义。 HTML 规范允许在 <!doctype html> 之前使用注释标记。
这不符合我的“仅使用客户端 javascript”标准，因为此解决方案需要 HTML 包装器。但是，当某事不可能时，您能做的最好的事情就是想出最接近的替代方案。你以聪明的方式做到了这一点。