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!

By István Gansperger on Tuesday, October 6, 2015 — 0 comments

Try Websharper: version info about extensions and some embedding improvementsCommunity

Try WebSharper has been updated with some minor improvements regarding version info and embedding snippets.

  1. There is now an About button which shows a dialog with all the relevant version info of the extensions and a version number for Try WebSharper itself. We are going to do our best to keep all the extensions up-to-date.

  2. It is now possible to point at a given tab of an embedded snippet instead of showing the Result one by default. You can do it by specifying the tab in the URL by a hash:

    • #f-sharp: F# editor
    • #html: HTML editor
    • #result: Result tab

Happy coding!

By Loïc Denuzière on Thursday, October 1, 2015 — 1 comment

Announcing WebSharper.SuaveCore team

We are happy to announce the release of WebSharper.Suave, an adapter to run WebSharper applications on Suave.

With WebSharper.Suave, creating a Suave WebPart from a WebSharper Sitelet is as simple as a single function call.

module Main

open WebSharper
open WebSharper.UI.Next.Html

module Client =
    open WebSharper.JavaScript
    open WebSharper.UI.Next.Client
    open WebSharper.Charting

    let RadarChart () =
        let labels =    
            [| "Eating"; "Drinking"; "Sleeping";
               "Designing"; "Coding"; "Cycling"; "Running" |]
        let data1 = [|28.0; 48.0; 40.0; 19.0; 96.0; 27.0; 100.0|]
        let data2 = [|65.0; 59.0; 90.0; 81.0; 56.0; 55.0; 40.0|]

        let ch =
            Chart.Combine [
                Chart.Radar( labels data1)
                    .WithFillColor(Color.Rgba(151, 187, 205, 0.2))
                    .WithStrokeColor(Color.Rgba(151, 187, 205, 1.))
                    .WithPointColor(Color.Rgba(151, 187, 205, 1.))

                Chart.Radar( labels data2)
                    .WithFillColor(Color.Rgba(220, 220, 220, 0.2))
                    .WithStrokeColor(Color.Rgba(220, 220, 220, 1.))
                    .WithPointColor(Color.Rgba(220, 220, 220, 1.))
        Renderers.ChartJs.Render(ch, Size = Size(400, 400))

open WebSharper.Sitelets
open WebSharper.UI.Next.Server

let MySite =
    Application.SinglePage (fun ctx ->
            Body = [
                h1 [text "Charting on Suave is easy with WebSharper!"]
                div [client <@ Client.RadarChart() @>]

open Suave.Web
open WebSharper.Suave

startWebServer defaultConfig (WebSharperAdapter.ToWebPart MySite)

This opens up awesome ways to combine Suave and WebSharper applications, and we are excited about the synergies this will bring to the F# web programming community.

Happy coding!

By Loïc Denuzière on Thursday, September 24, 2015 — 0 comments

WebSharper 3.4.19 releasedCore team

We are happy to announce the release of version 3.4.19 of the WebSharper stack, which you can download here. This release is mainly dedicated to bug fixes and minor features.

Xamarin Studio / MonoDevelop addin on the main channel

The WebSharper addin is now available on the main Xamarin Studio channel. This means that you can now drop the custom repository, and grab WebSharper directly from Xamarin instead! Simply check the "Web Development" category in the addin manager's gallery.

UI.Next Checked number inputs

The main new feature (and breaking change) is in UI.Next. The functions Doc.IntInput and Doc.FloatInput, which associate a Var<int> or Var<float> to a <input type="number"> element, took little care to check the correctness of the actual text entered by the user. This could result in awkward and even browser-inconsistent user experience, where mistakenly entering "1e" would return 1 on some browsers and 0 on others.

These combinators have therefore been modified to perform more input checking and bind the value to a Var<CheckedInput<_>>, with the following definition:

type CheckedInput<'T> =
    | Valid of value: 'T * inputText: string
    | Invalid of inputText: string
    | Blank of inputText: string

This way, typing "1e" consistently sets the Var to Invalid "1e".

The old behavior can still be achieved using Doc.IntInputUnchecked and Doc.FloatInputUnchecked, but is not advised.

Full change log

Here are the minor changes and bug fixes to WebSharper and components since the previous release.


  • #402: Fix exception when compiling a WebSharper project that references a Roslyn-compiled assembly.

  • #467: Add JS.RequestAnimationFrame and JS.CancelAnimationFrame, with a shim for IE9-.

  • #470: Fix the printf family of functions for union cases with [<Constant>] attributes.

  • #471: Fix exception on mono when looking for a [<Website>] if a dependent assembly is missing.

  • #473: Add server-side JSON serialization of the unit type.

  • Add missing proxy for jQuery.parseHTML.


  • #31: Add Doc.Verbatim to create a Doc from verbatim HTML. Be careful not to use it with user input data!

  • #33: camelCase on Expr-based events (eg. on.keyUp instead of on.keyup).

  • #34: make IntInput and FloatInput checked (see above).

  • #36: Add attr.``data-`` combinator to WebSharper.UI.Next.Html to create data-foo="value"-type attributes.

  • #37: Add Doc.SelectOptional, which adds a first selectable option that sets the Var to None.

  • #38: Add Doc.SelectDyn and Doc.SelectDynOptional, for which the list of available options comes dynamically from a View.

  • #39: Add View.MapCached, which is identical to View.Map except that it doesn't call the mapping function again if the input value is equal to the previous input. Useful if the mapping function is computationally expensive. Note that the output is still marked obsolete, it is simply re-filled with the same cached value.

  • #40: Add Doc.WebControl, which allows including a WebSharper.Web.Control inside a server-side Doc.

  • #41: Add .With() method overloads for WebSharper.Sitelets.Content.Template that take Docs as holes.

  • #42: Add instance member versions of Doc.Run, Doc.RunById and Doc.AsPagelet.


  • Release on the main Xamarin channel (see above).

  • #3 on websharper.templates: duplicate .fsproj file when creating a project whose name isn't also a valid identifier.

Happy coding!

By István Gansperger on Friday, September 18, 2015 — 0 comments

Try WebSharper: on-hover type infoCommunity

Try WebSharper has just been updated with some enticing features to help you write code even more easily!

  1. We have added on-hover tooltips to complement our already extensive editor support. Now, alongside autocomplete and on the fly typechecking, you also have the ability to check the types of your expressions when you hover over them.

  2. Most of our private and premium extensions have been added to the list of references you can choose from. This way you can try out most WebSharper extensions on Try WebSharper without subscribing! To complement this, we have changed the list a bit as the number of libraries got quite high and it started to get unreadable so we split the list into three columns and added a filter for quickly searching among them.

  3. In addition to adding a lot of new extensions we have updated all of them to the latest versions, which mostly means bugfixes.

Happy sharing!

By Loïc Denuzière on Tuesday, September 8, 2015 — 0 comments

WebSharper.UI.Next 3.4.19 with OnAfterRenderCore team

We just released WebSharper.UI.Next version 3.4.19 to NuGet. This minor release includes a functionality that is widely used with Html.Client and is now also available in UI.Next: OnAfterRender.

This handler allows you to register a callback to be called right after an element has been inserted into the DOM. This is very useful to run functionality from libraries that require an element to be rendered. For example, Google Maps require the container element to have its dimensions already computed. It is easy to create a map using the afterRender handler:

open WebSharper.UI.Next
open WebSharper.UI.Next.Html
open WebSharper.UI.Next.Client
open WebSharper.Google.Maps

let MyMap () =
    divAttr [ "width: 500px; height: 500px;"
        on.afterRender (fun div ->
            let options =
                    Center = LatLng(47.4968222, 19.0548256),
                    Zoom = 12)
            let m = Map(div, options)
    ] [text "Loading Google Maps..."]

Rendered page.

Like all event handlers, afterRender is available both as an attribute on.afterRender and as a method Elt.OnAfterRender.

This is one more step accomplished towards our ultimate goal to completely replace Html.Client with UI.Next. Happy coding!

By Loïc Denuzière on Wednesday, September 2, 2015 — 0 comments

WebSharper 3.4.14 releasedCore team

We are happy to announce the availability of WebSharper 3.4.14, which you can download here. Here are the main highlights of this release.


Previously, a bug prevented the WebSharper.Owin middleware from running on top of ASP.NET using Microsoft.Owin.Host.SystemWeb. This has now been solved, and the following is now possible:

open global.Owin
open Microsoft.Owin
open WebSharper
open WebSharper.Owin

module Site =
    let Main = Application.SinglePage(fun ctx -> Content.Text "Hello world!")

type Startup() =
    member this.Configuration(app: IAppBuilder) =
        app.UseSitelet(System.Web.HttpRuntime.AppDomainAppPath, Site.Main)
        |> ignore

do ()

For this you need to install the following NuGet packages in your web application: WebSharper, WebSharper.Owin, Microsoft.Owin.Host.SystemWeb and Mono.Cecil.

On the topic of Owin, the Suave team recently pre-released support for running Owin middleware; we will soon publish a blog entry about running WebSharper applications within Suave.

WebSharper UI.Next

A number of new features have also been added to UI.Next.

Data binding: abstract references and lenses

Until now, UI.Next interactive elements such as Doc.Input were only able to interact directly with a Var of primitive type. This was quite limiting in terms of how you could structure your data at the root of the dataflow graph. For example, if you wanted to have a ListModel with a record type for items, and display it with input fields to edit the individual record fields, then those record fields would need to have type Var<'T> themselves.

The new abstract reference type IRef<'T> relieves this restriction. IRef<'T> is an interface type that represents data that can be directly read or written, or observed by a View<'T>. Conceptually, that's exactly what Var<'T> is, and of course Var<'T> implements this interface; but not only. There are now methods on Var<'T> and ListModel<'K, 'T> that return IRef<'U>s where 'U represents a part of the original 'T. This concept is called lensing. For example:

type Person = { FirstName: string; LastName: string; Id: Key }

let me : Var<Person> =
  Var.Create { FirstName = "Loïc"; LastName = "Denuzière"; Id = Key.Fresh() }
let myFirstName : IRef<string> =
  me.Lens (fun p -> p.FirstName) (fun p n -> { p with FirstName = n })
let myFirstNameInput =
  Doc.Input [] myFirstName

In the above code, myFirstName is an IRef<string> that lenses into the FirstName field of me. Retrieving myFirstName's value retrieves the FirstName field of the current value of me, and setting myFirstName performs a record update on the current value of me. It is therefore possible to create an input field that is bound to the FirstName field of me. Note how the type Person is able to be entirely immutable.

Even more useful is lensing into ListModels. See for example the following editable list of people:

let people = ListModel.Create (fun p -> p.Id) []
let firstNameOf : Key -> IRef<string> =
  people.LensInto (fun p -> p.FirstName) (fun p n -> { p with FirstName = n })
let lastNameOf : Key -> IRef<string> =
  people.LensInto (fun p -> p.LastName) (fun p n -> { p with LastName = n })
let displayPeople =
  ul [
    people.View |> Doc.ConvertSeqBy people.Key (fun pid person ->
      li [
        Doc.Input [] (firstNameOf pid)
        Doc.Input [] (lastNameOf pid)

Creating a lensed reference is currently somewhat awkward, since you have to provide both the get and update functions. We are planning on providing a macro that will be able to infer the update function based on the getter function, making lenses more convenient to use.


A simple way to allow the dataflow to react to isolated events is to have a view whose value is taken from an input view, but only gets updated when events occur. This was already possible using View.SnapshotOn, but somewhat more involved than it needed to be. The new type Submitter<'T> simplifies this task:

let rvInput = Var.Create "the input data"
let submit = Submitter.Create rvInput.View "no data submitted yet"
div [
  Doc.Input [] rvInput
  Doc.Button "Submit" [] submit.Trigger
  p [
    text "You entered: "
    textView submit.View

Other UI.Next features

  • Add some instance equivalents to static members: the functions View.Map, View.Bind and ListModel.View are now available as instance members on the corresponding types, allowing slightly shorter code for those who prefer this style.

  • ListModel.Key: both as a static and instance member, retrieves the function that is used by a ListModel to get the key of an item. Typically needed by View.Convert*By or Doc.Convert*By (see the lens example above).

  • Doc.BindView: it is rare, when inserting a dynamic doc using Doc.EmbedView, to have a View<Doc> handy; instead, you generally have a View<'T> that needs to be mapped to a View<Doc>. The new function Doc.BindView : ('T -> Doc) -> View<'T> -> Doc combines these two steps in a single function call.

  • Event handlers that can use a View's current value: it is fairly common to need the current value of a reactive View inside the callback of an event handler. It is now very easy to do so using the function Attr.HandlerView, or methods such as on.clickView.

  • Templating: allow an element to be both a hole and a subtemplate. This is useful for example when the hole is to be filled with a list of items, and the subtemplate describes how these items will be displayed.

  • doc.On* methods for standard events have been added, akin to the on.* attributes. They also exist in server-side friendly version, taking a quotation as argument.

  • on.* attributes have been converted to camelCase; for example, on.animationend is now on.animationEnd.

Bug fixes

  • #464: Fixed the client-side JSON encoding of option<_> union case arguments.

  • #463: Track dependencies from the body of [<Macro>]-annotated functions.

  • Fixed the type of JQuery.Position fields from int to float.

  • UI.Next#28: correctly map from string the value of Doc.IntInput and Doc.FloatInput.

Future plans

As mentioned in previous blog entries, our intention is to merge UI.Next into the main WebSharper distribution and to obsolete Html.Client and Html.Server. We are planning to have this done for version 3.5.

At the same time, we are starting to implement UI.Next-based Formlets and Piglets. Piglets are pretty much usable already, while Formlets are still in a more early phase. In both cases, we are seeing huge gains compared with the IntelliFactory.Reactive-based counterparts in terms of code simplicity and safety. Look forward to being able to use Piglets and Formlets within UI.Next!

Happy coding!

By Adam Granicz on Tuesday, September 1, 2015 — 0 comments

Live F# coding and snippets with dependencies in Try WebSharperCore team

Try WebSharper reached an important milestone today: we just released the first bits of on-the-fly typechecking and code completion, and you can now develop F# web snippets, without any installation, online more easily than ever.

Here is what it looks like:

You don't have to do anything fancy, just start typing and the type checker will guide you, including code completion with Ctrl+Space as you would expect. When you are ready to run your snippet, hit Run and you will see your snippet run in the Result panel.

Snippets with dependencies

You may also notice the little gear icon in the F# source tab, with that, now you can set up dependencies for your snippet. Currently, we support a wide range of WebSharper extensions, with more coming soon:




WebSharper.Charting, WebSharper.ChartJs


WebSharper.D3, WebSharper.Google.Visualization

3D graphics

WebSharper.GlMatrix, WebSharper.O3D

Mobile UIs/apps

WebSharper.SenchaTouch, WebSharper.MaterialUI

WebSharper abstractions

WebSharper.Formlets, WebSharper.Piglets

Reactive development

WebSharper.React, WebSharper.UI.Next

We will add third-party extensions shortly, including a variant of FSharp.Data to enable data-aware snippets that communicate with web services, etc.

Even more enhancements will be coming shortly, until then happy coding!

By Frank Joppe on Friday, August 28, 2015 — 0 comments

FSharpArm - part 2Community

Read the previous article: FSharpArm - part 1 As the previous article was "current-status". Progress brought new insights, and so the following corrections apply:I develop in VS2015 under Windows, so I didn’t need to install Akka.Net on the RPi; installing fsharp for Debian/Ubuntu Linux is enough; The Self-Hosted Websharper template does not work -fully- as was described, see below; Control Panel [...]
>> Read the full article on
By István Gansperger on Wednesday, August 26, 2015 — 0 comments

Try WebSharper: update notes for snippetsCommunity

A new version of Try WebSharper just hit the live site featuring update notes to complement the addition of updates from the last release along with some quality of life changes.

  1. When updating your snippet you can now specify notes regarding that specific update. This is similar to the description field with the intent of only showing what changes were made and why. Later we might compile all the notes from the previous versions and show them all for a given snippet.

    which will show up under the description in the next version:

  2. We now have previous and next links on the embed page as well meaning you can switch between versions in an embedded snippet.

  3. You can use WebSharper.React and WebSharper.MaterialUi in your snippets. The extensions have not been publicly released yet so you can access them only on Try WebSharper!

  4. Extensions have been updated to the latest versions which means bugfixes — most notably UI.Next enhancements — and other improvements!

Happy sharing!