我很好奇“编译成 javascript 的东西”的观点是什么，例如GWT、Script# 和 WebSharper 等。这些似乎是相当小众的组件，旨在让人们在不编写 javascript 的情况下编写 javascript。
就我个人而言，我很喜欢编写 javascript（使用 JQuery/Prototype/ExtJS 或其他类似的库）并将 GWT 之类的东西视为不必要的抽象，最终可能会限制开发人员需要完成的工作或提供非常冗长的解决方法。在某些情况下，您仍然最终会编写 javascript，例如JSNI。
更糟糕的是，如果您不知道幕后发生的事情，您可能会面临意外后果的风险。例如。你怎么知道 GWT 正在正确地创建闭包和管理命名空间？
我很想听听别人的意见。这是网络编程的发展方向吗？
【问题讨论】：
标签： javascript gwt websharper
应该避免使用 JavaScript 来支持 X 吗？无论如何！
我首先要声明一个免责声明：我的回答非常有偏见，因为我是 WebSharper 开发团队的一员。我加入这个团队的原因首先是我发现自己在编写纯 JavaScript 方面完全失败，然后向我的公司建议我们尝试从我们最喜欢的语言 F# 到 JavaScript 编写一个编译器。
对我来说，JavaScript 是 Web 的可移植程序集，与 C 在世界其他地方的作用相同。它是便携式的，广泛使用的，并且会一直存在。但是我不想写 JavaScript，就像我想写汇编一样。我不想使用 JavaScript 作为语言的原因包括：
没有静态分析，它甚至不检查是否使用正确数量的参数调用函数。错别字咬人！
没有或非常有限的库、命名空间、模块、类的概念，因此每个框架都发明了自己的（类似于 R5RS 方案的情况）。
工具（代码编辑器、调试器、分析器）相当差，主要是因为 (1) 和 (2)：JavaScript 不适合静态分析。
没有标准库或标准库非常有限。
有许多粗糙的边缘和使用突变的偏见。即使在无类型家族中，JavaScript 也是一种设计不佳的语言（我更喜欢 Scheme）。
我们正在尝试在 WebSharper 中解决所有这些问题。例如，Visual Studio 中的 WebSharper 具有代码完成功能，即使它公开了第三方 JavaScript API，例如 Ext Js。但我们是否成功或失败并不是真正的重点。关键是解决这些问题是可能的，而且我希望非常可取。
如果你不知道什么是更糟糕的 在你运行的封面下进行 意外后果的风险。例如。 你怎么知道 GWT 正在创建 闭包和管理命名空间 正确吗？
这只是关于以正确的方式编写编译器。例如，WebSharper 以 1-1 的方式将 F# lambda 映射到 JavaScript lambda（事实上，它从未引入 lambda）。如果您提到 WebSharper 尚未成熟和经过足够的测试，因此您对信任它犹豫不决，我可能会接受您的论点。但是 GWT 已经存在了一段时间，应该会产生正确的代码。
归根结底，强类型语言比无类型语言更好 - 如果需要，您可以轻松地在其中编写无类型代码，但您可以选择使用类型检查器，它是程序员的拼写检查器.你为什么不呢？拒绝这样做对我来说听起来有点愚蠢。
【讨论】：
尽管我个人并不偏爱一种风格而不是另一种风格，但我不认为 Javascript 的抽象是这些框架带来的唯一好处。当然，在对整个语言进行抽象的过程中，会有一些以前可能的事情变得不可能，反之亦然。使用 GWT 等框架而不是编写原生 JavaScript 的决定取决于许多因素。
讨论 JavaScript 与语言 X 是徒劳的，因为每种语言都有其优点和缺点。相反，请对使用这样的框架会获得或失去什么进行客观的成本效益分析，不幸的是，这只能由您而不是 SO 社区来完成。
不知道幕后发生了什么的问题同样适用于 JavaScript，就像它适用于任何已翻译的源代码一样。您认为有多少人会在尝试进行比较（例如$("p") == $("p")）并返回false 时确切地知道jQuery 中发生了什么。这不是假设的情况，关于 SO 有几个关于此的问题。学习一种语言或框架需要时间，如果有足够的时间，开发人员也可以很好地理解这些框架的编译源代码。
与上述问题相关的另一个方面是信任。我们不断地在较低级别的抽象上构建更高级别的抽象，并依赖于较低级别的东西应该按预期工作的事实。您上一次深入研究 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 应用程序的框架和解决方案方面拥有所有这些多样性，因为下一代解决方案可以从每个解决方案的失败中吸取教训，并专注于他们的成功，以构建更好、更快、更出色的工具.
【讨论】：
我在使用 websharper 和其他声称可以避免 Javascript 痛苦的编译器方面遇到了三个重大实际问题。
我看到这些框架的 4 大优点是：
【讨论】：
我认为每个框架都有其优点/缺点，因此项目团队应该先评估他们的用例，然后再加入。对我来说，任何框架都只是用来解决问题的工具，你应该选择最适合这项工作的框架。
我自己更喜欢坚持使用纯 JavaScript 解决方案，但话虽如此，我还是能想到一些 GWT 会有所帮助的情况。 GWT 将允许团队在服务器/客户端之间共享代码，从而减少两次编写相同代码（JS 和 Java）的需要。或者，如果有人将 Java 客户端移植到 Web UI，他们可能会发现坚持使用 GWT 更容易（当然，这可能会使它更难:-)）。
【讨论】：
我知道这过于简单化了，因为像 GWT 这样的框架还提供了许多其他的东西，但我是这样看待它的：如果你喜欢 JavaScript，那就写 JavaScript；如果你喜欢 JavaScript，那就写 JavaScript；如果您不这样做，请使用 GWT 或 Cappuccino 或其他任何东西。
人们使用 GWT 之类的框架的原因不一定是它们提供的抽象——你可以使用 ExtJS 之类的 JavaScript 框架来拥有它——而是它们允许你用 JavaScript 以外的东西编写 Web 应用程序这一事实。如果我是一名想要编写 Web 应用程序的 Java 程序员，我会使用 GWT，因为我不必学习一门新语言。
这都是偏好，真的。我更喜欢编写 JavaScript，但很多人不这样做。
【讨论】：