为什么 HTML/JavaScript/CSS 不是编译语言，将来还会是吗？

Why HTML/JavaScript/CSS are not compiled languages and will they ever be?

提问by serg

Why HTML/JavaScript/CSS are not becoming compiled languages (or maybe even merge into a single compiled language)? What if browsers were running "Browser Virtual Machine" and html/javascript/css sources could by compiled to a "browser bytecode". Wouldn't it help developers and users a lot?

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

I can see a few challenges:

我可以看到一些挑战：

1. What to do with zillions of existing pages? Make this compilation optional, so if you want you can use plain old html. If you want to feed a browser with a compiled page just use .chtml for example.

2. How search providers would index pages? Make a decompiler that would decompile bytecode into exact original sources (for example like flash can be decompiled). Or search providers can use the same virtual machine and get data they need from there.

3. How to make it compatible with all browsers? Have one centralized developer (lets say w3c) to develop this virtual machine and then each browser would embed it.

1. 如何处理数以百万计的现有页面？将此编译设为可选，因此如果您愿意，可以使用普通的旧 html。例如，如果您想为浏览器提供编译页面，只需使用 .chtml 即可。

2. 搜索提供商如何索引页面？制作一个反编译器，将字节码反编译为精确的原始源（例如可以反编译闪存）。或者搜索提供商可以使用相同的虚拟机并从那里获取他们需要的数据。

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

But what about benefits:

但是好处呢：

1. Speed.
2. Size.
3. No more "loose" and "half-correct" html. It is either correct or won't compile.
4. Looks the same in every (supported) browser.

1. 速度。
2. 尺寸。
3. 不再有“松散”和“半正确”的 html。它要么正确，要么无法编译。
4. 在每个（支持的）浏览器中看起来都一样。

If not a bytecode then at least have some native compression going on, html probably is not the most efficient way of data storing. I know there is gzip but why to compress pages every time on a server and decompress in a browser if we can compress it once and feed it to a browser?

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

So what stops us from taking this road (well, besides a huge amount of effort to make it all happen)?

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

回答by Dave Markle

Ah, but Javascript IS becoming a compiled language. Check out Firefox 3.5 with TraceMonkey. It's insanely fast compared to um you-know-who's browser. It's true that JS will never be C, but it's a much more dynamic language than C is, and in many ways that makes it more expressive and powerful.

啊，但 Javascript 正在成为一种编译语言。使用TraceMonkey查看 Firefox 3.5 。与 um you-know-who 的浏览器相比，它的速度非常快。的确，JS 永远不会是 C，但它是一种比 C 更具动态性的语言，并且在许多方面使其更具表现力和功能。

As far as HTML goes, I don't think that the lack of validity of HTML is a huge detriment to speed. I think the engines that put together the visual representation and manipulate the DOM need to get a lot better (um, IE, I'm looking in your general direction...). CSS compliance needs to get better, and CSS itself needs to get more powerful. (Get on the bus with CSS 3 people!)

就 HTML 而言，我不认为 HTML 缺乏有效性对速度造成巨大损害。我认为将视觉表示组合在一起并操纵 DOM 的引擎需要变得更好（嗯，IE，我正在寻找你的总体方向......）。CSS 合规性需要变得更好，CSS 本身也需要变得更强大。（和 CSS 3 人一起上车！）

But I do think that speed is going to get better on Firefox and Chrome to such an extent that people really ARE going to start using it for mainstream application development. It's funny. Adobe seems to be selling Flash as their platform for dynamic web content, MSFT is selling Silverlight for dynamic web content, and Google just wants to really improve HTML and Javascript to display dynamic web content. And Google's doing pretty well at it so far, I must say...

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

回答by Simon

Since HTML and CSS aren't code they can't be compiled. Google Chrome's V8 engine does actually convert JS into byte code, expect other rendering engines to follow suit!

由于 HTML 和 CSS 不是代码，因此无法编译。Google Chrome 的 V8 引擎确实将 JS 转换为字节码，期待其他渲染引擎效仿！

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

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

We recently reworked a php template system I've helped create to use minify to compress multiple JS and CSS into one file each, seeing our file sizes drop to about 20% of the origial combined sizes. Minify also does gzip and caching so it's really amazing for speeding up websites.

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

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

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

In short you can't compile non-code, which HTML and CSS are. JS can be compiled and is starting to be, but all depends on what browsers feel like doing.

简而言之，您无法编译非代码，即 HTML 和 CSS。JS 可以编译并且正在开始编译，但这一切都取决于浏览器喜欢做什么。

Browsers just need to be on the ball regarding supporting web standards. The more browsers do this, the less headache us web developers have. I was quite happy with YouTube's very public drop of support for IE6. We need more action like that for the web to move forward.

浏览器只需要关注支持 Web 标准。浏览器执行此操作的次数越多，我们 Web 开发人员的头痛就越少。我对 YouTube 公开放弃对 IE6 的支持感到非常满意。我们需要更多类似的行动，让网络向前发展。

回答by Simon

Your ideas have validity when they are applied to JavaScript. As others have noted, to one degree or another several vendors are trying to apply those principles to JS even now. Another big step in this area will likely be the Chrome OS Google has announced. However, when it comes to (X)HTML and CSS I think your ideas may be missing the point.

当你的想法应用于 JavaScript 时，它们是有效的。正如其他人所指出的，在某种程度上，一些供应商甚至现在也在尝试将这些原则应用于 JS。这方面的另一个重大进步可能是谷歌宣布的 Chrome OS。但是，当谈到 (X)HTML 和 CSS 时，我认为您的想法可能没有抓住重点。

The world wide web is not a buggy and inconsistent application platform but a massive and unprecedented collection of interconnected documents. The power of the web is in the abstraction of the data from the often rigid (and breakable) visual layouts and increasingly complex in-page functionality largely provided via JavaScript. Encoding these pages in (X)HTML is ideal for making them accessible to the widest possible audience both in terms of browsers and in terms of technical knowledge required to author a page.

万维网不是一个有缺陷和不一致的应用程序平台，而是一个庞大且前所未有的互连文档集合。Web 的强大之处在于从通常僵化（且易损坏）的视觉布局和主要通过 JavaScript 提供的日益复杂的页面内功能中提取数据。在 (X)HTML 中对这些页面进行编码非常适合让最广泛的受众可以访问它们，无论是浏览器还是创作页面所需的技术知识。

More and more the web is being used as an application platform - which is a powerful and exciting use of this technology - but we cannot lose sight of the fact that these Ajax-driven "web 2.0" apps are merely documents with extended functionality. Compilation doesn't make sense for a document and compression is already happening (via gzip and the like).

越来越多的 Web 被用作应用程序平台——这是这项技术的一种强大而令人兴奋的用途——但我们不能忽视这样一个事实，即这些 Ajax 驱动的“Web 2.0”应用程序只是具有扩展功能的文档。编译对文档没有意义，并且已经在进行压缩（通过 gzip 等）。

On a more practical note, the W3C moves at a glacier's pace and browser vendors take turns between jumping-the-gun supporting experimental features in unfinished specs and taking their sweet time supporting other specs which have been on the table and in common usage for years. The whole processes is like herding cats. I wouldn't hold my breath for them to make the kind of radical changes you're proposing any time soon.

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

回答by Alex Martelli

The V8javascript engine (also embedded in Google Chrome, but it's open-source and liberally licensed so you're welcome to use it in the next browser you write!) does compile Javascript to native machine code -- of course, it does it "just in time" (like most modern compilers -- Java, C#, etc!), not "ahead of time" (like Fortran did in 1954 when computers were just too weak to handle compilation in the midst of execution). I'd be surprised if other good JS engines, like those in the very latest Firefox and Safari, didn't do the same.

在V8JavaScript引擎（还嵌入了谷歌浏览器，但它是开放源代码和许可不限所以欢迎您在你写的下一个浏览器使用它！）确实编译JavaScript来机器码-当然，它确实是“及时”（就像大多数现代编译器——Java、C# 等！），而不是“提前”（就像 Fortran 在 1954 年所做的那样，当时计算机太弱而无法在执行过程中处理编译）。如果其他优秀的 JS 引擎，比如最新的 Firefox 和 Safari 中的引擎，没有做同样的事情，我会感到惊讶。

Looks like you're not advocating "javascript as a compiled language" (since it obviously already IS compiled, if you're using a good JS engine), but rather "ahead-of-time" compilation for it (just when most modern languages are essentially abandoning ahead-of-time compilation). Pushing machine code rather than compilable code down the wire sounds like a mostly horrible idea -- much larger size, difficulties in supporting one CPU vs another, security nightmares in properly sandboxing it, etc, etc) with not much in term of compensating benefits.

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

