为什么HTML / JavaScript / CSS不是编译语言，它们会是什么？

Question

为什么HTML / JavaScript / CSS不会成为编译语言（或者甚至可能合并为一种编译语言）？如果浏览器运行“浏览器虚拟机”和html / javascript / css源可以通过编译为“浏览器字节码”怎么办？它不会对开发人员和用户有很大帮助吗？

我可以看到一些挑战：

1. 如何处理数以万计的现有网页？使这个编译可选，所以如果你想要你可以使用普通的旧HTML。如果您想为浏览器提供已编译的页面，请使用.chtml，例如。

2. 搜索提供商如何索引网页？制作一个可以将字节码反编译为精确原始源的反编译器（例如像flash一样可以反编译）。或者搜索提供商可以使用相同的虚拟机并从中获取所需的数据。

3. 如何使其与所有浏览器兼容？有一个集中开发人员（比方说w3c）来开发这个虚拟机，然后每个浏览器都会嵌入它。

但是好处呢？

1. 速度
2. 尺寸。
3. 没有更多“松散”和“半正确”的HTML。它是正确的还是不会编译。
4. 在每个（支持的）浏览器中看起来都一样。

如果不是字节码，那么至少要进行一些本机压缩，html可能不是最有效的数据存储方式。我知道有gzip但是为什么每次在服务器上压缩页面并在浏览器中解压缩，如果我们可以压缩一次并将其提供给浏览器？

那么是什么阻止我们走这条路（好吧，除了付出巨大努力才能实现这一切）？

Answer 1

啊，但Javascript正在成为一种编译语言。使用TraceMonkey查看Firefox 3.5。与你知道谁的浏览器相比，这是非常快的。确实，JS永远不会是C，但它是一种比C更动态的语言，并且在很多方面使它更具表现力和强大。

就HTML而言，我认为HTML缺乏有效性并不会对速度产生巨大损害。我认为将视觉表示和操作DOM组合在一起的引擎需要更好（嗯，IE，我正朝着你的大方向看......）。 CSS合规性需要变得更好，CSS本身需要变得更强大。 （搭乘CSS 3人上车！）

但我确实认为Firefox和Chrome的速度会越来越好，以至于人们真正开始将它用于主流应用程序开发。这很有趣。 Adobe似乎将Flash作为动态Web内容的平台销售，MSFT正在销售用于动态Web内容的Silverlight，而Google只是想真正改进HTML和Javascript以显示动态Web内容。到目前为止谷歌的表现相当不错，我必须说......

Answer 2

由于HTML和CSS不是代码，因此无法编译。谷歌Chrome的V8引擎确实将JS转换为字节码，期望其他渲染引擎也跟风！

http://code.google.com/apis/v8/design.html

我们最近重新设计了一个我帮助创建的php模板系统，使用minify将多个JS和CSS压缩成一个文件，看到我们的文件大小下降到原始组合大小的20％左右。 Minify也可以进行gzip和缓存，因此加速网站真的很棒。

http://code.google.com/p/minify/

简而言之，您无法编译HTML和CSS所使用的非代码。 JS可以编译并开始使用，但这完全取决于浏览器的用途。

浏览器需要关注支持Web标准。浏览器越多，Web开发人员就越不会头疼。我非常高兴YouTube公开支持IE6。我们需要采取更多行动来推动网络前进。

Answer 3

您的想法在应用于JavaScript时有效。正如其他人所指出的那样，在某种程度上，即使是现在，也有几家供应商试图将这些原则应用于JS。这个领域的另一个重要步骤可能是谷歌宣布的Chrome OS。但是，当谈到（X）HTML和CSS时，我认为你的想法可能会忽略这一点。

万维网不是一个错误且不一致的应用程序平台，而是一个庞大且前所未有的互连文档集合。 Web的强大之处在于从通常严格（且易碎）的可视化布局中抽象出数据，并且通过JavaScript主要提供越来越复杂的页内功能。在（X）HTML中编码这些页面非常适合在浏览器和创作页面所需的技术知识方面使最广泛的受众可以访问这些页面。

