为什么 HTML/JavaScript/CSS 不是编译语言，而且它们将来会是编译语言吗？
为什么 HTML/JavaScript/CSS 没有成为编译语言（或者甚至合并为单一编译语言）？ 如果浏览器运行“浏览器虚拟机”并且 html/javascript/css 源可以编译为“浏览器字节码”会怎样？ 是不是对开发者和用户都有很大的帮助呢？
我看到了一些挑战：
如何处理无数的现有页面？ 将此编译设置为可选，因此如果您愿意，可以使用普通的旧 html。 如果您想向浏览器提供编译后的页面，只需使用 .chtml 即可。
搜索提供商如何索引页面？ 制作一个反编译器，将字节码反编译为精确的原始源（例如可以反编译闪存）。 或者搜索提供商可以使用相同的虚拟机并从那里获取所需的数据。
如何使其兼容所有浏览器？ 让一个集中式开发人员（比如说 w3c）来开发这个虚拟机，然后每个浏览器都会嵌入它。
但好处呢：
- 速度。
- 尺寸。
- 不再有“松散”和“半正确”的 html。 它要么是正确的，要么无法编译。
- 在每个（支持的）浏览器中看起来都一样。
如果不是字节码，那么至少要进行一些本机压缩，html 可能不是最有效的数据存储方式。 我知道有 gzip，但是如果我们可以压缩一次并将其提供给浏览器，为什么每次都在服务器上压缩页面并在浏览器中解压缩呢？
那么是什么阻止我们走这条路（嗯，除了付出巨大的努力来实现这一切之外）？
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?
I can see a few challenges:
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.
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.
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.
But what about benefits:
- Speed.
- Size.
- No more "loose" and "half-correct" html. It is either correct or won't compile.
- Looks the same in every (supported) browser.
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?
So what stops us from taking this road (well, besides a huge amount of effort to make it all happen)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我认为你的想法是合理的，但是仍然没有办法执行标准。 因此，如果存在不受支持的功能，则整个页面很可能不会显示任何内容。 在当前设置下，仍然可以传递关键信息。
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.
Google V8，它是众多新一代“编译”JavaScript 引擎之一javascript 转换为伪代码，就像 .NET 动态“编译”c# 一样。 这里没什么神奇的。 期待更多，尤其是。 随着网络应用程序变得越来越重、要求越来越高
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
HTML
HTML 几乎就是XML。 DTD 存在各种版本，开发人员可以随时进行检查。
CSS
CSS 不是一种编程语言，但是我确实同意“编译”CSS 可以工作，因为编译会压缩它。 然而，有了 CSS 的支持以及任何 CSS 都需要的大量基本技巧，你永远不可能在没有错误的情况下编译它。
JS
正如其他人提到的，JS 正在成为一种编译语言，只不过浏览器为您而不是您自己编译它。
HTML
HTML is pretty much XML. DTD'd exist for various versions and developers can check against that at any time.
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.
JS
As others have mentioned, JS IS becoming a compiled language except the browser compiles it for you and not you yourself.
啊，但是 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 内容。 我必须说，到目前为止，谷歌在这方面做得相当不错......
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.
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!)
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...
当您的想法应用于 JavaScript 时，它们是有效的。 正如其他人所指出的，即使在某种程度上，一些供应商现在也在尝试将这些原则应用到 JS 中。 该领域的另一重大举措可能是谷歌宣布的 Chrome 操作系统。 然而，当谈到 (X)HTML 和 CSS 时，我认为您的想法可能没有抓住重点。
万维网不是一个有缺陷且不一致的应用程序平台，而是一个巨大且前所未有的互连文档的集合。 Web 的力量在于从通常僵化（且易碎）的视觉布局和主要通过 JavaScript 提供的日益复杂的页内功能中抽象出数据。 使用 (X)HTML 对这些页面进行编码非常适合让尽可能广泛的受众（无论是在浏览器方面还是在创作页面所需的技术知识方面）访问这些页面。
Web 越来越多地被用作应用程序平台 - 这是该技术的强大且令人兴奋的用途 - 但我们不能忽视这样一个事实：这些 Ajax 驱动的“web 2.0”应用程序仅仅是具有扩展功能的文档。 编译对于文档来说没有意义，压缩已经发生（通过 gzip 等）。
从更实际的角度来看，W3C 的发展速度非常缓慢，浏览器供应商轮流着急于支持未完成规范中的实验性功能，或者花点时间支持其他已经摆在桌面上并已广泛使用多年的规范。 。 整个过程就像放猫一样。 我不会屏住呼吸让他们很快做出你所提议的那种彻底的改变。
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.
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.
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).
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.
由于 HTML 和 CSS 不是代码，因此无法编译。 Google Chrome 的 V8 引擎确实将 JS 转换为字节码，希望其他渲染引擎也能效仿！
http://code.google.com/apis/v8/design.html
我们最近重新设计了我帮助创建的一个 php 模板系统，以使用 minify 将多个 JS 和 CSS 分别压缩到一个文件中，看到我们的文件大小下降到原始组合大小的 20% 左右。 Minify 还支持 gzip 和缓存，因此它对于加速网站速度确实非常惊人。
http://code.google.com/p/minify/
简而言之，您可以t 编译非代码，如 HTML 和 CSS。 JS 可以编译并且已经开始了，但这一切都取决于浏览器想要做什么。
浏览器只需要在支持网络标准方面保持警惕即可。 这样做的浏览器越多，我们网络开发人员的头痛就越少。 我对 YouTube 公开放弃对 IE6 的支持感到非常高兴。 我们需要更多类似的行动来推动网络向前发展。
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!
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.
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.
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.
V8 javascript 引擎（也嵌入在 Google Chrome 中，但它是开源的并获得自由许可所以欢迎您在您编写的下一个浏览器中使用它！）确实将 Javascript 编译为本机机器代码 - 当然，它“及时”执行（就像大多数现代编译器 - Java、C# 等！） ，而不是“提前”（就像 Fortran 在 1954 年所做的那样，当时计算机太弱，无法在执行过程中处理编译）。 如果其他优秀的 JS 引擎（例如最新的 Firefox 和 Safari 中的引擎）没有这样做，我会感到惊讶。
看起来你并不提倡“javascript作为编译语言”（因为如果你使用一个好的JS引擎，它显然已经被编译了），而是“提前”编译它（就在大多数现代的时候）语言基本上放弃了提前编译）。 推送机器代码而不是可编译代码听起来像是一个非常可怕的想法——更大的尺寸、支持一个 CPU 与另一个 CPU 的困难、正确沙箱化的安全噩梦等等，等等），而在补偿方面没有太多好处。
也就是说，如果您确实热衷于将机器代码推送到客户端，请尝试 nativeclient （只要客户端是 x86 机器 - 忘记地球上的每部智能手机、许多上网本、老式 Mac 等） - 至少它承诺解决安全噩梦。 如果您对 NativeClient 感到满意，那么将即时编译器转换为提前编译器是一项容易得多的技术挑战（当然，如果您想继续使用 Javascript 作为源代码而不是其他语言） ）。
The V8 javascript 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.
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.
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).
有关先前关于并非
所有给出的原因都一定有效，但一个重要的原因是，除非您是 Google，否则服务器端 CPU 周期比客户端周期更有价值：因此让客户端编译/优化更容易通常是动态生成的 HTML/JavaScript，而不是服务器。
肯
See here for 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.
Ken
您假设解析 HTML 需要花费大量时间。 然而，与其他事情所需的时间（例如在最终用户的窗口上布局文本所需的时间）相比，该时间可能微不足道。
使用 [X]HTML 您已经明白了。
您似乎在说应该只有一种浏览器，或者所有浏览器都会同等支持它。
互联网标准并不是由一个机构（w3c）实施某项内容并宣布其成为标准而产生的。 相反，互联网标准是通过多个独立机构创建多个实现来实现的。 结果是：
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.
You already get that, using [X]HTML.
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: