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用作语言的原因包括：

没有静态分析，甚至不检查是否使用正确数量的参数调用函数。错别字！
库，名称空间，模块，类没有或非常有限的概念，因此每个框架都发明了自己的（与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已经存在了一段时间，应该生成正确的代码。

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

Answer 2

虽然，我个人并不喜欢一种风格，但我认为从Javascript中抽象是这些框架带来的唯一好处。当然，在抽象整个语言的过程中，会有一些以前不可能实现的事情，反之亦然。决定使用像GWT这样的框架来编写普通的JavaScript取决于很多因素。

将JavaScript与语言X的讨论毫无结果，因为每种语言都有其优点和缺点。相反，通过使用这样的框架，对可以获得或丢失的内容进行客观的成本效益分析，而且这只能由您而不是SO社区完成。

不知道幕后发生了什么的问题适用于JavaScript，就像对任何已翻译的源一样。你认为有多少人在jQuery尝试进行$("p") == $("p")之类的比较时会确切地知道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应用程序的框架和解决方案中拥有所有这些多样性非常棒，因为下一代解决方案可以从每个解决方案的失败中学习，并专注于他们的成功，以构建更好，更快，更棒的工具

Answer 3

我在websharper和其他编译器方面有三大实际问题，声称可以避免Javascript的痛苦。

如果你不熟悉Javascript，你无法理解网上使用DOM / ExtJs等的大多数例子，所以你必须学习Javascript。（由于某种原因，所有F＃程序员必须能够至少读取C＃或VB.NET，否则他们无法访问有关.net框架的大部分信息）。
在任何网络项目中，您需要一些了解DOM和CSS的网络专家;这样的人是否愿意使用F＃而不是Javascript？
与编译器的提供者联系在一起，它们将在5年后出现;我想要完全开源或Microsoft支持的工具。

我在这些框架中看到的四大积极因素是：

在服务器/客户端之间共享代码
程序员需要知道的语言较少（javascript是一个真正的痛苦，因为它看起来像Jave / C＃，但不是像它们一样）
F＃程序员的平均质量比jscript程序员好很多。

Answer 4

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

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

Answer 5

我知道这是一个严重的过度简化，因为像GWT这样的框架还有许多其他的东西，但我在这里是如何看待的：如果你喜欢JavaScript，那就写JavaScript;如果你不这样做，可以使用GWT或Cappuccino或其他任何东西。

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

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

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

5 个答案: