是否应该避免编写Javascript以支持GWT / WebSharper或其他一些抽象？

虽然，我个人并不喜欢一种风格，但我认为从Javascript中抽象是这些框架带来的唯一好处。当然，在抽象整个语言的过程中，会出现以前不可能的事情，反之亦然。决定使用像GWT这样的框架来编写普通的JavaScript取决于很多因素。 由于每种语言都有其优点和缺点，因此对JavaScript与语言X进行讨论是徒劳的。相反，通过使用这样的框架，对可以获得或丢失的内容进行客观的成本效益分析，这只能由您而不是SO社区完成。 不知道幕后发生了什么的问题适用于JavaScript，就像对任何翻译的源一样。你认为有多少人在jQuery尝试进行比较时会知道jQuery发生了什么，并因此得到了回复

false

。这不是一个假设的情况，关于SO的问题有几个问题。学习语言或框架需要时间，如果有足够的时间，开发人员也可以理解这些框架的编译源。 上述问题的另一个相关方面是信任。我们不断在较低级别的抽象上构建更高级别的抽象，并依赖于较低级别的东西应该按预期工作的事实。你最后一次挖掘C ++或Java程序的编译二进制文件是为了确保它正常工作？我们不这样做，因为我们信任编译器。 此外，在使用这样的框架时，例如，使用JSNI回退到JavaScript是没有羞耻的。一切都是用手头的工具以最好的方式解决问题。没有什么神圣的JavaScript，或Java，或C＃，或Ruby等。它们都是解决问题的工具，虽然它可能是一个障碍，但它可能是一个真正的节省时间，对其他人有利。 至于我认为网络编程的发展方向，我认为有很多有趣的趋势，或者希望能够成功，例如服务器端的JavaScript。它至少解决了我真正的问题，因为我们可以在Web应用程序中轻松避免代码重复。可以在客户端和服务器端共享相同的验证，逻辑等。它还允许编写简单的（de）序列化机制，因此可以非常容易地进行RPC或RMI通信。我的意思是能够写下来真的很棒：

account.debit(200);

在客户端，而不是：

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

最后，我们在构建Web应用程序的框架和解决方案中拥有所有这些多样性非常棒，因为下一代解决方案可以从每个解决方案的失败中学习，并专注于他们的成功，以构建更好，更快，更棒的工具。     

应该避免使用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＃lambdas映射到JavaScript lambdas（事实上，它从未引入lambda）。如果您提到WebSharper尚未成熟且经过充分测试，因此您可能会接受您的论点，因此您对此信任犹豫不决。但是GWT已经存在了一段时间，应该生成正确的代码。 底线是强类型语言严格优于无类型语言 - 如果需要，您可以轻松地在其中编写无类型代码，但您可以选择使用类型检查程序，即程序员的拼写检查程序。你为什么不呢？拒绝这样做对我来说听起来有点沉闷。     

我对websharper和其他编译器有三大实际问题，声称可以避免Javascript的痛苦。 如果你不太了解Javascript，你无法理解网上使用DOM / ExtJs等的大多数例子，所以你必须学习Javascript。 （由于某些原因，所有F＃程序员必须能够至少读取C＃或VB.NET，否则他们无法访问有关.net框架的大多数信息） 在任何Web项目中，您需要一些知道DOM和CSS的Web专家;这样的人是否愿意使用F＃而不是Javascript？ 被绑定到编译器的提供者，它们将在5年后出现;我想要完全开源或Microsoft支持的工具。 我在这些框架中看到的四大积极因素是： 在服务器/客户端之间共享代码 程序员需要知道的语言较少（javascript是一个真正的痛苦，因为它看起来像Jave / C＃，但不是像他们一样） F＃程序员的平均质量比jscript程序员好很多。     

我认为它的价值在于每个框架都有其优点/缺点，项目团队应该在包含一个框架之前对其用例进行评估。对我来说，任何框架都只是一个用来解决问题的工具，你应该选择最适合的工作。 我更喜欢自己坚持使用纯JavaScript解决方案，但据说我可以想到一些GWT会有用的情况。 GWT允许团队在服务器/客户端之间共享代码，从而减少了两次编写相同代码（JS和Java）的需要。或者，如果有人将Java客户端移植到Web UI，他们可能会发现更容易坚持使用GWT（当然，这可能会使其变得更难:-)）。     

我知道这是一个严重的过度简化，因为像GWT这样的框架还有很多其他的东西，但我在这里看的是：如果你喜欢JavaScript，那就写JavaScript;如果你不这样做，可以使用GWT或Cappuccino或其他任何东西。 人们使用像GWT这样的框架的原因并不一定是它们提供的抽象 - 你可以使用像ExtJS这样的JavaScript框架 - 而是它们允许你用JavaScript以外的东西编写Web应用程序。如果我是一名想要编写Web应用程序的Java程序员，我会使用GWT，因为我不需要学习一门新语言。 真的，这都是偏好。我更喜欢编写JavaScript，但很多人不喜欢。