为什么客户端网络仍然使用解释语言？ [关闭]

Question

据我所知，在从服务器检索 HTML 文件后，JavaScript 是唯一在客户端执行的语言。据我所知，JavaScript 无论如何都不会被编译，因此它是一种解释性语言。

随着网络变得越来越流行，以至于有人说移动和桌面应用程序将很快不复存在。

我们看到了像 WebGL 这样利用 JS 的新技术。

当我为 WebGL 开发时，我必须进行更多优化以达到合理的性能基准，然后我就必须为 PC 或控制台做这些。

那么为什么我们仍然使用解释型客户端语言呢？是安全问题、硬件（跨平台）问题还是仅仅因为难以将如此大的变化引入 Web 架构？我知道即使是最小和最简单的更改（例如使用 CSS 3），Web 开发人员也会头疼，这仅仅是因为并非每个人的浏览器都是最新的。

我认为交互语言比编译语言慢吗？我说得通还是我的假设完全不正确？我绝不是 JS/web 专家，请教育我。

Answer 1

JavaScript 作为源代码加载，因此需要解释。

你不能拥有更低级别的代码，因为它不再在设备间普遍兼容。

JavaScript 的好处之一是您的代码几乎可以在任何设备的网络浏览器上运行。

如果您要编译此代码，它将成为特定于架构/设备的代码。

自然解释型语言的运行速度会比编译型语言慢，因为编译后的代码可以由 CPU 盲目运行，而编译后的代码需要逐行检查/运行；但是，您可以应用优化来限制这一点。

Answer 2

据我所知，JavaScript 是唯一可以在其上执行的语言 从客户端检索 HTML 文件后的客户端 服务器。

并非总是如此。我们还有其他选择。像在 Flash 播放器中运行的 ActionScript 或 VB 脚本。但它们已经过时了。

当我为 WebGL 开发时，我必须进行更多优化才能实现 合理的性能基准，然后我必须为 PC 或 控制台。

是的，我认为我们可以使用 WebGL 制作非常好的图形。但它仍然在浏览器沙箱中运行。 js 的行为方式，WebGL 在文件访问或其他核心标准的意义上也是如此。像这样想，如果你开发像看门狗或 gta 这样的大规模勇敢游戏。您认为浏览器可以处理这些功能吗？但是PC，Console可以。

那么为什么我们仍然使用解释型客户端语言呢？是不是一个 安全问题，硬件（跨平台）问题还是简单的 因为很难将如此大的变化引入网络 架构？

我猜他们两个。编译后的代码直接运行到机器上。那么这里浏览器的作用是什么。所以我们失去了安全的东西。 javascript也有大量的社区。如果我们需要完全改变 Web 架构，我们需要一个完全不同的客户端。该客户端将替换所有当前浏览器。是不是完全不可能。但会一天天改变。 ES6 是一个好的开始。

我知道 Web 开发人员对即使是最小的和 最简单的改变，比如使用 CSS 3，只是因为不是每个人都有 他们的浏览器是最新的。

是的，100% 正确。但是对于这个问题没有其他办法。作为开发者必须保持兼容性。

我认为互操作的语言比那时慢吗？ 编译的？

是的，它会很快。但是最近的浏览器有很好的 js 引擎，比如 chrome 使用的 V8。这真的比我们预测的快。基本的事情是 JS 作为轻量级架构引入。那天服务器发送html，JS会根据需要修改DOM，但最近几天服务器只发送数据，JS正在创建DOM。所以负载在 JS 方面更重要。在优秀的 JS 引擎的帮助下，这一切都很好。

Answer 3

据我所知，在从服务器检索 HTML 文件后，JavaScript 是唯一在客户端执行的语言。

这是错误的。至少在 HTML 4.01 中，<script> 元素有一个type 属性，允许您指定任何您想要的语言。 HTML 4.01 规范本身在 VBScript 和 Tcl 中有示例。

例如，旧版本的 Internet Explorer 支持 VBScript 作为 ECMAScript 的替代脚本语言。有一些版本的 Chrome 支持 Dart 作为替代脚本语言。有一个项目为 Firefox 添加了对 PHP、Perl、Python、Ruby、Tcl 等的支持。

