By Loïc Denuzière on Wednesday, January 13, 2016 — 3 comments

WebSharper 3.6.7 releasedCore team

We are pleased to announce the release of WebSharper 3.6.7. This is a minor release with bug fixes and updates for dependent libraries. Here is the full change log.


  • #512: Fix JSON deserialization of [<NamedUnionCases>] union types in some situations.


  • #8: Update to Suave 1.0.0.


  • #65: Fix initial selected index in Doc.Select.
  • #66: Fix exception when calling a client function from server in on.*.


  • #8: Fix Autocomplete.Source's variants to use a union case. Thanks @juselius for your contribution!

Happy coding!

By Adam Granicz on Saturday, December 26, 2015 — 2 comments

WebSharper - a year in reviewCore team

WebSharper – a year in review

Just over a year ago, last year in December we released WebSharper 3 on Apache, putting it into the hands of every F# web developer. One thing we learned from WebSharper 2 is that more frequent releases are better and this year kept the whole team busy with constant innovation and new releases. Below is a list I cherry-picked from the WebSharper blog:

We have also:

Conferences and academia

This year we concentrated on getting work out and attended fewer conferences than in previous years. In 2014, the WebSharper team gave 16 talks on WebSharper in six countries, this year we gave nine talks in six countries.

The team submitted three research papers to academic conferences in 2015, continuing our tradition to publish research results in peer-reviewed conferences.

Next to conferences and research papers, our team has been active in teaching and trainings. Among others, we run functional reactive web development courses with F# and WebSharper at the Eotvos Lorand University (ELTE) and the University of Dunaujvaros, and have signed a similar agreement with the University of Szeged. We are also involved in creating an online semester long course for international students.

Coming up

Our WebSharper team has been cooking up some awesome things that are not yet available or not yet documented. In particular, with more blog entries coming up on each:

  • WebSharper 4 - we are finalizing the last bits of moving WebSharper to the F# Compiler Services (FCS) and merging the F#+WebSharper compilation steps into a single sweep, giving a significant boost to compilation speed, better F# language coverage, and fixing a number of corner cases in earlier releases. The first alphas are out in early January under a new WebSharper codename “Zafir”.

  • WebSharper 4 for C# - we are finally able to bring WebSharper to C# developers, covering the most common C# scenarios (asyncs, LINQ, etc.), most of the language, and calls to any one of the existing extensions in the WebSharper ecosystem. A lot more on this in upcoming blogs.

  • WebSharper.React - bringing React to WebSharper applications. Here is a live example:

  • WebSharper.LiveData - automatic syncronization of reactive data models between a server and its participating clients. You can read a draft of our first, upcoming tutorial.

  • WebSharper.Forms and WebSharper.Forms.Bootstrap - reactive web forms (aka. reactive Piglets) with custom rendering. Here is a live example that uses Bootstrap-based rendering for a login form:

  • New extensions, in particular WebSharper.JointJs and WebSharper.Rappid - bringing awesome diagramming solutions to WebSharper:

  • Updating CloudSharper with the latest WebSharper - this has been left on the backburner for several releases, now it's time to sync the two again. Once this work is finished, CloudSharper will be your one-stop shop for online web and mobile development with C# and F#; quick data access, analytics and visualization, and a host of other interactive capabilities.

This article gave you a quick overview of WebSharper in 2015, and is by no means complete. One thing is certain: WebSharper remains the primary choice for F# web developers, giving unparalleled productivity and access to the largest F# web ecosystem, and works well with a number of other efforts (ASP.NET, MVC, OWIN, Suave, Hopac, etc.) in the web and development space.

Happy coding and Happy Holidays!

By Loïc Denuzière on Tuesday, December 15, 2015 — 0 comments

WebSharper 3.6.6 releasedCore team

We are happy to announce the release of WebSharper 3.6.6. Here are the main highlights.

Cookies library

We integrated a library to facilitate the management of cookies on the client side. It is available under WebSharper.JavaScript.Cookies. Here is a small example:

open WebSharper
open WebSharper.JavaScript

let testCookies() =

    // Set a cookie
    Cookies.Set("key", "value")

    // Set a secure cookie which expires in a day
    Cookies.Set("key", "value",
            Secure = true,
            Expires = System.DateTime.Now.AddDays(1.).JS))

    // Get a cookie
    let value = Cookies.Get("key")
    // Delete a cookie by setting it to expire immediately

Require resources in server-side markup

It can sometimes be useful to depend on a resource, such as a CSS file, without having any client-side markup. This is now possible using a WebSharper.Web.Require control.

