是否应该避免编写 Javascript，转而使用 GWT/WebSharper 或其他抽象？

Question

我很好奇“编译成 javascript 的东西”（例如 GWT、Script# 和 WebSharper 等）的观点是什么。这些似乎是相当小众的组件，旨在让人们无需编写 javascript 即可编写 javascript。

就我个人而言，我很乐意编写 javascript（使用 JQuery/Prototype/ExtJS 或其他一些此类库），并将 GWT 之类的东西视为不必要的抽象，这些抽象最终可能会限制开发人员需要完成的工作，或者最好的情况是提供非常冗长的内容解决方法。在某些情况下，您最终仍然要编写 javascript，例如 JSNI。

更糟糕的是，如果您不知道幕后发生了什么，您就有可能遭受意想不到的后果。例如，您如何知道 GWT 正在正确创建闭包并管理名称空间？

我很想听听其他人的意见。这是网络编程的发展方向吗？

Answer 1

应该避免 JavaScript 而选择 X 吗？无论如何！

首先我要声明一个免责声明：由于我是 WebSharper 开发团队的成员，所以我的回答非常有偏见。我加入这个团队的首要原因是我发现自己在编写纯 JavaScript 方面完全失败了，然后向我的公司建议我们尝试编写一个从我们最喜欢的语言 F# 到 JavaScript 的编译器。

对我来说，JavaScript 是网络的可移植程序集，与 C 在世界其他地方扮演的角色相同。它便于携带，用途广泛，而且会一直存在。但我不想写 JavaScript，就像我不想写汇编一样。我不想使用 JavaScript 作为语言的原因包括：

1. 没有静态分析，它甚至不检查是否使用正确数量的参数调用函数。拼写错误！

2. 没有或非常有限的库、命名空间、模块、类的概念，因此每个框架都发明了自己的（与 R5RS 方案类似的情况）。

3. 工具（代码编辑器、调试器、分析器）相当差，大部分是因为（1）和（2）：JavaScript 不适合静态分析。

4. 没有或非常有限的标准库。

5. 使用突变有很多粗糙的地方和偏见。即使在无类型家族中，JavaScript 也是一种设计很糟糕的语言（我更喜欢Scheme）。

我们正在尝试在 WebSharper 中解决所有这些问题。例如，Visual Studio 中的 WebSharper 具有代码补全功能，即使它公开第三方 JavaScript API（例如 Ext Js）也是如此。但我们是否已经或将会成功或失败并不是真正的重点。关键是解决这些问题是可能的，而且我希望非常可取。

如果你不知道什么是更糟糕的
在你运行的幕后进行
出现意外后果的风险。例如
你怎么知道 GWT 正在创建
闭包和管理命名空间
正确吗？

这只是关于以正确的方式编写编译器。例如，WebSharper 以 1-1 的方式将 F# lambda 映射到 JavaScript lambda（事实上，它从不引入 lambda）。如果您提到 WebSharper 尚未成熟并经过充分测试，因此您对信任它犹豫不决，我也许会接受您的论点。但是 GWT 已经存在了一段时间并且应该生成正确的代码。

最重要的是，强类型语言严格优于非类型语言 - 如果需要，您可以轻松地在其中编写非类型代码，但您可以选择使用类型检查器，即程序员的拼写检查器。你为什么不呢？对我来说，拒绝这样做听起来有点勒德主义。

Answer 2

尽管我个人并不偏爱某一种风格，但我不认为 Javascript 的抽象是这些框架带来的唯一好处。当然，在抽象整个语言的过程中，一些以前可能的事情会变得不可能，反之亦然。决定使用 GWT 等框架而不是编写普通 JavaScript 取决于许多因素。

将 JavaScript 与 X 语言进行讨论是徒劳的，因为每种语言都有其优点和缺点。相反，对使用这样的框架会获得什么或失去什么进行客观的成本效益分析，不幸的是，这只能由您而不是 SO 社区来完成。

不知道幕后发生了什么的问题同样适用于 JavaScript，就像它适用于任何翻译的源代码一样。您认为有多少人在尝试进行诸如 $("p") == $("p") 之类的比较并返回 时确切地知道 jQuery 中发生了什么结果是> false 。这不是一个假设的情况，并且有几个与此相关的问题。学习一门语言或框架需要时间，只要有足够的时间，开发人员也可以理解这些框架的编译源码。

