Version 3 of WebSharper, the F# framework for developing web applications hits RTM this year. We decided to catch up with Adam Granicz, CEO of IntelliFactory, to learn what new features and improvements WebSharper 3 brings.
InfoQ: In July 2012, you explained to InfoQ what WebSharper is and how it worked. Since then, what would you consider to be the key achievements for WebSharper?
Adam Granicz: Three years is a very long time, especially in the life of a single framework or library. We are extremely proud that WebSharper not only grew into a complete F# web ecosystem and remained the de-facto standard of F# web development, but also gained more traction in the larger web space within the .NET open source community - and that it sparked new ideas: type-safe, retargetable UIs via piglets, and reactive markup and dynamic data binding via UI.Next, among others.
For instance, UI.Next came as an experiment in designing functional, reactive web applications in F#. After having explored the JavaScript space with libraries like React.js, we were confident that we could design and implement a similar library in type-safe F#, one that combines and builds on the capabilities WebSharper brings to the language. UI.Next now offers a complete set of reactive markup capabilities including a unified client-server HTML language and reactive templating, dynamic data binding, and an infrastructure to implement pluggable persistence, and is planned to supersede the standard HTML capabilities in WebSharper from the next major release.
Regarding the mobile web front, we have added a range of new extensions for cross-platform mobile web development, including Kendo UI, Sencha Touch, and WinJS, and power tools like instant WYSIWYG integration with Sencha Architect. We continue to invest heavily in this space, with the inclusion of Material Design UI libraries and a totally revamped PhoneGap support, among others.
We also rolled out a whole line of iterations on our CloudSharper web IDE, with built-in support for WebSharper projects, including an interactive web REPL, data charting and visualization, and support for local code services. CloudSharper is now on its way to be more tightly integrated with our other F# online tools to give developers the ultimate online coding and code exploration experience.
InfoQ: WebSharper is now on an Apache license. Why did you change from a modified AGPL license?
AG: We moved to Apache in December 2014, by when it became clear that our previous dual-licensed AGPL model was limiting the visibility and community penetration of the project. Many potential enterprise users came with a prejudice towards AGPL (see Google and others) even though we offered OSS license exceptions to most popular formats, or just simply didn’t want to open source their products in order to use WebSharper. On the other hand, we knew that a less restrictive OSS license was a sure way to attract more OSS developers. Overall, this move seemed to be the most straightforward going forward. Since the move to Apache, WebSharper downloads are up several fold and show constant increase, and so does community involvement in providing pull requests, forks, extensions, samples and applications, social site activity, etc.
InfoQ: WebSharper 4 will include C# support. Can you give some details about it? For example, what version of C# will be supported?
AG: We are targeting C# 6, but earlier C# projects should work as well. WebSharper for C# will use similar code annotations as the F# counterpart, and will generate assemblies that can work in mixed language scenarios. So it will be possible to combine C# and F# projects into a single WebSharper application, or distribute WebSharper libraries and extensions compiled with and for use with either language.
For this to happen, we have also re-engineered the core compiler and will be integrating the F# compiler and the WebSharper one into a single pass. This will have a positive impact on compilation speed and the ability to share a wider code path with the C# version.
InfoQ: Microsoft made its compiler platform Roslyn open source a few months ago. Do you have any plans to use it?
AG: Yes, we already use Roslyn to parse C# files and projects, and then we convert these Roslyn ASTs into our internal representation that is shared between C# and F# projects. So Roslyn is used as the first step in the pipeline to parse C# source files and projects.
In contrast off other existing C# to JavaScript translators, our main aim is to maintain a good balance on the generated code size, provide interoperability with JavaScript libraries, being able to address them with idiomatic C#, and bringing access to the existing F# ecosystem and tool set.
Using the F# ecosystem, we can enable C# projects to implement/use/consume sitelets (modeling entire web applications as values in the type system), formlets and flowlets (representing web forms as composable, type-safe values), piglets (like formlets but with pluggable rendering), and the reactive abstractions available in UI.Next, among others. These are key WebSharper features that we now bring to C#. C# code can also access the rest of the ecosystem, including 50+ extensions (to different JavaScript libraries), bringing it on par with the F# version we have now.
InfoQ: WebSharper has been open source since early 2012. How would you qualify the involvement of the community so far? How does it compare to your expectations?
AG: Open source is a young but core driving force behind the success of F#. The community has greatly benefited from the openness and has attracted a much larger audience than anyone thought was possible, genuinely and immensely inspiring other parts/projects of the .NET ecosystem. As with any open community, there is a degree of fragmentation where certain groups or individuals spin off personal projects instead of contributing to existing projects, and equally, many projects suffer from under-representing their potential by not providing an easy path to contributing, missing relevant documentation, or just simply marketing themselves in a less visible way. We are certainly guilty of many of these ourselves and have learned a lot from those early times.
Looking back, the dual AGPL model did not help to grow fast enough initially and it also put some potential F# and WebSharper adopters off – yielding only modest community involvement up until we switched to Apache. However, we continued tirelessly to roll out exciting new capabilities and new extensions – many of which only made it to existing license holders and our few dozen customers, and largely fell off the radar of the wider community that was not so much into F#+web just yet.
We spent much of the post-AGPL period (about nine months) with creating ways to demonstrate just how much WebSharper improves web developer productivity, and making it easy to experiment with F# on the web with tools like Try WebSharper and CloudSharper. By now, these have attracted a much wider audience and community contribution is picking up steadily, and our users are rediscovering the full potential of the ecosystem that exists today. Our plan is to continue lowering the barrier to get involved with and learn about WebSharper.
More information about WebSharper, along with documentation and tutorials can be found on the official website. It is also possible to try it online through a web IDE and experiment with the already existing samples.