【发布时间】：2010-10-21 19:06:06
【问题描述】：
目前我们使用 jQuery 为我们的应用程序添加 RIA 优点，但最近我们一直在将 Coveo 搜索引擎实施到我们的 Sharepoint 门户中，并发现在他们的产品中使用了 ScriptSharp。 ScriptSharp 能带来什么？
【问题讨论】：
【发布时间】：2010-10-21 19:06:06
【问题描述】：
正如我们所说，我正在使用 ScriptSharp，大约 2-3 周前发现了它。老实说，我喜欢它。原生 Javascript 是一个挑战，而 DOM 模型让客户端编程更加糟糕。然后我在大约六个月前发现了 jQuery，我认为这是天赐之物。 jQuery 提高了我的工作效率，但我仍然经常使用 jQuery 陷入困境，因为您仍然需要编写、调试和调整 Javascript。
输入 ScriptSharp。它比 jQuery 提高了我的工作效率，并极大地减少了我的头痛。我能看到的最大优势是 C# 和 Visual Studio 的强大功能在您编写代码时是您的。它的强大功能不容小觑。现在，过去需要数小时才能调试的 Javascript 小错误在编译时被消除了。代码行数可能是 jQuery 的两倍，但生产力这么高，谁在乎呢？您基本上只是编写代码，编译/测试/调试周期要少得多。小时变成分钟。
我会说，最初让 ScriptSharp 与 Microsoft AJAX 一起工作是相当困难的，直到我了解到为了使用它而必须采取的非常重要的一步。在我知道这件事之前，我把头发拔了好几天。 （我相信这在 ScriptSharp 的 61 页 PDF 自述文件中有记录，但它非常很容易掩盖它。）关键是选择项目类型“网站内的脚本#类库”（或“网站内的 MS Ajax 类库”）创建 ScriptSharp 库时。这会将 ScriptSharp 项目放置在网站的 Bin/Scripts 目录中，并且 -- 非常重要 -- 将编译后的输出定向到该目录而不是默认的“bin " ScriptSharp 项目的目录。也许一个例子会很有启发性：
Web Site or Application directory\
Bin\
Scripts\ <-- "..\\" config setting sends .js files here.
ScriptSharp Project directory\
Bin\ <-- will not be used at run time
Debug\ <-- will not be used at run time
简而言之，我发现这个项目很有价值。我将编写我自己的 HOW-TO（在我的情况下涉及使用 Web 用户控件）关于如何将所有内容绑定在一起，并在此处发布一个 URL。现在我已经弄清楚了 ScriptSharp，它使我在 RIA 开发中的工作效率很高。要是它更显眼就好了，要是 CodePlex 网站还在那里就好了。
【讨论】：
-
谢谢 - 非常详细。一个跟进虽然 - 你说代码大小翻了一番，但是你有没有替代更轻量级的 jQuery 实现的地方？
-
不——自从我开始使用它以来，我还没有做过任何 jQuery 开发。我没有放弃 jQuery——我只是使用 Script# 来满足对 jQuery 不够强大或不够容易使用的功能的压抑需求。我认为 jQuery 的优势在于它的选择器——非常强大的东西——以及“流畅”的编码风格。 (en.wikipedia.org/wiki/Fluent_interface)
-
这里有一篇博文详细描述了必须将 ScriptSharp 项目放在 web 应用程序或 web 项目的 Bin\Scripts 目录中的事实：thinkfarahead.com/2008/07/tip-script-and-scriptpath_13.html
-
据称 2009 年底 Script# 将支持 jQuery。
-
我使用它的项目只持续了几个星期，但它在一个棘手的 AJAX 功能上为我提供了很好的帮助。我同意你的大部分反对意见，但它还远未消亡——它曾在 MIX11 上亮相——而且它即将开源。 （见github.com/NikhilK/scriptsharp.）我觉得使用与否有时是一个折腾，部分原因是你提到的因素。但是前几天我在一个项目中使用它来推出一个小功能，在原始 JavaScript 中（即使使用 jQuery）会花费我更长的时间，我只是知道。我觉得它可能更适合大型项目。
在上一家公司，我非常广泛地使用 Script#。我设法编写了一些很酷的控件（实际上是一个完整的客户端 MVC 堆栈），这是我无法用我的 javascript 知识完成的。但是，出于几个原因，我不会再次使用它
- 该项目是闭源的，支持不是很好（自从论坛关闭以来几乎不存在）。当您深入使用它时会有很多烦恼，如果您有来源，可以解决这些烦恼。您在 s# 代码上投入的资金越多，这就会成为一个越来越大的问题。
- 它仅限于 .NET 2.0 的一个子集，即便如此，它也是一个有漏洞的抽象
- 最近 Javascript 单元测试和 VS intellisense for javascript 变得更好，因此静态类型的重要性有所降低
- 使用它限制了我对 jquery 和 javascript 的学习
js 的工具只会越来越好，在 Script# 开源之前，它处于停滞状态。
如果您对交叉编译感兴趣，还可以查看http://jsc.sourceforge.net/ 项目，它可以让您使用 .net 3.5 并编译为 JS、Java、Flash 甚至 PHP！不确定生成的代码的效率如何......
编辑：有一个名为 JSIL 的新项目也将 .net 代码重写为 JS
【讨论】：
-
谢谢 - 虽然我本质上是一个 .Net，但我看到越来越多的工作是使用 Javascript 完成的，而 MS 只是忽略了这一点。我的团队的核心优势是 .Net，因此我们希望在向新方向拓展的同时继续发挥这种优势。
-
在他的 MIX11 演讲 (channel9.msdn.com/Events/MIX/MIX11/HTM16) 中，Nikhil Kothari 宣布他打算在 V1 发布后开源整个项目。在撰写本文时（v0.7.4），其中一些已经在 GitHub 上以 MSPL 提供：github.com/nikhilk/scriptsharp
jsc 编译器项目支持以下场景：
- C# 到 MSIL 到 JavaScript 的浏览器
- C# 到 MSIL 到 JavaScript for AppJet
- C# 到 MSIL 到 PHP5 的托管解决方案
- 用于浏览器小程序的 C# 到 MSIL 到 Java
- C# 到 MSIL 到 Java 的应用程序
- C# 到 MSIL 到 Java for JavaCard
- C# 到 MSIL 到 C99，用于本机存根应用程序
- C# 到 MSIL 到 ActionScript3 for Flash 9
- C# 到 MSIL 到 Adobe Alchemy C for Flash 9
- C# 到 MSIL 到 C# 2.0
通过一些努力，Visual Basic 也可以用作源语言。即使 GWT 和 Script# 这样做，jsc 编译器也不会读取您的源代码。我的编译器会读取您的 IL。
jsc编译器是
- 一个实验项目
- 一个人的努力呢
- 已经相当有用了。
- 3 岁。
- 等待捐赠以优化编译时间和输出本身
最新示例是等离子动画，其中single implementation 可以在这些平台之间使用：
- Flash 10
- Java Applet（通过画布元素）
- JavaScript
- Windows 窗体
- Windows Presentation Foundation
（来源：sourceforge.net）
【讨论】：
-
许可不明确，带有商业用途的隐含条款...？
Script sharp Prototype: Microsoft’s GWT
根据这个页面：
- 具有自然结构的简洁语言。
- 更容易重构和探索。
- 能够生成文档。
- 能够轻松自定义脚本代码。
我不确定我是否同意所有这些，但无论如何，这就是推销。似乎它带有一些 OO 功能。意见如下：正如我在其他时候提到的，Java 和 C# 开发人员似乎想要抛弃 Javascript 的原型/非类型化方面，因为他们不喜欢以这种方式编写代码。无类型的原型语言有它们的位置。
【讨论】：
-
我同意你关于无类型代码的观点。在处理 DOM 时，您没有那么多或相同类型的类型安全问题。我们注意到了 ScriptSharp，因为 Coveo 在他们的产品中使用了它。
-
我看到 Script# 的最大优势是您可以在常规 C# 上使用重构工具（例如 Jetbrain 的 Resharper 重构）并清理大型项目。据我所知，使用原始 JavaScript 很难做到这一点。
我想分享我的 Script# 的 jQuery 包装类。您现在可以在 Script# 项目中访问和使用 jQuery 的强大功能。
【讨论】：