应该避免使用GWT/WebSharper还是其他抽象来编写Javascript？

我很好奇什么是“编译成JavaScript的东西”的观点，例如GWT，Script＃和WebSharper等。这些似乎是相当利基的组件，旨在让人们在不写javascript的情况下编写javascript。我个人很喜欢编写javascript（使用JQuery/Prototype/ExtJS或其他类似的库），并将诸如GWT这些东西视为不必要的抽象，这可能最终会限制开发人员需要完成的任务或提供最佳案例非常冗长的解决方法。在某些情况下，您最终还是会编写javascript JSNI。应该避免使用GWT/WebSharper还是其他抽象来编写Javascript？

更糟糕的是，如果您不知道封面下面发生了什么事情，那么您将面临意外后果的风险。例如。你怎么知道GWT正在创建闭包和管理命名空间？

我很好奇听到别人的意见。这是网络编程的目标吗？

来源

2010-07-10 Francis Shanahan

虽然我个人不喜欢一种风格而不喜欢另一种风格，但我不认为从Javascript抽象出来的这些框架带来的唯一好处就是它。当然，在抽象整个语言的过程中，会有以前可能变得不可能的事情，反之亦然。决定使用诸如GWT之类的框架来编写vanilla JavaScript取决于很多因素。

使JavaScript与X语言的讨论毫无结果，因为每种语言都有其优点和缺点。相反，通过采用这样一个框架来对将要获得或失去的东西进行客观的成本效益分析，而这只能由你而不是不幸的SO社区来完成。

不知道底层的问题适用于JavaScript，就像它对任何翻译过的源代码一样。你认为有多少人知道jQuery究竟发生了什么，因为他们试图做一个比较，比如$("p") == $("p")，并且因此返回false。这不是假设情况，关于同样的问题也有几个问题。学习语言或框架需要时间，如果有充足的时间，开发人员可以理解这些框架的编译源。

上述问题的另一个相关方面是信任。我们不断在较低层次的抽象层次上构建更高层次的抽象，并依靠低层次的东西应该按预期工作的事实。你最后一次深入到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应用程序，因为下一代解决方案可以从每个解决方案的失败中学习，并专注于他们的成功构建更好，更快，更棒的工具。

来源

2010-07-11 02:03:22 Anurag

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

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

来源

2010-07-10 18:52:35 eSniff

我知道这是一个粗略的过度简化，因为像GWT提供的框架还有很多其他的东西，但这里是我如何看待它：如果你喜欢JavaScript，写JavaScript;如果你不这样做，使用GWT或卡布奇诺或其他。

人们使用像GWT这样的框架的原因不一定就是它们提供的抽象 - 你可以使用像ExtJS这样的JavaScript框架 - 但它允许你用JavaScript以外的东西编写Web应用程序。如果我是一个想要编写Web应用程序的Java程序员，我会使用GWT，因为我不需要学习新的语言。

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

来源

2010-07-10 19:04:38

JavaScript应该避免使用X吗？无论如何！

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

对我来说，JavaScript是web的便携式组件，履行与C在世界其他地方一样的作用。它是便携式的，广泛使用的，它会留下来。但我不想写JavaScript，不过我想编写程序集。我不想使用JavaScript作为一门语言的原因包括：

没有静态分析，它甚至不检查函数调用的参数的权数。错字咬人！
图书馆，命名空间，模块，类没有或非常有限的概念，因此每个框架都发明了自己的（与R5RS计划类似的情况）。（1）和（2）：JavaScript不适用于静态分析。工具（代码编辑器，调试器，分析器）相当差，大部分是因为（1）和（2）：JavaScript不适合静态分析。
没有或非常有限的标准库。
有许多粗糙的边缘和使用突变的偏见。即使在无类型的家庭中JavaScript也是设计不佳的语言（我更喜欢Scheme）。

我们正试图解决WebSharper中的所有这些问题。例如，Visual Studio中的WebSharper具有代码完成功能，即使它公开第三方JavaScript API（如Ext Js）。但是，我们是否有成功或失败并非真正的重点。关键在于，我希望能够解决这些问题，这是非常可取的。

更糟的是，如果你不知道什么是被窝里怎么回事
运行的意想不到的后果风险。例如。您如何知道GWT正在创建关闭和正确管理名称空间？

这只是编写正确的编译方式。例如，WebSharper以1：1的方式将F＃lambda映射到JavaScript lambda（实际上，它从不引入lambda）。如果您提到这一点，我可能会接受您的观点，比如说，WebSharper还不够成熟并且测试不足，因此您不愿相信它。但是，GWT已经有一段时间了，应该生成正确的代码。

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

来源

2010-07-13 06:55:44 t0yv0

我有三个大的实际问题，我与websharper和其他编译器，声称避免JavaScript的痛苦。

如果您不会很好地了解Javascript，那么您无法理解使用DOM/ExtJs等Web上的大多数示例，因此您必须学习Javascript。（由于某些原因，所有F＃程序员必须至少能读取C＃或VB.NET，否则他们无法访问大多数关于.net框架的信息）
在任何Web项目上，您都需要一些知道DOM的Web专家， CSS里面出来了;这样的人愿意使用F＃而不是Javascript吗？
被捆绑到编译器的提供者中，他们将在5年左右的时间内;我想要完整的开源代码或者微软支持的工具。

的4个大阳性我与这些框架看到的是：

共享型码
拥有更少的语言程序员需要知道（JavaScript是一种真正的痛苦，因为它看起来像Jave/C＃，但不是像他们那样）
F＃程序员的平均质量比jscript程序员要好很多。

来源

2011-04-13 10:41:09

+1如果提到'绑定到编译器的提供者'的问题 – 2011-04-19 14:00:35

WebSharper现在是开源的，但考虑到你写这个时，这是一个非常好的答案。 – 2012-07-04 15:52:22

“出于某种原因，所有F＃程序员都必须至少能读取C＃或VB.NET，否则他们无法访问大多数关于.net框架的信息”。 FWIW，这当然不是真的。 – 2012-11-11 12:45:37

应该避免使用GWT/WebSharper还是其他抽象来编写Javascript？

回答

相关问题