Adam Granicz 聊 WebSharper

InfoQ：2011 是 WebSharper 的重要一年。哪些成就是你最感到自豪的？

绝对是这样！2011 年 WebSharper 发生了很多事情，项目开源绝对是其中我们最为自豪的一件事。借着这股势头，我们彻底翻新编译器，调整翻译流程，输出更漂亮的 JavaScript 去提高可读性和降低调试难度。另外我们投入了巨大的资源和精力在工具支持和 HTML5 支持两个方面，此外还有开发和更新各种 WebSharper 扩展。现在已经能够兼容二、三十种主流的 JavaScript 库，其领域涵盖高级的可视化、图表绘制、用户界面控制、GIS 等等，基于 HTML5 的移动应用开发也包括在内。

基于 Web 的移动应用现在是移动开发者的新宠，它以坚实的标准和多目标平台为前提，提供了一种相对无痛苦的开发途径。WebSharper 让你用相同的 F#代码同时开发出 Android 和 Windows Phone 应用。如果需要支持更多的目标平台，挂接其他打包技术也不困难。

总地来说，WebSharper 稳固了它在 F# web 开发领域的第一名位置，还证明用 F#开发基于 Web 的移动应用完全可行。我们对于现在的发展方向很满意。

InfoQ：你可以具体说一下工具支持的方面吗？你们现在提供哪些东西？

WebSharper 的工具支持一向很充分，它和 Visual Studio 紧密集成，开发者可以获得无缝的构建集成和一键部署功能，项目模板也很丰富。最近我们又增加了一套方便的函数式测试框架，对服务端和客户端代码都适用。也就是说，开发者除了用现有的单元测试框架对服务端代码进行单元测试，还可以在各种客户端上，用 F#编写的规格说明去检验生成的 JavaScript 代码。这种功能在为 JavaScript 库开发扩展的时候特别有用，也适合用来对客户端功能和用户交互做详细测试。

另外，我们现在支持各种云上的.NET 环境，可以自动部署到 AppHarbor 等服务，WebSharper 应用通过云来扩大规模是很方便的。这是一项重要改进，迁移 WebSharper web 应用和移动应用到云上已经没有障碍。我们会继续增加这方面的投入，目前有一个基于云的 WebSharper IDE 正在开发当中，以后开发团队不需要安装软件，在 Web 上就可以同时参与多个项目的协作开发。WebSharper IDE 的第一个 beta 测试版将在 2012 年第三季度面世。

InfoQ：与早期的 WebSharper 相比，现在对 HTML5 的支持有什么进展吗？

任何 JavaScript 库都可以开发相应的 WebSharper 绑定，各种针对 HTML5 的 JavaScript API 也不例外。在最新的版本里面，我们加强了 HTML 组合子语言，让它适应 HTML5 的 DOM 结构（如 data attributes 等等），还按照最新的 API 规范更新了 HTML5 绑定，其中最重要的部分是针对 WebSockets 的更新。所以 WebSharper 的 HTML5 支持与最新的 HTML5 规范保持同步。

InfoQ：能否解释一下 F#-JavaScript 转换器的工作原理？

WebSharper 一直以来都依赖 F#生成的 assembly，F#编译器会在里面嵌入特殊的元数据。这种元数据类似于类型化的 AST，我们可以利用里面的信息，对应每个 assembly 里面的客户端内容，生成模块化的 JavaScript 代码。相对于以站点为单位来生成脚本，采取翻译 assembly 的方式，便于在 WebSharper 应用之间共享各种库，重用一些客户端功能。重用组件可以用.NET assembly 的形式交付，兼容的 WebSharper 项目只要引用一下就行了，非常方便。

我们在即将发布的 3.0 版中提供另一种编译路径，从依赖 F#元数据改为基于.NET IL 字节码。这样做是为了允许开发者用 C#或者别的.NET 语言来开发组件和整个 WebSharper 应用，同时 F#作为一种客户端和服务端都适用的优秀选项，被保留下来。

InfoQ：F#-JavaScript 转换器是否可以独立出来，成为开发者的试验工具？