与上述问题相关的另一个方面是信任。我们不断地在较低级别的抽象上构建较高级别的抽象，并依赖于较低级别的东西应该按预期工作的事实。您上次深入研究 C++ 或 Java 程序的已编译二进制文件以确保其正常工作是什么时候？我们不这样做是因为我们信任编译器。

此外，当使用这样的框架时，例如使用 JSNI 回退到 JavaScript 并没有什么可耻的。这一切都是为了利用手头的工具以尽可能最好的方式解决问题。 JavaScript、Java、C#、Ruby 等并没有什么神圣之处。它们都是解决问题的工具，虽然这对你来说可能是一个障碍，但对其他人来说可能是一个真正的节省时间和优势的工具。

至于我认为 Web 编程的发展方向，我认为或者更确切地说希望有许多有趣的趋势会成功，例如服务器端的 JavaScript。它至少为我解决了非常现实的问题，因为我们可以轻松地避免 Web 应用程序中的代码重复。相同的验证、逻辑等可以在客户端和服务器端共享。它还允许编写一个简单的（反）序列化机制，因此 RPC 或 RMI 通信变得非常容易。我的意思是，能够

account.debit(200);

在客户端编写： 而不是：

$.ajax({
    url: "/account",
    data: { amount: 200 },
    success: function(data) {
        ..
    }
    error: function() {
        ..
    }
});

最后，很高兴我们在构建 Web 应用程序的框架和解决方案方面拥有如此多样性，因为下一代解决方案可以从失败中学习并专注于他们的成功来构建更好、更快、更棒的工具。

Answer 3

对于 websharper 和其他声称可以避免 Javascript 痛苦的编译器，我遇到了三个重大的实际问题。

• 如果您不太了解 Javascript，您将无法理解网络上使用 DOM/ExtJs 等的大多数示例，因此您必须学习 Javascript。 （出于某种原因，所有 F# 程序员必须至少能够阅读 C# 或 VB.NET，否则他们无法访问有关 .net 框架的大部分信息）
• 在任何 Web 项目中，您都需要一些对 DOM 和 CSS 了如指掌的 Web 专家;这样的人会愿意使用 F# 而不是 Javascript 吗？
• 与编译器提供商捆绑在一起，大约 5 年后它们会实现吗？我想要完全开源或微软支持的工具。

我看到这些框架的 4 大优点是：

• 在服务器/客户端之间共享代码
• （javascript 是一个真正的痛苦，因为它看起来像 Jave/C#，但与它们完全不同）
• 程序员需要了解的语言更少 F# 程序员比 jscript 程序员要好得多。

Answer 4

我对它的价值的看法是，每个框架都有其优点/缺点，项目团队应该在包含一个框架之前评估其用例。对我来说，任何框架都只是用来解决问题的工具，你应该选择最适合这项工作的框架。

我自己更喜欢坚持使用纯 JavaScript 解决方案，但话虽这么说，我可以想到 GWT 会有所帮助的一些情况。
GWT 将允许团队在服务器/客户端之间共享代码，从而减少编写两次相同代码（JS 和 Java）的需要。或者，如果有人将 Java 客户端移植到 Web UI，他们可能会发现坚持使用 GWT 更容易（当然，这可能会变得更困难:-)）。

Answer 5

我知道这过于简单化了，因为像 GWT 这样的框架还提供了许多其他功能，但我的看法是：如果你喜欢 JavaScript，就写 JavaScript；如果你不这样做，请使用 GWT 或卡布奇诺或其他。

人们使用 GWT 这样的框架的原因不一定是它们提供的抽象（您可以使用 ExtJS 等 JavaScript 框架来实现），而是因为它们允许您使用 JavaScript 之外的其他语言编写 Web 应用程序。如果我是一名 Java 程序员，想要编写 Web 应用程序，我会使用 GWT，因为我不必学习新语言。

真的，这都是偏好。我更喜欢写 JavaScript，但很多人不喜欢。