That said, if you're really keen on pushing machine code to the client, try out nativeclient(as long as the client is an x86 machine - forget every smart phone on the planet, many netbooks, good old macs, etc) -- at least it promises a fix to the security nightmares. If and when you're happy with nativeclient, transforming a just-in-time compiler into an ahead-of-time one is a far easier technical challenge (if you want to keep using Javascript for the sources rather than other languages, of course).

也就是说，如果您真的很想将机器代码推送到客户端，请尝试使用nativeclient（只要客户端是 x86 机器——忘记地球上的每部智能手机、许多上网本、好的旧 Mac 等）——至少它承诺解决安全噩梦。如果您对 nativeclient 感到满意，那么将即时编译器转换为提前编译器是一项容易得多的技术挑战（当然，如果您想继续使用 Javascript 而不是其他语言作为源代码） ）。

回答by ChrisW

Speed.

速度。

You're assuming that it takes significant time to parse HTML. However it might be that that time is insignificant compared to the time required for something else, e.g. the time required to layout the text on the end-user's window.

您假设解析 HTML 需要花费大量时间。然而，与其他事情所需的时间相比，该时间可能微不足道，例如在最终用户的窗口上布局文本所需的时间。

No more "loose" and "half-correct" html. It is either correct or won't compile.

不再有“松散”和“半正确”的 html。它要么正确，要么无法编译。

You already get that, using [X]HTML.

你已经知道了，使用 [X]HTML。

Looks the same in every (supported) browser.

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

You seem to be saying that there should only be one browser, or that all browsers would support it equally.

您似乎在说应该只有一种浏览器，或者所有浏览器都会平等地支持它。

Internet standards don't happen by having a single body (the w3c) implementing something and declaring it a standard. Instead, internet standards happen by having multiple independent bodies creating multiple implementations. A consequence is:

互联网标准不会通过让一个机构（w3c）实施某事并将其宣布为标准来实现。相反，互联网标准是通过让多个独立机构创建多个实现来实现的。一个后果是：

• Some people have developed something that isn't standard yet (i.e. they're ahead of the standard)
• Some people haven't yet developed something that is standard (i.e. they're behind of the standard)

• 有些人开发了一些还不是标准的东西（即他们领先于标准）
• 有些人还没有开发出标准的东西（即他们落后于标准）

回答by Ken Smith

See herefor a previous discussion on the matter

有关此问题的先前讨论，请参见此处

Not all of the reasons given are necessarily valid, but one important one is that, unless you're Google, server-side CPU cycles are a lot more valuable than client-side cycles: so it's easier to have the client compile/optimize what is quite often dynamically generated HTML/JavaScript, rather than the server.

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

Ken

肯

回答by Alex S

I think your idea is sound, however there's still no way to enforce a standard. Thus if there was a non-supported feature, there's a good chance the entire page would simply not display anything. In the current setup, critical information can still be passed.

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

回答by Scott Evernden

Google V8, which is one of many new-generation javascript engines 'compiles' javascript into pseudocode, much like .NET 'compiles' c# on the fly. Nothing magical here. Expect more of it esp. as webapps get heavier and more demanding

Google V8是众多新一代 javascript 引擎之一，它可以将 javascript '编译'成伪代码，就像 .NET 即时'编译'c# 一样。这里没有什么神奇的。期待更多，尤其是。随着 web 应用程序变得越来越重，要求越来越高

回答by Darko Z

HTML

HTML

HTML is pretty much XML. DTD'd exist for various versions and developers can check against that at any time.

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

CSS

CSS

CSS is not a programming language, however I do agree that "compiled" CSS could work seeing as compilation would compress it. However with the support that CSS has and with the number of essential hacks any CSS needs to have, you'd never manage to compile it without errors.

CSS 不是一种编程语言，但是我确实同意“编译”的 CSS 可以工作，因为编译会压缩它。然而，有了 CSS 的支持以及任何 CSS 需要拥有的基本技巧的数量，您将永远无法在没有错误的情况下编译它。

JS

JS

As others have mentioned, JS IS becoming a compiled language except the browser compiles it for you and not you yourself.

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