您还可以使用任何具有输出 ECMAScript 的编译器的语言，现在几乎所有语言都有，例如有一些编译器可以将 C、C++、Java、Scala、Ruby、C♯、F♯ 和许多其他编译器编译为 ECMAScript。还有一些语言被明确设计为 ECMAScript 的超集（例如 TypeScript），语义上接近 ECMAScript（例如 CoffeeScript），或者易于编译为 ECMAScript（例如 Dart）。

据我所知，JavaScript 无论如何都不会编译，因此它是一种解释型语言。

这是错误的。所有当前存在的浏览器内 ECMAScript 执行引擎都至少有一个编译器。许多人有几个编译器。至少有一个没有任何翻译：

• V8 是纯编译的，永远不会进行任何解释，它总是将 ECMAScript 源代码编译为二进制本机机器代码。原始版本只有一个编译器，当前版本有两个。
• SpiderMonkey 总是将 ECMAScript 编译为 SpiderMonkey 字节码。然后，首先对该字节码进行几次解释以收集统计信息，然后由多个编译器之一将“热”部分编译为二进制本机机器代码。
• Nitro 总是将 ECMAScript 编译为 Nitro 字节码。然后，这个字节码首先被解释几次以收集统计信息，然后“热”部分由另一个编译器编译成二进制本机机器码。
• Chakra 总是 将 ECMAScript 编译为 Chakra 字节码。然后，这个字节码首先被解释几次以收集统计信息，然后“热”部分由另一个编译器编译成二进制本机机器码。

事实上，术语“解释语言”和“编译语言”甚至没有意义。语言不被解释或编译。语言只是是。编译和解释不是语言的特征，它们是编译器或解释器的特征（呃！）语言是一组数学规则和限制。而已。 “语言”的概念和“解释”的概念生活在两个完全不同的抽象层次上。如果英语是一种类型化语言，那么术语“解释性语言”将是类型错误。

每种语言都可以由解释器实现，每种语言都可以由编译器实现。有 C 和 C++ 的解释器，有 ECMAScript、PHP、Python 和 Ruby 的编译器。

我认为交互语言比编译语言慢吗？

没有。首先，就像我上面解释的那样，根本没有解释或编译语言这样的东西。只有语言的解释或编译实现。其次，说一种语言比另一种语言慢是没有意义的。您只能说，当某个特定程序在特定机器上的特定环境中由特定实现的特定版本执行时，其运行速度比由不同环境中不同实现的不同版本执行的不同程序运行得更快。机器。

一般而言，典型程序在特定实现上的性能主要取决于在其上花费了多少金钱、资源、努力、脑力、研究、工程和人力，而不是语言的任何特定特征。 Oracle HotSpot JVM 快不是因为它是一个编译实现，也不是因为 Java 是静态类型的（事实上，这完全不相关，因为 HotSpot JVM 执行 JVM 字节码，它甚至对 Java 一无所知！），而是因为 Oracle Sun 已经在其中投入了大量资源。具有讽刺意味的是，在 Sun 收购了 Smalltalk(!!!) 公司和他们的 VM 技术之前，Java 实际上非常慢。是的，没错：HotSpot JVM 实际上只是一个稍加修改的 Smalltalk VM，即动态语言的 VM。

事实上，VM HotSpot 是基于，是开源的，也是 VM V8 的基础（这并不奇怪，因为 V8 是由一些开发 HotSpot JVM 和 Smalltalk VM 的人开发的它是基于）。

请注意，要获得浏览器供应商接受的新语言有两种尝试：

asm.js 是一种语言，它是 ECMAScript 的语法和语义子集（这意味着任何 asm.js 程序在语义上也是相同的 ECMAScript 程序，并且对 asm.js 一无所知的浏览器只会认为它是 ECMAScript 并将其作为 ECMAScript 执行，它只会工作）具有某些限制，使其成为编译器的良好 target（例如，创建将 C 编译为 asm.js 的编译器相对容易）和同时也是原生代码生成的良好来源（即其语义比较接近现代主流通用 CPU 的语义）。

同样，WebAssembly 是一种（二进制）语言，其目标与 asm.js 基本相同，只是不要求它是 ECMAScript 的适当子集。它是自己的独立语言，灵感来自 asm.js、LLVM 位码、ANDF、CIL、JVM 字节码、Pascal P-Code 等。

Asm.js 已经有一些浏览器支持，而且由于它只是 ECMAScript 的一个子集，甚至可以在没有支持的浏览器中运行……只是速度较慢。 WebAssembly 正在获得关注，尽管它仍处于试验和原型设计阶段。