GWT 与 ScriptSharp 的优缺点 [关闭]答案

【问题标题】：GWT vs. ScriptSharp Pros and Cons [closed]GWT 与 ScriptSharp 的优缺点 [关闭]
【发布时间】：2010-07-21 21:03:30
【问题描述】：

我们已经确定，要维护编写完整的“单页”javascript“应用程序”所需的大量 javascript 对我们来说太难了。依赖编程约定仍然让我们想要……尤其是在重构领域。对于这些项目的新手来说，他们发现很难改变任何东西，因为他们不相信他们知道还有谁真正依赖于组件（通过“查找所有引用......”和代码访问级别很容易做到这一点）打字语言）。

我们一直在使用 GWT，但我们的一位开发人员想要使用 Script#。我们已经是一家基于 Microsoft 的商店，我们所有的服务器端工作都是用 C# 完成的。

我不认为 java 是 GWT 的阻碍，因为它与 C# 极为相似。

我最初对 Script# 的担忧主要围绕支持和文档。

一方面我们有 Google，另一方面......“Some Dude”。 Script# 也是封闭源代码......所以如果开发人员停止开发它，我们是 S.O.L. 吗？我也觉得 GWT 有更多的文档和社区支持。

不管怎样，你都用过吗？想法？优点/缺点？

（顺便说一句：问题不在于是否使用编译器......问题是哪个编译器）

类似但不同的问题：

What advantages can ScriptSharp bring to my tool kit?
Should I use ScriptSharp

【问题讨论】：

标签： javascript gwt script#

【解决方案1】：

我使用 Script#，之前使用过 GWT。他们真的是两种不同的东西。 GWT 旨在提供客户端和服务器解决方案，包括 RPC 和其他一切。它肯定更成熟，您可以更快地进行复杂的应用程序。简而言之，还有更多的代码和示例。

但是，我认为如果您是服务器端和客户端的开发人员，使用两种不同的语言和两种不同的平台可能会非常非常繁琐。这就是我搬到 Script# 的原因。我所做的一切都在 C# 和 Visual Studio 中，它让我的工作效率更高。如果您不利用 GWT 的后端功能，那真的是大材小用了。

我喜欢将 Script# 视为用 C# 2.0 规范（确实如此）编写的 Javascript。它完全是客户端，任何类型的映射都必须手动完成（尽管可以广泛使用自动映射）。它对 Javascript 和 jQuery 的支持非常完整，实际上它是如此完整，这让我感到惊讶。看起来它做的比实际少。

angryundead 的观点是有效的，尤其是在社区和开放性方面。虽然这对我来说有点棘手，但我真的非常喜欢使用 Script#。我不必更改 IDE，也不必查找如何在 Java 中做事等。jQuery 有一个庞大的插件库，将它们挂接到 Script# 中非常非常容易。您只需抛出一些对象来表示属性，将它们注释为“导入”并让它返回 null。在您的代码中，您将对象转换为插件，并且您的输出与 Javascript 中的输出完全相同。 Script# 不关心/知道插件是如何工作的。

不要让缺少社区支持的 Script# 愚弄您。虽然这是一个问题，但该产品非常成熟且功能丰富。如果您的开发人员使用 C#/VS，为什么要让他们为客户端使用单独的程序？我发现这对生产力造成了巨大的打击。

顺便说一句，自从使用 C# 以来，我在 Javascript 方面变得更好了。 Javascript 的许多问题是缺少您并不真正需要的语言功能，但在大型项目中，这是使其易于管理的唯一方法。

【讨论】：

嘿！感谢您抽出宝贵时间回复！！作为记录，我确实对脚本#表示同意，但我确实（并且仍然）有顾虑和保留。但归根结底，我觉得开发人员，就像木匠一样，需要享受使用他们的工具......而且我不打算强迫 GWT 进入任何人的喉咙。很高兴知道其他人使用 script# 效果很好。
Script# 确实有一个庞大的 (?) 用户社区，我相信：微软内部的开发人员创建了 MVC 分发的控件。诚然，这个社区比 GWT 还小，我已经等不及它开源了。
我对 Script# 自动映射很好奇。它是如何完成的？由于这个线程是古老的，我并不真的期待回复，但希望永远存在。 ;)

【解决方案2】：

我已经使用 GWT 好几年了。我从未听说过 Script#，所以我只会告诉你为什么要坚持使用 Google 解决方案。

积极发展。 Google 拥有一支付费的工程师团队，他们既积极修复缺陷，又致力于开发新功能。我目前正在与其他一些开发人员讨论如何为 GWT 实现新功能。
大型机构。谷歌投资了这个项目，并用它来实施大规模的解决方案。换句话说，他们正在吃自己的狗粮。不让它停滞不前或过时是他们的既得利益。
社区。有很多人在开发插件/第三方/等库和 API，以便与 vanilla 发行版一起使用。这些人也在测试、归档和修复缺陷。
兼容性。 GWT 可以处理浏览器可以做的任何事情。还有一些适用于 jQuery 和其他主要 JavaScript 库的插件，它们可以让您在使用 JavaScript 时更轻松地管理项目的复杂性。
打开。你自己也接触过。

请注意我没有涉及语言选择问题。我认为这与您描述的水平无关。请记住，当您第一次遇到 Script# 的限制或障碍时，由于您和我所描述的事情，您很快就会陷入困境。

当然，我推荐 GWT 只是因为它的业绩记录。

【讨论】：

有趣的是没有人发表反驳。
我将答案归功于您，因为看起来其他人不会回复，我要感谢您的时间。再次感谢。

【解决方案3】：

如果您想在 JavaScript 代码中使用 C#，我建议您使用 SharpKit。它有一个 feature comparison 和其他 C# 解决方案。此外，作为其应用程序的示例，您可能需要查看使用 SharpKit 创建的 CodeRun。

【讨论】：

有趣！感谢您的链接！

【解决方案4】：

除非您要构建一个完整的浏览器内应用程序，否则我的首选是 Script#，因为它坚持自己最擅长的事情——将 C# 编译为 JavaScript——而不是试图成为一个全面的客户端/服务器工具包。 Web 范式变化很快，将项目投资于 GWT 可能会给您带来您希望没有的开销或技术承诺。但我要补充一点，这实际上取决于您尝试构建的 Web 应用程序或 Web 体验的类型。

就个人而言，我已经非常熟悉 jQuery、WCF，并且开始直接使用新的 HTML5 功能。 Script# 是完美的缺失部分，因为我可以非常轻松地继续使用 jQuery 和 WCF，而且我不需要经历切换或集成 GWT 的范式或要求的麻烦。

另外，在 UI 构建方面，您可能会考虑我最近开源的 Sharp UI，它可以更轻松地在 jQuery+Script# 设置中构建可重用控件。

【讨论】：