现在还不行，但我们正努力去除各种限制，让它可以用在 WebSharper 项目之外的地方。我们从.NET assembly 生成 JavaScript 代码的能力是占优势的，我们有能力处理命名空间、类、函数等更小的代码单元，甚至处理任意.NET 语言的任意代码段。我们的翻译已经不是幼稚的、代码到代码的翻译，里面牵涉到大量的分析，例如计算外部资源依赖（如样式表、外部 JavaScript 文件等），大规模的转换场景还会涉及其他必不可少的元信息。以上能力，以及别的一些好处，很快会作为独立 API 提供给大家。除此之外，下一版的元编程能力值得大家期待。

InfoQ：你为什么决定将 WebSharper 变成开源项目?

首先，开源的举动是我们持续有意识提高项目透明度的结果。我们面对着非常困难的挑战：虽然 F#的用户数量增长很快也很稳定，但其中的 web 开发者相对较少，而愿意为一个昂贵产品付费的就更少了。开源之后，我们有机会通过一套开源免费的创作软件争取更多的 F#开发者，既引导更多 web 开发者接触 F#，又转化更多 F#开发者成为 web 开发者。我们相信开源项目会衍生出足够维持自身发展的商业机会，让我们摆脱单纯的产品销售模式，围绕 WebSharper 建立更有价值的培训、技术支持，以及其他创新的付费服务。

WebSharper 原本只是一家小公司的一个封闭、不透明的产品，曾经有大企业、财富 500 强企业表达过这样的担忧，它们的管理思路难以接受小公司、新产品、新开发方式带来的风险。开源解除了这方面的限制。项目公开透明，用户不用担心产品突然消失掉。我们也获得成长空间去尝试一些创新思路，建立更多周边服务。

InfoQ：能否解释一下，为什么 WebSharper 选择附带条款的 AGPL 作为许可协议？其中的例外条款应该怎么理解？

WebSharper 是框架也是 SDK，一方面它帮助和简化 web 应用、基于 web 的移动应用的开发工作，与此同时，它和别的库一样，会有一部分代码会成为应用的一部分。

大多数 WebSharper 用户把它当作工具和库来使用：编译和构建 F#代码，这是它的工具用途，被包含在应用里面，这是它的库用途。应用直接受益于 WebSharper 的代码。那么开发者就有两个选择：第一种选择，他们可以按照 GNU AGPL v3 或者例外条款中允许的其他许可协议，将整个应用开源；第二种选择，保证每一个参与应用开发的人员，都持有有效的开发者许可证，在此前提下，可以保持闭源。

双重许可同时满足开源和闭源开发者的需要，在类似项目中是一种常见的许可模型。AGPL 修补了 GPL 在服务端使用场景，如 CS 结构 web 应用等场景下的重要漏洞。假如开发者不喜欢 AGPL，或者组织明确排除 AGPL，那么也可以选择让应用整体代码适用例外条款中列出的其他许可种类，只有应用内包含的 WebSharper 代码和相关库组件必须遵守 AGPL.

有一种重要的例外情况并不包含在双重许可的范围内——在 WebSharper 的基础上构建其他开发框架，必须先取得特别许可。这种要求是有先例的，有些开源项目通过类似的规定来保护成果不被恶意利用。

InfoQ：现在对源码公开和开发公开的区别有不少讨论。开发公开说的是项目接受来自公众的代码贡献。你认为 WebSharper 会采取开发公开的运作模式吗？

长期来说，肯定会的。WebSharper 社群的人数和发展势头都很健康，新的扩展和库一直冒出来，很多人热心地开发各种扩展和新功能。像保持同步更新 jQuery 等库对应的内建扩展，增加对.NET 语言和库的覆盖，改善不同场景下的翻译效果，对接 web 服务，支持 ORM 和其他数据抽象，这些事情都有人在做。

社区里面表现出来的热情和努力，代表了这个平台被激发出来的的巨大能量。甚至有人打算让 WebSharper 应用运行在新的 web 容器里面，集成 OWIN、Web.API 等未来标准。

随着我们按照自己的步骤拥抱开放的开发模式，可以预期社区贡献会在一种可控的模式下，进入 WebSharper 的主代码库。

查看英文原文： Talking WebSharper with Adam Granicz