据我所知，JavaScript是从服务器检索HTML文件后在客户端执行的唯一语言。据我所知，JavaScript无论如何都不是编译的，因此它是一种解释语言。
随着网络越来越流行，以至于有人说移动和桌面应用程序很快就会不复存在。
我们看到了像WebGL这样利用JS的新技术。
当我为WebGL开发时，我必须进行更多的优化，以达到合理的性能基准，然后才能为PC或控制台进行优化。
那么，为什么我们仍然使用解释性的客户端语言呢？这是一个安全问题，硬件(跨平台)问题，还是仅仅因为很难在网络架构中引入如此大的变化？我知道，即使是最小和最简单的更改，比如使用CSS3，网络开发人员也会感到头疼，因为并不是每个人都有最新的浏览器。
我认为相互渗透的语言比编译的语言慢，这是正确的吗？我说得通吗？还是我的假设完全不正确？我决不是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♯,以及ECMAScript的许多其他功能。还有一些语言被明确设计为ECMAScript的超集(例如TypeScript)，在语义上接近ECMAScript(例如CoffeeScript)，或者很容易编译到ECMASscript(例如Dart)。
据我所知，JavaScript无论如何都不是编译的，因此它是一种解释语言。
这是错误的。所有当前存在于浏览器中的ECMAScript执行引擎都至少有一个编译器。许多都有几个编译器。至少有一个没有翻译：
- V8是纯编译的，从来没有任何解释，它总是将ECMAScript源代码编译为二进制本地机器代码。原来的版本只有一个编译器，现在的版本有两个
- SpiderMonkey总是将ECMAScript编译为SpiderMonkey字节码。然后，首先对该字节码进行几次解释以收集统计信息，然后由几个编译器中的一个将"热门"部分编译为二进制本机代码
- Nitro始终将ECMAScript编译为Nitro字节码。然后，该字节码首先被解释几次以收集统计信息，然后由另一个编译器将"热"部分编译为二进制本地机器代码
- Chakra总是将ECMAScript编译为Chakra字节码。然后，该字节码首先被解释几次以收集统计信息，然后由另一个编译器将"热"部分编译为二进制本地机器代码
事实上，术语"解释语言"one_answers"编译语言"甚至没有意义。语言不会被解释或编译。的语言是。编译和解释不是一种语言的特征，而是编译器或解释器的特征(啊！)语言是一套数学规则和限制。没什么了。"语言"的概念和"解释"的概念生活在两个完全不同的抽象层次上。如果英语是一种打字语言，那么"解释语言"一词就是打字错误。
每种语言都可以由解释器实现，每种语言也可以由编译器实现。有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程序在语义上也是相同的ECMASscript程序，对asm.jsp一无所知的浏览器只会认为它是ECMASscript，并将其作为ECMASscript执行，它就可以工作)，但有一些限制，这使它成为编译器的一个很好的目标(例如，创建一个将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是唯一将在从服务器
并非总是正确的。但我们还有其他选择。比如在flash播放器中运行的ActionScript或VB脚本。但它们已经过时了。
当我为WebGL开发时，我必须进行更多的优化才能实现合理的性能基准，那么我对PC或安慰
是的，我认为我们可以用WebGL做非常好的图形。但它仍然在浏览器沙盒中运行。js的行为方式与WebGL在文件访问或其他核心标准方面的行为方式相同。这样想吧，如果你开发了一款像看门狗或gta这样的大众勇敢游戏。你认为浏览器能处理这些功能吗。但是Pc，控制台可以。
为什么我们仍然使用解释客户端语言？它是一个安全问题，硬件(跨平台)问题，还是只是因为很难将如此大的变化引入网络建筑学
我想他们两个都有。编译后的代码直接运行到机器中。那么浏览器的作用是什么呢。所以我们放松了安保措施。此外，javascript拥有庞大的社区规模。如果我们需要完全改变web架构，我们需要一个完全不同的客户端。该客户端将替换所有当前浏览器。是不是完全不可能。但会一天比一天变。ES6是一个良好的开端。
我知道web开发人员甚至对最小的和最简单的更改，比如使用CSS3，只是因为不是每个人都有他们的浏览器是最新的。
是的，100%正确。但这个问题没有其他解决办法。作为开发者必须保持兼容性。
我认为相互渗透的语言比其他语言慢，这是正确的吗编译的？
是的，它会很快。但最近的浏览器有很好的js引擎，比如chrome使用的V8。比我们预测的要快。最基本的是JS作为轻量级架构引入。当天服务器发送html，JS会根据需要修改DOM，但最近几天服务器只发送数据，JS正在创建DOM。因此JS侧的负载更多。在优秀的JS引擎的帮助下，这一切都很顺利。