我是否可以使用自己选择的语言编写客户端浏览器代码？[关闭]

15

我会坦率地说：我讨厌用JavaScript编写客户端代码。至少可以说，我不是这种语言的粉丝。

对我来说，浏览器支持一种编程语言，而不是一种中间虚拟机（如CIL或JVM），这似乎很愚蠢。后者将允许程序员以他们选择的语言（在某种程度上）书写，而不是使用一种固定的预设语言。这种语言的发展可能会更快，因为只有对CIL / JVM /进行任何更改，都需要每个主要的浏览器进行升级。可以添加语言功能而不会影响旧的浏览器体验。

众所周知，中间语言可以节省大量的精力。除了JavaScript以外，是否有其他措施可以促进浏览器“脚本”开发，特别是在已经设计，开发和优化的虚拟机中？他们有动力吗？

programming-languages browser

— 罗曼·斯塔科夫（Roman Starkov）
source

另请参见：为什么网站没有其他客户端脚本语言？

— 蚊蚋

11

要回答您的问题，是的，我们正在努力不赞成使用Javascript，而推荐使用更具凝聚力的Web脚本语言。Google一直在大力发展其Dart语言。Dart拥有自己的VM，该VM已嵌入到Chrome中，但是我不确定其他浏览器是否已采用它。还有一种相当有前途的语言，称为CoffeeScript。

还有一个非常雄心勃勃的项目，名为HaXe，旨在用一种语言将整个开发平台统一起来。

相信我，您并不是不喜欢Java脚本的人，但是我担心它不会很快消失-实际上，Windows 8 HTML5 / JS应用程序等似乎正在获得很大的发展势头。提到的开始兴起:)

— 马特·戴维
source

9

将所有内容统一为一种语言与所需要的完全相反。它只会使您处于与现在相同的情况，只是使用不同的语言而不是JavaScript。关键是，应该基于现有的努力：IL / CLR已经建立良好，已经在大多数平台上具有高性能的JITter，并且一些编译器已经在其中编译了多种语言。为了使Web进入21世纪，浏览器需要利用它，而不是不断尝试烘焙自己的新内容并从头开始。

— Timwi

3

@ Timwi，CIL太重了，其中太多的官僚机构。将具有专用类的完整的，ated肿的字节码文件和所有庞大的元数据附加到每个onSomething事件处理程序上是没有意义的-解析和解释简单脚本语言的10-20个字符效率更高。

— SK-logic

1

@ SK-logic：您似乎对CIL和字节码有完全错误的理解。我不知道与JavaScript之类的高级语法相比，二进制元数据是“庞大”的。最重要的是，我不知道为什么要使用“每个onSomething事件处理程序”。C＃程序显然不会为每个事件处理程序编译为多个程序集。

— Timwi

1

@Timwi，我早餐吃ECMA-335，所以我非常清楚CIL的体积。DOM节点通常是动态生成的。无法将任何内容添加到CIL中的现有模块-您必须定义一个新模块。而且您不能添加到类中-您必须定义一个新类（附加了庞大的元数据）。并且只需将读取，JIT和执行CIL的成本与解析，执行并立即丢弃一个很小的文本字符串的成本进行比较。在许多情况下，即席解释比任何形式的编译都有效得多。

— SK-logic

2

@Timwi，您建议使用字节码作为公共分母和通信格式，对吗？我的观点是，当前的CIL规范几乎没有用。ExpandoObject无关紧要。而且您对解析复杂性的观点也被模糊了。CIL模块包含其自己的程序集引用表，元数据令牌表，然后仅包含类和方法。通过解释一系列琐碎的高级语言，比较阅读和JIT所有这些笨重的东西所需的工作量。解析成本在这里几乎为零。只需尝试两种方法并进行比较即可。

— SK-logic

5

Javascript本身可以被视为一种中间语言，它定义了可以将其他语言编译成的虚拟机。在类似GWT的项目中，这一概念已经开始流行。可能不是从头开始设计的，但是已经可以将“您喜欢的语言”编译为Javascript成为现实。

