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的主代码库。
\ \