越来越多的网络被用作应用程序平台 - 这是对这项技术的强大而令人兴奋的使用 - 但我们不能忽视这些Ajax驱动的“web 2.0”应用程序仅仅是扩展的文档这一事实功能。编译对文档没有意义，压缩已经发生（通过gzip等）。

更实际的是，W3C以冰川的速度移动，浏览器供应商轮流在未完成的规格中支持实验性功能，并花时间支持已经摆在桌面上的其他规格使用多年。整个过程就像放牧猫。我不会屏住呼吸让他们尽快做出你提出的那种激进的改变。

Answer 4

V8 javascript引擎（也嵌入在谷歌浏览器中，但它是开源的，并且获得许可，因此欢迎您在下一个浏览器中使用它！）确实将Javascript编译为本地机器代码 - - 当然，它“及时”（像大多数现代编译器一样 - Java，C＃等！），而不是“提前”（就像Fortran在1954年做的那样，计算机太弱而无法处理编译在执行中）。如果其他优秀的JS引擎（如最新的Firefox和Safari中的那些引擎）没有做同样的事情，我会感到惊讶。

看起来你并不是在倡导“javascript作为一种编译语言”（因为它显然已经编译好了，如果你使用的是一个好的JS引擎），而是“为它提前编译”（只是当大多数现代语言基本上放弃了提前编译时。推送机器代码而不是可编辑的代码听起来像一个非常可怕的想法 - 更大的尺寸，支持一个CPU与另一个CPU的困难，正确沙盒中的安全噩梦等等）与补偿利益没有多少。

那就是说，如果你真的热衷于将机器代码推送到客户端，请尝试nativeclient（只要客户端是x86机器 - 忘记这个星球上的每一部智能手机，很多上网本，不错旧的macs等） - 至少它承诺修复安全噩梦。如果您对nativeclient感到满意，将即时编译器转换为提前编译器是一个更容易的技术挑战（如果您希望继续使用Javascript作为源而不是其他语言，当然）。

Answer 5

有关此事的先前讨论，请参阅here

并非所有给出的理由都必然有效，但重要的一点是，除非您是Google，否则服务器端CPU周期比客户端周期更有价值：因此客户端编译更容易/优化通常动态生成的HTML / JavaScript，而不是服务器。

肯

Answer 6

  

速度

您假设解析HTML需要很长时间。然而，与其他东西所需的时间相比，这个时间可能是微不足道的。在最终用户窗口上布置文本所需的时间。

  

没有更多“松散”和“半正确”的HTML。它是正确的还是不会编译。

你已经使用[X] HTML获得了它。

  

在每个（支持的）浏览器中看起来都一样。

您似乎在说应该只有一个浏览器，或者所有浏览器都会同样支持它。

互联网标准不是通过让一个机构（w3c）实现某些东西并将其声明为标准来实现的。相反，互联网标准通过让多个独立机构创建多个实现来实现。结果是：

• 有些人已经开发出一些不标准的东西（即它们超出了标准）
• 有些人还没有开发出标准的东西（即他们落后于标准）

Answer 7

我认为你的想法很合理，但仍无法执行标准。因此，如果存在不受支持的功能，则整个页面很可能不会显示任何内容。在当前设置中，仍然可以传递关键信息。

Answer 8

Google V8，这是许多新一代javascript引擎之一“将javascript编译成伪代码”，就像.NET“动态编译”c＃一样。这里没什么神奇的。特别期待更多。随着webapps变得更重，更苛刻

Answer 9

HTML

HTML几乎就是XML。各种版本都存在DTD，开发人员可以随时对其进行检查。

CSS

CSS不是一种编程语言，但是我同意“编译”的CSS可以看到编译会压缩它。然而，有了CSS的支持以及任何CSS需要的基本黑客的数量，你永远不会设法编译它没有错误。

JS

正如其他人所提到的，JS正在成为一种编译语言，除了浏览器为你编译它而不是你自己。