open WebSharper

// Let's say you have a resource defined:

type MyResource() =
    inherit Resources.BaseResource("style.css")

[<assembly: System.Web.UI.WebResource("style.css", "text/css")>]
do ()

// And you want to include it in your page that doesn't contain client-side code.

// Using UI.Next:
open WebSharper.UI.Next
open WebSharper.UI.Next.Html
open WebSharper.UI.Next.Server

let styledElement() =
    div [
        text "A page containing this element will include style.css"
        Doc.WebControl (Web.Require<MyResource>())
        // Or equivalently:
        Doc.WebControl (Web.Require(typeof<MyResource>))

// Using WebSharper.Html:
open WebSharper.Html.Server

let styledElement() =
    Div [
        Text "A page containing this element will include style.css"
        // Or equivalently:

That's it for the main new features; here is the full change log.


  • #491: Remove reference from WebSharper.Sitelets.dll to WebSharper.Compiler.dll
  • #498: Add WebSharper.Web.Require (see above).
  • #502: Add client-side Cookies library (see above).
  • #503: Window inherits from EventTarget, allowing the use of AddEventHandler on JS.Window.
  • #504: MSBuild task: force loading the right version of FSharp.Core in the appdomain.
  • #506: In unpack task, use $(OutDir) if set.
  • #507: Honor optional arguments Async.AwaitEvent(?cancelAction) and Async.StartChild(?timeout).
  • #508: bind multiple-argument versions of JSON.Stringify.
  • #509: Fix JSON.Serialize macro for recursive types.
  • Add missing proxies for querySelector and querySelectorAll on Window and Dom.Element.
  • Add proxy for System.TimeoutException.
  • Always extract resources when WebSharperProject is Site, thus fixing WebSharper.Suave #7.


  • #60: Templating: allow using the same simple text hole in multiple places.
  • #65: Make sure to set the selected element after rendering the select box.

Happy coding!

By Loïc Denuzière on Monday, November 23, 2015 — 2 comments

WebSharper 3.6 released with CDN supportCore team

We are happy to announce the release of WebSharper 3.6.

The main new feature is the capability to point to our CDNs for the WebSharper libraries. You can simply add the following setting to your application configuration file (Web.config or App.config depending on the project type):

  <add key="WebSharper.StdlibUseCdn" value="true" />

The links generated by WebSharper, instead of pointing to /Scripts/WebSharper/... for scripts and /Content/WebSharper/... for CSS, will point to //{assembly}/{version}/{filename}. You can configure this URL by setting the WebSharper.StdlibCdnFormat configuration setting. And finally, you can configure the CDN URL for the resources of a specific assembly (from the standard WebSharper library or not) by setting the WebSharper.CdnFormat.{assemblyname} configuration setting.

Here is the full change log:

  • #488: Allow adding a macro attribute on a type. The macro is invoked for all static and instance method calls on this type.

  • Fix issue preventing macro use in argument to a PropertyGet/Set.

  • #490: Retrieve appConfig parameters from Web.config or App.config when building a single-page application.

  • #493: Add WebSharperReference project item. This allows you to pass references to the WebSharper compiler that are not referenced by the compiled assembly. For example, adding the following to your project file:

      <WebSharperReference Include="..\packages\WebSharper.\lib\net40\WebSharper.Core.dll" />
      <WebSharperReference Include="..\packages\WebSharper.\lib\net40\WebSharper.Core.JavaScript.dll" />
      <WebSharperReference Include="..\packages\WebSharper.\lib\net40\WebSharper.JavaScript.dll" />
      <WebSharperReference Include="..\packages\WebSharper.\lib\net40\WebSharper.JQuery.dll" />
      <WebSharperReference Include="..\packages\WebSharper.\lib\net40\WebSharper.Main.dll" />
      <WebSharperReference Include="..\packages\WebSharper.\lib\net40\WebSharper.Control.dll" />
      <WebSharperReference Include="..\packages\WebSharper.\lib\net40\WebSharper.Collections.dll" />

    and removing the corresponding <Reference> entries allows you to use the proxies from the standard libraries without referencing them in your assembly.

  • Add AssemblyFileVersionAttribute to all standard library assemblies.

  • #494: Add support for pointing resources to a CDN (see above).

  • #495: Add proxies for {Int32,Double,DateTime}.{MinValue,MaxValue}.

  • #496: Add proxy for String.IsNullOrWhiteSpace.

Happy coding!

By Loïc Denuzière on Thursday, November 12, 2015 — 0 comments

WebSharper 3.5.16 releasedCore team

We are happy to announce the release of WebSharper 3.5.16 available through the usual channels. Here is the change log:


The unit testing framework WebSharper.Testing has been split into a separate NuGet package.

This fixes the issue where QUnit was included as a script in Single-Page Applications even when it wasn't actually used.


  • #486: Reference the correct version of FSharp.Core in the MSBuild task. This fixes issues such as Json.Serialize failing to compile when running MSBuild from the command line.

  • #489: Null argument exception when building on mono.


  • #17: Add try...with, try...finally and return! to the View.Do computation expression.

  • #19: Add View.Sequence : seq<View<'T>> -> View<seq<'T>>.

  • #55: In the templating type provider, translate <[CDATA[...]]> blocks to Doc.Verbatim.

  • #56: Don't delete some text nodes when updating the view.

  • #57: Fix genericity error on the <~ update operator in Notation.

Happy coding!

By Adam Granicz on Wednesday, November 4, 2015 — 0 comments

Data-aware workbooks and client-side data access with WebSharper.DataCore team

F# has always excelled at accessing heterogeneous data sources in server-side code through its unique type provider feature: a metaprogramming technique that enables generating (or "providing") domain-specific code to be consumed during compilation, such as generating typed schemas for relational databases, CSV and other data files, or bindings for web services and integration with other languages such as R. Type providers are given an optional set of arguments in your code using custom F# syntax, yielding a type space in return.

For instance, FSharp.Data provides access to various forms of structured data (XML, CSV, etc.) and the WorldBank database via its web API. You can now access some of this data, from client-side code in your WebSharper applications with WebSharper.Data.


WebSharper.Data provides various proxies for FSharp.Data, currently supporting the JsonProvider and the WorldBankProvider runtimes in client-side use with WebSharper.

Below is a snippet that uses WebSharper.Data and WebSharper.Charting to provide a workbook with data obtained from the WorldBank database.

A wide array of other data-aware scenarios are possible, below is another simple snippet that works out of the GitHub issue database and displays a list of open tickets for the WebSharper repository.

Happy coding!

By András Jankó on Friday, October 30, 2015 — 0 comments

WebSharper 3.5.14 releasedCore team

This is a small bufgix release for SPA projects. Change log:


  • The bundle command (a.k.a Single-Page Application) now extracts non-JS, non-CSS WebResources into /Content.
  • #483: Cleaning a bundle project does not fail if output folder does not exists.

Happy coding!

By Loïc Denuzière on Wednesday, October 28, 2015 — 0 comments

WebSharper 3.5.13 releasedCore team

We are happy to announce the release of WebSharper 3.5.13, with minor features and bug fixes. Here is the full change log:

Visual Studio Extension

  • #2: Add supported product: Visual Studio 2015 Enterprise Edition.


  • The bundle command (a.k.a Single-Page Application) now extracts non-JS, non-CSS WebResources into /Content.

  • #482: Fix the serialization of None and other values represented as null in .NET when passed to inline controls (ClientSide <@ ... @> in WebSharper.Html, client <@ ... @> in UI.Next).

  • Don't fail silently when failing to initialize a Sitelet from a [<Website>]-annotated static property.


  • Doc is now an abstract class, rather than an interface.

  • Most extension methods have been changed to C#-style extension methods.

  • Add Doc.Async : Async<#Doc> -> Doc.

  • #52: Fix over-eager loading of assemblies in the templating type provider, which could cause conflicts due to file locking.


  • Add Doc.ShowErrors : View<Result<'T>> -> (list<ErrorMessage> -> Doc) -> Doc, also as an extension method on View<Result<'T>>.

  • Add Doc.ShowSuccess : View<Result<'T>> -> ('T -> Doc) -> Doc, also as an extension method on View<Result<'T>>.

Happy coding!

By Loïc Denuzière on Wednesday, October 21, 2015 — 0 comments

WebSharper 3.5.9 releasedCore team

We just released version 3.5.9 of the WebSharper stack. This is mostly a bugfix release, with a few shorthands added to the UI.Next API.

Change log


  • #477: Fix translation to JavaScript of mutable variables used from a closure (F# 4.0 feature).

  • #478: Fix encoding of web controls by the ASP.NET ScriptManager.

  • #479: Fix currying of local functions in some edge cases.

  • #480: Fix division involving large negative integers.

  • #481: Include "Z" UTC indicator in server-side System.DateTime JSON serialization.

  • Ignore final slash in table-based Sitelets routing, thus fixing WebSharper.Suave #1.


  • #1: Restore Html.Server.Web.Control and fix the JSON encoding of any client-side controls it contains.


  • #43: Use keypress instead of keyup for IE8-compatible input detection in the Attr.Value and Doc.Input families of functions. This makes it possible to use on.keyup for other purposes, such as catching Enter to submit the input.

  • Add Submitter.CreateOption : View<'T> -> Submitter<option<'T>>. This creates a Submitter with initial value None, that maps the input view through Some when triggered.

  • Rename the View.Convert and Doc.Convert families of functions as follows:

    View.Convert      -> View.MapSeqCached
    View.ConvertBy    -> View.MapSeqCachedBy
    View.ConvertSeq   -> View.MapSeqCachedView
    View.ConvertSeqBy -> View.MapSeqCachedViewBy
     Doc.Convert      -> Doc.BindSeqCached
     Doc.ConvertBy    -> Doc.BindSeqCachedBy
     Doc.ConvertSeq   -> Doc.BindSeqCachedView
     Doc.ConvertSeqBy -> Doc.BindSeqCachedViewBy

    The old versions still exist for backward-compatibility, but are marked obsolete.

  • Add extension method equivalents on View<'T> for all of the above. They are overloaded: all variants of View.MapSeqCached have an equivalent v.MapSeqCached(), and all variants of Doc.BindSeqCached have an equivalent v.DocSeqCached().
    Additionally, Doc.BindView has an equivalent v.Doc().

Project Templates

The UI.Next project templates in the Visual Studio extension and the Xamarin Studio addin have been updated:

  • The SPA project uses People.View.DocSeqCached() instead of ListModel.View People |> Doc.Convert.

  • The Client-Server projects now use a reactive style for the small client-side code sample, instead of the previous imperative style.

Happy coding!

By Adam Granicz on Wednesday, October 7, 2015 — 0 comments

Announcing WebSharper 3.5 with pluggable HTML supportCore team

We are happy to announce the availability of WebSharper 3.5, bringing a couple important changes and numerous bug fixes.

Most notably, this release brings alternate HTML implementations to your WebSharper applications, and while there are only two at the moment, new flavors and variations (both in syntax and capabilities), and integrations with third-party markup engines are coming your way soon.

Swappable HTML language support

WebSharper always shipped with standard HTML support in Html.Client and Html.Server for constructing client/server markup. In an effort to bring additional markup functionality and new markup alternatives for your applications, WebSharper 3.5 introduces a less tighly coupled setup and leaves the actual markup implementations to be chosen freely.

This means that WebSharper 3.5+ applications will reference their actual choice(s) of HTML implementations (won't be auto-referenced via WebSharper any longer), and these in turn can evolve separately from the main WebSharper toolset, giving a way to incorporate novel ideas and new capabilities in constructing markup.

Reactive applications with UI.Next

Going forward, you are encouraged to try the reactive HTML implementation shipped with WebSharper.UI.Next. UI.Next also brings enhanced templating capabilities beyond those in the standard Html.Server templates, giving you type-safe, reactive HTML templates that are stunningly easy to work with. You can read about UI.Next here, while the documentation for UI.Next templating will be added shortly.

You can also find a number of UI.Next-based project templates shipped in the main VSIX installer and the MonoDevelop/Xamarin Studio integration, to help you get started with developing reactive WebSharper applications.

Standard HTML support now available as a separate Nuget

The previous HTML support (Html.Client and Html.Server) has moved to a separate repository and Nuget package called WebSharper.Html, so to continue using this implementation you will need to reference WebSharper.Html in your 3.5+ applications.

WebSharper + Suave template

Next to the recent WebSharper.Suave announcement, WebSharper 3.5 now also ships a new project template for Visual Studio, MonoDevelop, and Xamarin Studio for running WebSharper applications on Suave. This template implements the standard client-server WebSharper "sample" application, and is easy to modify to fit your needs for any full-stack F# web application running on Suave.

Full change log

The list of other changes and bug fixes to WebSharper and components since the previous release are the following:


  • #476: Add proxies for static members FSharpOption.Some and FSharpOption.None
  • #474: Add ability to set content type directly in Content.File


  • #45: Rename Content.Doc to Content.Page
  • #46: Restore Attr.ClassDynPred
  • #47: Add Doc.RunAppend, RunPrepend
  • #48: Templating: add .Elt() when template is a single element
  • #49: Templating: pure-whitespace nodes are ignored

The released bits on are Nuget for you to try - and your feedback is welcome. The easiest way to get in touch is joining the WebSharper chat room on Gitter. See you there!

Happy coding!