为什么HTML / JavaScript / CSS不是编译语言，他们会是？
为什么HTML / JavaScript / CSS没有成为编译语言（或者甚至可能合并成单一的编译语言）？ 如果浏览器运行“浏览器虚拟机”，html / javascript / css源代码可以编译成“浏览器字节码”。 它不会帮助开发者和用户很多吗？
我可以看到一些挑战：
-
如何处理现有网页的无数？ 使这个编译可选，所以如果你想你可以使用普通的旧的HTML。 如果你想喂一个浏览器与编译页面只使用.chtml例如。
-
search引擎如何索引页面？ 创build一个反编译器，将字节码反编译成精确的原始资源（例如像flash一样可以被反编译）。 或者search提供者可以使用相同的虚拟机并从那里获取他们需要的数据。
-
如何使它与所有浏览器兼容？ 有一个集中的开发人员（可以说w3c）开发这个虚拟机，然后每个浏览器将embedded它。
但是好处呢？
- 速度。
- 尺寸。
- 没有更多的“宽松”和“半正确”的HTML。 这是正确的或不会编译。
- 每个（支持的）浏览器看起来都一样。
如果不是字节码，那么至less有一些本地压缩，html可能不是最有效的数据存储方式。 我知道有gzip，但为什么每次在服务器上压缩页面，并在浏览器解压缩，如果我们可以压缩一次，并将其提供给浏览器？
那么是什么阻止我们走上这条路？（除此之外，还有很大的努力来完成这一切）？
啊，但JavaScript正在成为一种编译语言。 用TraceMonkey检查Firefox 3.5。 与你认识的浏览器相比，它的速度非常快。 确实，JS永远不会是C，但它是一个比C更dynamic的语言，并且在很多方面使它更具performance力和更强大。
就HTML而言，我不认为缺乏HTML的有效性对速度是一个巨大的损害。 我认为把视觉performance和操纵DOM的引擎需要变得更好（呃，IE，我正在看你的大方向…）。 CSS合规性需要变得更好，CSS本身需要变得更强大。 （用CSS 3人上车！）
但是我认为Firefox和Chrome的速度会越来越好，以至于人们真的会开始将其用于主stream应用程序开发。 这很有趣。 Adobe似乎将Flash作为其dynamic网页内容的平台销售，MSFT正在销售用于dynamic网页内容的Silverlight，而Google只是想要真正改进HTML和Javascript来显示dynamic网页内容。 而且Google迄今做得相当不错，我必须说…
将它们应用于JavaScript时，您的想法是有效的。 正如其他人所指出的那样，甚至现在有几个供应商试图将这些原则应用于JS。 谷歌已经宣布的Chrome操作系统将是这一领域的另一大举措。 但是，当涉及到（X）HTML和CSS时，我认为你的想法可能会被忽略。
万维网并不是一个错误的，不一致的应用程序平台，而是一个庞大而史无前例的相互关联的文档集合。 networking的强大之处在于，通常是僵化的（和易碎的）可视化布局以及通过JavaScript提供的日益复杂的页面内function。 使用（X）HTML对这些页面进行编码是浏览器和编写页面所需技术知识方面最广泛的受众群体的理想select。
越来越多的networking被用作应用程序平台 – 这是对这项技术的强大和令人兴奋的使用 – 但是我们不能忽视这样一个事实：这些Ajax驱动的“web 2.0”应用程序仅仅是具有扩展function的文档。 编译没有意义的文件和压缩已经发生（通过gzip之类的）。
更为实际的一点是，W3C以冰河的速度前进，浏览器厂商轮stream支持未完成规格的实验性function，并花费他们的甜蜜时间来支持其他规格，这些规格已经在桌面上使用了很多年。 整个过程就像放牧猫。 我不会屏住呼吸，让他们做出你很快提出的那种激进的改变。
由于HTML和CSS不是代码，因此无法编译。 谷歌浏览器的V8引擎确实将JS转换为字节码，期望其他渲染引擎也能跟上！
http://code.google.com/apis/v8/design.html
我们最近重新编写了一个我创build的php模板系统，使用minify将多个JS和CSS压缩成一个文件，看到我们的文件大小下降到原始组合大小的20％左右。 Minify也做gzip和caching，所以加速网站真的很棒。
http://code.google.com/p/minify/
总之，你不能编译HTML和CSS的非代码。 JS可以被编译，并开始成为，但这一切都取决于浏览器的感觉。
浏览器只需要支持networking标准即可。 浏览器越多，Web开发人员就越不会觉得头疼。 对于YouTube对IE6的大力支持，我非常满意。 我们需要更多的行动来支持networking向前迈进。
V8 javascript引擎（也embedded在谷歌浏览器中，但是它是开放源代码的，并且是免费的，因此欢迎您在下一个浏览器中使用它）将JavaScript编译为本地机器代码 – 当然，它是这样做的（像大多数现代编译器 – Java，C＃等等），而不是“提前”（就像Fortran在1954年做的那样，当时计算机太脆弱了，无法在执行过程中处理编译）。 如果其他优秀的JS引擎（如最新的Firefox和Safari中的引擎）没有这样做，我会感到惊讶。
看起来你不是主张“JavaScript作为一种编译语言”（因为它显然已经被编译，如果你使用的是一个好的JS引擎），而是“提前”编译它（只是当最现代语言基本上放弃了提前编译）。 把机器代码而不是可编译的代码放在线路上，听起来像是一个非常可怕的想法 – 尺寸大得多，支持一个CPU相对于另一个CPU困难，在正确的沙箱中进行安全噩梦等等），并没有太多补偿效益。
也就是说，如果你真的热衷于将机器代码推送到客户端，那么试试nativeclient （只要客户端是x86机器 – 忘记地球上的每一个智能手机，许多上网本，好老mac等）至less它承诺修复安全噩梦。 如果当你对nativeclient感到满意时，将一个即时编译器转换成提前的编译器是一个更容易的技术挑战（当然，如果你想继续使用Javascript来源而不是其他语言，当然）。
在这里看到关于此事的讨论
并非所有的理由都是有效的，但重要的一点是，除非你是Google，否则服务器端CPU周期比客户端周期更有价值：所以客户端更容易编译/优化是经常dynamic生成的HTML / JavaScript，而不是服务器。
肯
速度。
你假设parsingHTML需要很长的时间。 然而，与其他事物所需的时间相比，这个时间可能是微不足道的，例如在最终用户的窗口上布置文本所需的时间。
没有更多的“宽松”和“半正确”的HTML。 这是正确的或不会编译。
你已经得到了，使用[X]的HTML。
每个（支持的）浏览器看起来都一样。
你似乎在说应该只有一个浏览器，或者所有浏览器都支持它。
互联网标准不是通过一个单一的主体（W3C）实现某些东西并将其声明为标准来实现的。 相反，互联网标准是由多个独立的机构创build多个实现而发生的。 结果是：
- 有些人已经开发出了一些不标准的东西（即他们超越了标准）
- 有些人还没有开发出符合标准的东西（即他们落后于标准）
我认为你的想法是正确的，但是仍然没有办法强制执行一个标准。 因此，如果有一个不受支持的function，整个页面很可能不会显示任何内容。 在目前的设置中，关键信息仍然可以通过。
谷歌V8是许多新一代JavaScript引擎之一，它将JavaScript编译成伪代码，就像.NET在编译C＃时一样。 这里没什么神奇的。 尤其期待更多。 随着webapps越来越重，要求越来越高
HTML
HTML是非常多的XML。 DTD存在多种版本，开发人员可以随时进行检查。
CSS
CSS不是一种编程语言，但我同意“编译”CSS可以看到编译会压缩它。 然而，随着CSS的支持，以及任何CSS需要的基本攻击的数量，你永远不会设法没有错误地编译它。
JS
正如其他人所说，JS是成为一种编译语言，除了浏览器为你编译，而不是你自己。
