为什么客户端Web仍然使用解释语言?

时间:2017-01-01 03:25:17

标签: javascript optimization web interpreted-language compiled-language

据我所知,JavaScript是从服务器检索HTML文件后将在客户端执行的唯一语言。据我所知,JavaScript绝不是以任何方式编译的,因此它是一种解释性语言。

随着Web变得越来越流行,有些人说移动和桌面应用程序很快就会不复存在。

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

当我为WebGL开发时,我必须进行更多优化才能获得合理的性能基准,然后我需要为PC或控制台做些什么。

那么为什么我们仍然使用解释的客户端语言?这是一个安全问题,硬件(跨平台)问题还是因为很难在Web架构中引入如此大的变化?我知道Web开发人员对即使是最小和最简单的更改也很头疼,比如使用CSS 3,因为不是每个人都有他们的浏览器是最新的。

我是否认为混合语言比编译语言慢?我有意义还是我的假设完全错误?我绝不是JS /网络专家,请教育我。

3 个答案:

答案 0 :(得分:8)

  

据我所知,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),或者很容易编译成ECMAScript(例如Dart)。

  

据我所知,JavaScript绝不会被编译,因此它是一种解释型语言。

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

  • V8是纯编译的,从来没有任何解释,总是将ECMAScript源代码编译为二进制本机代码。原始版本有一个编译器,当前版本有两个。
  • SpiderMonkey 始终将ECMAScript编译为SpiderMonkey字节码。然后,首先将此字节码解释几次以收集统计信息,然后再使用&#34; hot&#34;部件由几个编译器之一编译为二进制本机代码。
  • Nitro 始终将ECMAScript编译为Nitro字节码。然后,首先将此字节码解释几次以收集统计信息,然后再使用&#34; hot&#34;部件由另一个编译器编译为二进制本机代码。
  • Chakra 总是将ECMAScript编译为Chakra字节码。然后,首先将此字节码解释几次以收集统计信息,然后再使用&#34; hot&#34;部件由另一个编译器编译为二进制本机代码。

事实上,术语&#34;解释语言&#34;和#34;编译语言&#34;甚至没有意义。语言不被解释或编译。语言只是 。编译和解释不是语言的特征,它们是编译器或解释器的特征(呃!)语言是一组数学规则和限制。而已。 &#34;语言&#34;的概念以及&#34;解释&#34;的概念生活在两个完全不同的抽象层次上。如果英语是一种打字语言,那么术语“解释语言”就是一种语言。将是一个类型错误。

每种语言都可以由解释器实现,每种语言都可以由编译器实现。有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 bitcode,ANDF,CIL,JVM字节码,Pascal P-Code等启发。

Asm.js已经拥有一些浏览器支持,并且因为它只是ECMAScript的一个子集甚至可以在没有支持的浏览器中运行......只是速度较慢。 WebAssembly正在获得牵引力,尽管它仍处于实验和原型设计阶段。

答案 1 :(得分:1)

JavaScript作为源代码加载,因此需要进行解释。

您无法获得更低级别的代码,因为它不再能够跨设备无处不在兼容。

JavaScript的一个好处是您的代码几乎可以在任何设备上运行。

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

自然解释的语言运行速度比编译语言慢,因为编译代码可以由CPU盲目运行,因为编译代码需要逐行检查/运行;但是,您可以应用优化来限制此操作。

答案 2 :(得分:1)

  

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

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

  

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

是的,我认为我们可以用WebGL做很好的图形。但它仍然在浏览器沙箱中运行。如何js表现,同样的WebGL也表现在文件访问或其他核心标准的意义上。像这样思考,如果你开发了像看门狗或gta这样的大规模勇敢游戏。你认为浏览器可以处理这些功能吗?但Pc,Console do。

  

那么为什么我们仍然使用解释的客户端语言?是一个   安全问题,硬件(跨平台)问题还是简单的问题   因为很难在网络上引入如此大的变化   架构?

我想他们两个。编译后的代码直接运行到机器中。那么什么是浏览器在这里的作用。所以我们放松了安全的东西。 此外,javascript拥有大量的社区。如果我们需要彻底改变网络架构,我们需要一个完全不同的客户端。该客户端将取代所有当前的浏览器。这是不可能的。但会每天都在变化。 ES6是一个良好的开端。

  

我知道网络开发人员甚至对最小的和   最简单的变化,比如使用CSS 3,只是因为不是每个人都有   他们的浏览器是最新的。

     

是100%是真的。但是这个问题别无他法。因为开发人员必须保持兼容性。

     

我认为混合语言比较慢是正确的   编译的?

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