InfoQ: 2011 has been a big year for WebSharper. What are some of the achievements that you are the most proud of?
Absolutely! Lots of things had happened around WebSharper in 2011, and certainly the one we are the most proud of was open sourcing the project itself. In the same sweep, we implemented a massive overhaul of the compiler and streamlined our translation path to make the JavaScript output better, more readable and easier to debug. We also invested heavily into our tooling support; into extending our HTML5 support; and into developing and updating various WebSharper extensions, now bridging to over two dozen mainstream JavaScript libraries from advanced visualization, charting, user interface controls and GIS to targeting HTML5 web-based mobile applications.
Web-based mobile applications are now an intriguing choice for mobile developers and offer a relatively painless path to develop with solid standards and multi-targeting in mind. You can now use WebSharper to develop Android and Windows Phone applications from the same F# code base, and you can easily hook in other packaging technologies to extend your platform coverage even more.
Overall, WebSharper solidified its #1 position in F# web programming and proved the path for web-based F# mobile applications, and we are quite happy about the direction this is taking.
InfoQ: Can you explain what you mean by tooling support? What kinds of things are you now offering in that area?
WebSharper tooling has been traditionally quite strong with tight Visual Studio integration, giving developers seamless build integration, single-click deployment, and various project templates to start from. Recently, we also added a handy functional testing framework for both server and client-side code. This means that developers can not only unit test their server-side code as with various existing unit testing frameworks, but also test the generated JavaScript code against an F# test specification and run those tests on various clients. This is especially useful when developing new extensions to different JavaScript libraries or when testing more elaborate client-side functionality or user interaction features.
Furthermore, we now also support various cloud hosted .NET environments and automated deployment hosts like AppHarbor, making it super easy to scale WebSharper applications into the cloud. This is an important enhancement and removes literally all obstacles from seamlessly migrating WebSharper web and mobile applications into the cloud. We continue to invest heavily in this area and, among others, are working on a cloud-based WebSharper IDE that enables development teams to develop and collaborate on various WebSharper projects without the need for installed software, all on the web. Developers can expect the first beta releases of WebSharper IDE in 2012 Q3.
InfoQ: How has your HTML5 support changed since the early versions of WebSharper?
WebSharper bindings can be developed to virtually any JavaScript library, and the HTML5 JavaScript APIs are no exceptions. In the latest releases, we enhanced our HTML combinator language to suit HTML5 DOM construction (data attributes and the like), and updated the HTML5 bindings to the latest API specifications, most notably to the WebSockets updates. This brings WebSharper HTML5 support in sync with the latest of the HTML5 specs.
InfoQ: Can you explain how the F# to JavaScript converter works?
WebSharper traditionally relies on F#-produced assemblies with special metadata embedded by the F# compiler. This metadata is similar to typed ASTs and contains various bits of information that we use to output modular JavaScript code that reflects the client-side content for each assembly. Translating assemblies, instead of generating per-site scripts, makes it easier to share libraries and distribute client-side functionality that can be consumed by other WebSharper applications. In fact, such parts and components can be shipped as .NET assemblies and referenced directly in compatible WebSharper projects without any more hassle.
In the upcoming 3.0 version of the product, we will also be providing an alternate compilation path that is based on .NET IL code instead of F# metadata. This will allow developing parts of or entire WebSharper applications in C# and other .NET languages, but at the same time keeping F# as a powerful and popular choice for both client and server-side code.
InfoQ: Is the F# to JavaScript converter available as a stand-alone API that developers can experiment with?
Not yet, but we are working on making this more accessible, even outside of WebSharper development projects. There is a clear advantage of being able to produce JavaScript code from .NET assemblies and smaller code units such as namespaces, classes or functions, and even arbitrary source text in different .NET languages. Our translation goes well beyond naïve code to code translation, and involves a significant amount of analysis to compute external resource dependencies (style sheets, external JavaScript files, etc.) and other metainformation that is invaluable in larger-scale translation scenarios. Harvesting these and other benefits as part of a stand-alone API is a short reach away and developers can expect not only such an API but also further metaprogramming capabilities in upcoming releases.
InfoQ: Why did you decide to release WebSharper as an open source project?
Primarily, this move reflects our ongoing conscious effort to increase the visibility of the project. We are faced with quite a challenge: even though F# has a quickly growing and steady mass of developers, there are relatively few who are web developers, and there are even fewer who are not only both but are also willing to pay for an expensive product. So by going open source, we are aiming to get a much larger slice of the growing F# developers by enabling authoring open source software at no cost, bringing in new web developers to F#, and turning more F# developers to web developers. Furthermore, we believe that there are a healthy number of derived opportunities such as trainings, basic and custom support plans, and other innovative, subscription-based services that we can build around WebSharper to make transitioning away from strictly selling a product easier and worthwhile.
Going open source also lifts the limitation that WebSharper is a closed and opaque product of a small company, which was a concern before to several larger and Fortune 500 companies with a more managerial mindset about the risks of innovating development approaches with a relatively new product backed by a smaller company. Now with WebSharper open source, there is clear transparency and no longer any fear about investing in a product that may disappear, and this also allows us to grow more synergically and to innovate in various new ways and build new and related services.
InfoQ: Can you explain why WebSharper went with a modified AGPL license and how the exceptions work?
WebSharper is both a framework, an SDK that facilitates and eases the development of web and web-based mobile applications, and in part a set of source files that are included in those applications, similar to any library.
Most developers who use WebSharper use it as a tool and a library: a tool to compile and build web and web-based mobile applications from F# code, and a library that is included within those. As such, these WebSharper applications include code from, and benefit from WebSharper directly. Here, developers have two choices: they either open source their entire application on GNU AGPL v3 or another open source license from the exceptions, or keep it closed as long as they have a valid developer license for each developer participating in developing that application.
This dual licensing model caters to both open source and closed source developers and seems to be a popular model with similar projects. AGPL fills an important hole over GPL in server-side scenarios such as client-server web applications, and even if AGPL is not favored or outright ruled out in an organization, their entire application code base can be licensed in any one of the license types listed in the WebSharper AGPL license exceptions, keeping only the code of WebSharper and its associated library components under AGPL.
The only significant exception is building other development frameworks based on WebSharper, which is not covered by the above dual licensing model and in turn requires special licensing. This, once again is not unheard of, several other open source projects apply similar restrictions to ensure that no work is taken unethical advantage of.
InfoQ: Lately there has been a lot of talk about the difference between open source and open development, the latter meaning the project accepts source code contributions from the general public. Do you see WebSharper moving into an open development model?
We certainly do in the long run. There are a healthy and growing number of WebSharper forks and new WebSharper extension and library projects with many WebSharper enthusiasts working on various extensions and new features. These range from keeping existing built-in extensions such as jQuery updated with respect to their underlying JavaScript libraries, to extending .NET coverage or enhancing the translation experience in various scenarios such as working with web services or supporting ORM and other data abstractions for the client.
Many of these community efforts are truly inspiring and represent a great deal of energy going into the platform. For instance, some are working to enable WebSharper applications to run in new web containers and are integrating with upcoming standards such as OWIN or Web.API.
You can surely expect these to make their ways into the main WebSharper code base at some point as we are moving to gradually embrace the open development model and starting to take code contributions in a controlled manner.