— 约翰·斯内尔森
source

5

本质上没有。您几乎迷上了Javascript。

话虽这么说，过去人们一直在努力将其他语言（java applet，vbscript等）加入其中，但由于集成了javascript，因此每种语言从未真正获得javascript的青睐。

构建所指对象的唯一方法是创建一种脚本语言，该脚本语言在虚拟机上运行，在客户端编译后再执行。然后，每个浏览器都必须将虚拟机实现到其自己的代码库中，以便所有代码都可以在所有浏览器上运行。然后，您必须确保具有某种标准，以便所有浏览器以相同的方式执行命令。当然，浏览器是独立创建的，开发人员可能需要记住一些怪癖。

但是现在我们已经描述了Javascript。

所以最后，您的选择是：

习惯Java
尝试使用一些可编译为Javascript的语言。（请记住，您仍将要验证Javascript，这将回到选项1。）
使用作为浏览器插件存在的语言，例如actionscript（Flash），ActiveX，java applet，.Net（SilverLight）。这避免了该语言的多个供应商/实现的问题，但没有集成该语言。

本质上，如果您想使用集成语言，则只能使用Javascript。

— 理查德
source

2

另一种选择是使用可编译为javascript并使用该语言的语言。

— 杰蒂2011年

@Jetti您在考虑CoffeeScript吗？它的座右铭是“它只是Javascript”，这就是他们所说的“黄金法则”。但是，如果您正在编写本质上是Javascript的内容，那么您不是真的在编写Javascript吗？就像争论jQuery不是JavaScript一样，因为它更干净更易于使用。

— 理查德

2

看看这份可编译为javascript的语言的清单

— Jetti 2011年

@Jetti也许他们会解决的。但是由于有跨浏览器支持的古怪之处，我会为推荐其中任何一种而不验证实际生成的javascript感到不安。

— 理查德

1

除了javascript是一种非常可怕的中间语言，而且很难一致地执行。

— Milind R 2014年

4

实际上，您并没有像Ecma标准中所描述的那样讨厌javascript，而是讨厌各种浏览器中的糟糕实现，它们带有古怪，错误和wtfs。服务器端Javascript实际上非常有趣。DOM模型也是造成客户端JavaScript痛苦的80％的原因。

如果您仍然想使用另一种语言，则可以使用GWT，它基本上可以让您编写Java，然后将其编译为（难看的）JavaScript，或者将CoffeeScript编译为JS上的语法糖，然后编译为JS。

— 克莱门特·赫雷曼（Clement Herreman）
source

9

我不能代表romkyns，但是我讨厌JavaScript本身（除了您提到的问题之外）。它不是面向对象的，没有静态类型，没有有用的错误处理，也没有有用的现代功能框架。它也是不一致且笨拙的。顺便说一下，JS最讨厌的功能是分号插入，这是 ECMA标准。

— Timwi

1

