为什么客户端 Web 仍然使用解释性语言？
Why is client-side web still using an interpreted language?
据我所知，JavaScript 是唯一一种在从服务器检索 HTML 文件后将在客户端执行的语言。据我所知 JavaScript 无论如何都不会编译，因此它是一种解释语言。
随着 Web 变得越来越流行，以至于有人说移动和桌面应用程序将很快不复存在。
我们看到了使用 JS 的新技术，例如 WebGL。
当我为 WebGL 开发时，我必须进行更多优化才能达到合理的性能基准，然后我必须为 PC 或控制台进行优化。
那么为什么我们仍然使用解释性的客户端语言呢？是安全问题、硬件（跨平台）问题还是仅仅是因为很难将如此大的变化引入到网络架构中？我知道网络开发人员甚至对最小和最简单的更改感到头疼，例如使用 CSS 3，只是因为不是每个人的浏览器都是最新的。
我认为交互语言比编译语言慢的想法是否正确？我说得有道理还是我的假设完全不正确？我绝不是JS/web高手，请赐教。
JavaScript 加载为源代码，因此需要解释。
您不能拥有更低级别的代码，因为它不再能够跨设备普遍兼容。
JavaScript 的好处之一是您的代码将 运行 在几乎任何设备的网络浏览器上。
如果您要编译此代码，它将成为特定于体系结构/设备的。
自然解释语言将 运行 比编译语言慢，因为编译代码可以 运行 盲目地被 CPU，其中编译代码需要检查 / 运行 逐行;但是，您可以应用优化来限制这种情况。
To my knowledge JavaScript is the only language that will execute on
the client side after the HTML file has been retrieved from the
server.
并非总是如此。我们还有其他选择。像在 Flash 播放器中 运行s 的 ActionScript，或 VB 脚本。但是他们已经过时了。
When I develop for WebGL I have to optimize so much more to achieve a
reasonable performance benchmark, then what I would have to for PC or
Console.
是的，我认为我们可以使用 WebGL 制作非常漂亮的图形。但它仍然 运行 在浏览器沙箱中。 js 的行为方式与 WebGL 在文件访问或其他核心标准方面的行为方式相同。这样想，如果你开发了看门狗或者gta这样的大众勇敢者游戏。您认为浏览器可以处理这些功能吗？但是 Pc，Console 可以。
So why do we still use an interpreted client side language? Is it a
security issue, hardware (cross platform) issue or is it simply
because it's difficult to introduce such a large change into the web
architecture?
我猜他们两个。编译后的代码运行直接进入机器。那么这里浏览器的作用是什么。所以我们放松了安全措施。
javascript 也有大型社区。如果我们需要完全改变网络架构，我们需要一个完全不同的客户端。该客户端将取代所有当前的浏览器。是不是完全不可能。但会一天一天地改变。 ES6 是一个好的开始。
I know web developers have headaches over even the smallest and
simplest changes, like using CSS 3, simply because not everyone has
their browser up to date.
Yes 100% true. But there is no other way for this problem. As a developer must keep the compatibility.
Am I correct in thinking that interperated languages are slower then
compiled ones?
是的，它会很快。但是最近的浏览器有很好的 js 引擎，比如 chrome 使用的 V8。那真的比我们预测的要快。基本的东西是 JS 作为轻量级架构引入。那天服务器发送html，JS会根据需要修改DOM，但最近几天服务器只发送数据，JS正在创建DOM。所以负载更多地集中在 JS 端。这在优秀的 JS 引擎的帮助下进展顺利。
To my knowledge JavaScript is the only language that will execute on the client side after the HTML file has been retrieved from the server.
这是错误的。至少在 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）。
As far as I know JavaScript is by no means compiled in anyway and thus it is an interpreted language.
这是错误的。所有当前存在的浏览器内 ECMAScript 执行引擎都至少有一个编译器。许多有几个编译器。至少有一个没有任何翻译：
- V8 是纯编译的，从不进行任何解释，它总是 将 ECMAScript 源代码编译为二进制本机代码。原始版本只有一个编译器，当前版本有两个。
- SpiderMonkey 总是 将 ECMAScript 编译成 SpiderMonkey 字节码。这个字节码首先被解释几次以收集统计数据，然后 "hot" 部分被几个编译器之一编译成二进制本机代码。
- Nitro 总是 将 ECMAScript 编译成 Nitro 字节码。这个字节码首先被解释几次以收集统计信息，然后 "hot" 部分被另一个编译器编译为二进制本机代码。
- Chakra 总是 将 ECMAScript 编译为 Chakra 字节码。这个字节码首先被解释几次以收集统计信息，然后 "hot" 部分被另一个编译器编译为二进制本机代码。
事实上，术语 "interpreted language" 和 "compiled language" 甚至没有意义。语言不会被解释或编译。语言 是 。编译和解释不是语言的特征，它们是编译器或解释器的特征（duh！）语言是一组数学规则和限制。而已。 "language" 的概念和 "interpretation" 的概念存在于两个完全不同的抽象层次上。如果英语是一种打字语言，术语 "interpreted language" 将是打字错误。
每种语言都可以由解释器实现，每种语言都可以由编译器实现。有 C 和 C++ 的解释器，有 ECMAScript 的编译器，PHP、Python 和 Ruby.
Am I correct in thinking that interperated languages are slower then compiled ones?
没有。首先，就像我上面解释的那样，根本就没有解释或编译语言这样的东西。只有语言的解释或编译实现。其次，说一种语言比另一种语言慢是没有意义的。您只能说，某些特定程序在特定机器上的特定环境中由特定版本的特定实现执行时，比由不同版本的不同实现在不同环境中可能不同的机器上执行的不同程序运行得更快机.
一般来说，典型程序在特定实现上的性能主要取决于花费了多少金钱、资源、努力、脑力、研究、工程和人力，而不是取决于程序的任何特定特征语。 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) 的编译器，同时也是一个很好的 source 用于本地代码生成（即它的语义相对接近现代主流通用语言的语义CPU）。
同样，WebAssembly 是一种（二进制）语言，其目标与 asm.js 基本相同，只是不要求它是 ECMAScript 的适当子集。它是自己独立的语言，受到 asm.js、LLVM 位码、ANDF、CIL、JVM 字节码、Pascal P-Code 等的启发。
Asm.js 已经有一些浏览器支持，并且由于它只是 ECMAScript 的一个子集，甚至可以在没有支持的浏览器中运行……只是速度较慢。 WebAssembly 正在获得关注，尽管它仍处于实验和原型设计阶段。
据我所知，JavaScript 是唯一一种在从服务器检索 HTML 文件后将在客户端执行的语言。据我所知 JavaScript 无论如何都不会编译，因此它是一种解释语言。
随着 Web 变得越来越流行，以至于有人说移动和桌面应用程序将很快不复存在。
我们看到了使用 JS 的新技术，例如 WebGL。
当我为 WebGL 开发时，我必须进行更多优化才能达到合理的性能基准，然后我必须为 PC 或控制台进行优化。
那么为什么我们仍然使用解释性的客户端语言呢？是安全问题、硬件（跨平台）问题还是仅仅是因为很难将如此大的变化引入到网络架构中？我知道网络开发人员甚至对最小和最简单的更改感到头疼，例如使用 CSS 3，只是因为不是每个人的浏览器都是最新的。
我认为交互语言比编译语言慢的想法是否正确？我说得有道理还是我的假设完全不正确？我绝不是JS/web高手，请赐教。
JavaScript 加载为源代码，因此需要解释。
您不能拥有更低级别的代码，因为它不再能够跨设备普遍兼容。
JavaScript 的好处之一是您的代码将 运行 在几乎任何设备的网络浏览器上。
如果您要编译此代码，它将成为特定于体系结构/设备的。
自然解释语言将 运行 比编译语言慢，因为编译代码可以 运行 盲目地被 CPU，其中编译代码需要检查 / 运行 逐行;但是，您可以应用优化来限制这种情况。
To my knowledge JavaScript is the only language that will execute on the client side after the HTML file has been retrieved from the server.
并非总是如此。我们还有其他选择。像在 Flash 播放器中 运行s 的 ActionScript，或 VB 脚本。但是他们已经过时了。
When I develop for WebGL I have to optimize so much more to achieve a reasonable performance benchmark, then what I would have to for PC or Console.
是的，我认为我们可以使用 WebGL 制作非常漂亮的图形。但它仍然 运行 在浏览器沙箱中。 js 的行为方式与 WebGL 在文件访问或其他核心标准方面的行为方式相同。这样想，如果你开发了看门狗或者gta这样的大众勇敢者游戏。您认为浏览器可以处理这些功能吗？但是 Pc，Console 可以。
So why do we still use an interpreted client side language? Is it a security issue, hardware (cross platform) issue or is it simply because it's difficult to introduce such a large change into the web architecture?
我猜他们两个。编译后的代码运行直接进入机器。那么这里浏览器的作用是什么。所以我们放松了安全措施。 javascript 也有大型社区。如果我们需要完全改变网络架构，我们需要一个完全不同的客户端。该客户端将取代所有当前的浏览器。是不是完全不可能。但会一天一天地改变。 ES6 是一个好的开始。
I know web developers have headaches over even the smallest and simplest changes, like using CSS 3, simply because not everyone has their browser up to date.
Yes 100% true. But there is no other way for this problem. As a developer must keep the compatibility.
Am I correct in thinking that interperated languages are slower then compiled ones?
是的，它会很快。但是最近的浏览器有很好的 js 引擎，比如 chrome 使用的 V8。那真的比我们预测的要快。基本的东西是 JS 作为轻量级架构引入。那天服务器发送html，JS会根据需要修改DOM，但最近几天服务器只发送数据，JS正在创建DOM。所以负载更多地集中在 JS 端。这在优秀的 JS 引擎的帮助下进展顺利。
To my knowledge JavaScript is the only language that will execute on the client side after the HTML file has been retrieved from the server.
这是错误的。至少在 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）。
As far as I know JavaScript is by no means compiled in anyway and thus it is an interpreted language.
这是错误的。所有当前存在的浏览器内 ECMAScript 执行引擎都至少有一个编译器。许多有几个编译器。至少有一个没有任何翻译：
- V8 是纯编译的，从不进行任何解释，它总是 将 ECMAScript 源代码编译为二进制本机代码。原始版本只有一个编译器，当前版本有两个。
- SpiderMonkey 总是 将 ECMAScript 编译成 SpiderMonkey 字节码。这个字节码首先被解释几次以收集统计数据，然后 "hot" 部分被几个编译器之一编译成二进制本机代码。
- Nitro 总是 将 ECMAScript 编译成 Nitro 字节码。这个字节码首先被解释几次以收集统计信息，然后 "hot" 部分被另一个编译器编译为二进制本机代码。
- Chakra 总是 将 ECMAScript 编译为 Chakra 字节码。这个字节码首先被解释几次以收集统计信息，然后 "hot" 部分被另一个编译器编译为二进制本机代码。
事实上，术语 "interpreted language" 和 "compiled language" 甚至没有意义。语言不会被解释或编译。语言 是 。编译和解释不是语言的特征，它们是编译器或解释器的特征（duh！）语言是一组数学规则和限制。而已。 "language" 的概念和 "interpretation" 的概念存在于两个完全不同的抽象层次上。如果英语是一种打字语言，术语 "interpreted language" 将是打字错误。
每种语言都可以由解释器实现，每种语言都可以由编译器实现。有 C 和 C++ 的解释器，有 ECMAScript 的编译器，PHP、Python 和 Ruby.
Am I correct in thinking that interperated languages are slower then compiled ones?
没有。首先，就像我上面解释的那样，根本就没有解释或编译语言这样的东西。只有语言的解释或编译实现。其次，说一种语言比另一种语言慢是没有意义的。您只能说，某些特定程序在特定机器上的特定环境中由特定版本的特定实现执行时，比由不同版本的不同实现在不同环境中可能不同的机器上执行的不同程序运行得更快机.
一般来说，典型程序在特定实现上的性能主要取决于花费了多少金钱、资源、努力、脑力、研究、工程和人力，而不是取决于程序的任何特定特征语。 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) 的编译器，同时也是一个很好的 source 用于本地代码生成（即它的语义相对接近现代主流通用语言的语义CPU）。
同样，WebAssembly 是一种（二进制）语言，其目标与 asm.js 基本相同，只是不要求它是 ECMAScript 的适当子集。它是自己独立的语言，受到 asm.js、LLVM 位码、ANDF、CIL、JVM 字节码、Pascal P-Code 等的启发。
Asm.js 已经有一些浏览器支持，并且由于它只是 ECMAScript 的一个子集，甚至可以在没有支持的浏览器中运行……只是速度较慢。 WebAssembly 正在获得关注，尽管它仍处于实验和原型设计阶段。