据我所知，JavaScript 是从服务器检索 HTML 文件后在客户端执行的唯一语言。据我所知，JavaScript 无论如何都不会被编译，因此它是一种解释性语言。
随着 Web 变得越来越流行，以至于有人说移动和桌面应用程序将很快不复存在。
我们看到了像 WebGL 这样使用 JS 的新技术。
当我为 WebGL 开发时，我必须进行更多优化以达到合理的性能基准，然后我必须为 PC 或控制台做这些。
那么为什么我们仍然使用解释型客户端语言呢？是安全问题、硬件（跨平台）问题还是仅仅因为难以将如此大的变化引入 Web 架构？我知道 Web 开发人员会为即使是最小和最简单的更改（例如使用 CSS 3）而头疼，这仅仅是因为并非每个人的浏览器都是最新的。
我认为交互语言比编译语言慢吗？我说得通还是我的假设完全不正确？我绝不是 JS/web 专家，请教育我。
据我所知，JavaScript 是从服务器检索 HTML 文件后在客户端执行的唯一语言。
这是错误的。至少在 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♯ 和许多其他语言的编译器ECMA 脚本。还有一些语言被明确设计为 ECMAScript 的超集（例如 TypeScript），在语义上接近 ECMAScript（例如 CoffeeScript），或者易于编译为 ECMAScript（例如 Dart）。
据我所知，JavaScript 无论如何都不会被编译，因此它是一种解释性语言。
这是错误的。所有当前存在的浏览器内 ECMAScript 执行引擎都至少有一个编译器。许多人有几个编译器。至少有一个没有任何解释器：
事实上，术语“解释语言”和“编译语言”甚至没有意义。语言不被解释或编译。语言只是。编译和解释不是语言的特征，它们是编译器或解释器的特征（呃！）语言是一组数学规则和限制。而已。“语言”的概念和“解释”的概念生活在两个完全不同的抽象层次上。如果英语是一种类型化语言，那么术语“解释语言”将是类型错误。
每种语言都可以由解释器实现，每种语言都可以由编译器实现。有 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 执行，它只会工作）具有某些限制，使其成为编译器的良好目标（例如，创建将 C 编译为 asm.js 的编译器相对容易），同时也是本机代码的良好来源代（即其语义比较接近现代主流通用CPU的语义）。
同样，WebAssembly 是一种（二进制）语言，其目标与 asm.js 基本相同，只是不要求它是 ECMAScript 的适当子集。它是自己的独立语言，灵感来自 asm.js、LLVM 位码、ANDF、CIL、JVM 字节码、Pascal P-Code 等。
Asm.js 已经有一些浏览器支持，而且由于它只是 ECMAScript 的一个子集，甚至可以在没有支持的浏览器中工作……只是速度较慢。WebAssembly 正在获得关注，尽管它仍处于实验和原型设计阶段。
JavaScript 作为源代码加载，因此需要解释。
您不能拥有更低级别的代码，因为它不再在设备之间普遍兼容。
JavaScript 的好处之一是您的代码几乎可以在任何设备的网络浏览器上运行。
如果您要编译此代码，它将成为特定于体系结构/设备的。
自然解释语言的运行速度会比编译语言慢，因为编译代码可以由 CPU 盲目运行，而编译代码需要逐行检查/运行；但是，您可以应用优化来限制这一点。
据我所知，JavaScript 是从服务器检索 HTML 文件后在客户端执行的唯一语言。
并非总是如此。我们还有其他选择。像在 Flash 播放器中运行的 ActionScript 或 VB 脚本。但它们已经过时了。
当我为 WebGL 开发时，我必须进行更多优化以达到合理的性能基准，然后我必须为 PC 或控制台做这些。
是的，我认为我们可以使用 WebGL 制作非常好的图形。但它仍然在浏览器沙箱中运行。js 的行为方式，WebGL 在文件访问或其他核心标准的意义上也是如此。像这样想，如果你开发像看门狗或 gta 这样的大规模勇敢游戏。您认为浏览器可以处理这些功能吗？但是PC，控制台可以。
那么为什么我们仍然使用解释型客户端语言呢？是安全问题、硬件（跨平台）问题还是仅仅因为难以将如此大的变化引入 Web 架构？
我猜他们两个。编译后的代码直接运行到机器上。那么这里浏览器的作用是什么。所以我们失去了安全的东西。javascript也有大量的社区。如果我们需要完全改变 Web 架构，我们需要一个完全不同的客户端。该客户端将替换所有当前浏览器。是不是完全不可能。但会一天天改变。ES6 是一个好的开始。
我知道 Web 开发人员会为即使是最小和最简单的更改（例如使用 CSS 3）而头疼，这仅仅是因为并非每个人的浏览器都是最新的。
是的 100% 正确。但是对于这个问题没有其他办法。作为开发者必须保持兼容性。
我认为交互语言比编译语言慢吗？
是的，它会很快。但是最近的浏览器有很好的 js 引擎，比如 chrome 使用的 V8。这真的比我们预测的快。基本的事情是 JS 作为轻量级架构引入。那天服务器发送html，JS会根据需要修改DOM，但最近几天服务器只发送数据，JS正在创建DOM。所以负载在 JS 方面更重要。这在良好的 JS 引擎的帮助下进展顺利。