@Timwi，它基于功能，您可以根据需要编写OO代码。静态类型是不错的选择，但是如果您的代码编写得很好（小的函数，适当的作用域），则几乎不会有问题。至于分号插入，我发现这是一个小麻烦。它只被我咬过一次，因为我{在不同的行上有一个对象的返回和打开。您发现缺少什么“现代功能框架”？

— CaffGeek 2011年

2

JavaScript本身并不是最好的语言（礼貌地说）。我不在乎面向对象的东西（它越少越好），在乎它的动态类型系统（不幸的是，这种脚本语言确实需要它），但是我并不关心语句的存在和缺乏适当的语言。列表和元组很烦人。既可以用JavaScript编写，也可以实现针对JavaScript的编译器。

— SK-logic

2

@Timwi：您并不认为面向对象不是一件好事，尽管并非总是如此。请不要将OOP视为开发范例的灵丹妙药。像JS或Scala这样的功能方法也很棒。您可以在JS中使用OOP，但是主要区别在于它是基于原型的编程，而不是基于类的编程。OOP是一个广义的名称，并不限于Java / C＃。基于原型不同于基于类，并且使用得很好，它与基于类一样强大。

— 克莱门特·赫雷曼

2

@ClementHerreman：JavaScript不限于客户端，但是此讨论是关于客户端的。JavaScript的是到原型的基础，这是相对于IL一个缺点这将让您使用几乎任何语言的任何限制。

— Timwi

2

这个问题有时会弹出。

为什么我们在脚本标签中没有其他语言而不仅仅是Javascript

早在IE时代，VB便替代了Javascript。我想您已经知道如果流行起来，这将如何导致标准地狱...

那么，为什么不使用通用的标准中间语言呢？

Brendan Eich有一个古老的播客，解释了为什么他在不久的将来看不到中间字节码语言：

http://www.aminutewithbrendan.com/pages/20101122

http://news.ycombinator.com/item?id=1893686

基本的问题是，尽管中间语言（例如CIL和JVM字节码）试图变得通用，但它们中的大多数时间却显得太低级，并且与编译给它们的原始高级语言过于绑定。例如，您不能真正在JVM中实现尾部递归函数-如果过早耦合到低级字节码抽象，我们将无法实现其他哪些语言功能或实现选择？

同时，JavaScript是一种灵活的高级语言，具有丰富的语义和多种不同的高效实现。我们将来可能会看到Java语言本身是一种中间语言 -不幸的是，这还不太成熟，到目前为止，几乎没有语言可以编译为JS。

— 雨果
source

但是，此论点适用于JavaScript的情况与适用于JVM和CIL的情况一样，不是吗？:) JavaScript唯一要做的就是所有浏览器都已支持它。

— 罗曼·斯塔科夫

重点更加微妙-与大多数中间语言相比，Java语言的描述更高层次，因此实现在选择操作时有更大的空间。（当然，这并不是一

— 团束

1

是。您已经可以将Dart，Coffeescript和Java编译为Javascript。您拥有Emscripten，这是LLVM的编译器后端，用于生成Javascript字节码（我相信LLVM处理多种语言）。

但是除了编译为JS之外，不是在很短的时间内。IE6已有10年历史了，至今仍在继续。我希望当前的浏览器（不支持其他语言）不能生存太久，但是它们会存在几年，这激起了“我们仍然必须支持仅支持Javascript的浏览器，因此我们必须使用Javascript”，比说CSS3困难得多，您的网站可能不需要CSS3也可以工作，但是请尝试使其不使用客户端脚本就可以工作。

— 亚历克斯
source

0

您可能很幸运。这是webkit-dev论坛上提交内容的开头段落：

今天，许多语言都可以编译为JavaScript以在网络上运行。作为替代方案，我们一直在尝试在WebKit中启用不同的语言运行时，使其与JavaScript一起在网页中运行...

您可以在此处查看消息的其余部分。

— pgfearo
source

0

JavaScript是浏览器的灵魂，这就是为什么大多数新尝试都在生成JavaScript的原因（CoffeeScript是一个明显的例子）。
在GWT中，您可以使用Java编程语言来编写客户端逻辑，并使用生成JavaScript来编写工具包。

如果您使用Lisp编码，那么ClojureScript是一个有趣的项目。

因此，无论如何，JavaScript都将保留下来。（也许是网络的COBOL？）。

— 凯龙
source

0

“只要是黑色，任何客户都可以在汽车上涂任何想要的颜色。” - 亨利·福特

已经有许多针对javascript的编译器，您可以选择任何可编译为javascript的语言。

您讨论中间语言价值的链接在实现编译器套件的上下文中讨论了它们，而不是在提供将通过网络传送并在客户端计算机上运行的代码的情况下进行了讨论。Javascript可能不是最好的格式，但是无论如何，它看起来都不像CIL或Java字节码。

如果您不喜欢javascript，建议您进入嵌入式，科学或游戏开发领域，由C，Fortran和C ++主导。业务应用程序正越来越多地转移到网络上，这意味着更多的Javascript，而不是更少。

— 肖恩·麦克米兰
source