A number of these new functions are equivalent to functions that were in WebSharper.Warp, which are now marked as obsolete.

New HTML language for UI.Next

We completely redesigned the HTML embedded language for WebSharper UI.Next. We will post another blog entry soon to fully describe the new design, but here are the main take-aways:

Element and attribute combinators are now lowercase, for a hopefully more natural-looking syntax.

The type Doc can be used for both client-side and server-side markup. Some features are only available on one side, such as UI.Next reactive elements for the client and conversion to a Content<_> for the server. To use these features, you need to open WebSharper.UI.Next.Client or WebSharper.UI.Next.Server, respectively.A template for client-server UI.Next applications has also been added to the Visual Studio and Xamarin Studio extensions.

Our goal for WebSharper 4.0 is to obsolete the current Html.Client and Html.Server, and to merge WebSharper.UI.Next into WebSharper under a new name. Doc will be the unique way to deal with HTML content, both on the client and the server side.

F# 4.0 proxies

WebSharper 3.4 provides JavaScript proxies for the functions that were added to the standard library in F# 4.0. You can now call functions such as Seq.mapFold and Array.last from the client-side.

Cross-site features for RPC functions

WebSharper 3.4 integrates several features related to cross-site requests to RPC functions:

Protection against Cross-Site Request Forgery using a cookie-to-header token. This protection is active by default and completely automatic.If you need to deactivate it, in particular to be able to call RPC functions from a PhoneGap mobile application, you can simply call DisableCsrfProtection() from module WebSharper.Web.Remoting at the top-level on the server side.

Management of allowed CORS origins. In module WebSharper.Web.Remoting, the functions AddAllowedOrigin and associated can be called at the top-level on the server side to add CORS origins accepted by the RPC handler. In particular, PhoneGap applications need to add file:// as an allowed origin.

We are happy to announce the availability of WebSharper 3.3, which you can download here. The main highlight of this release is the addition of JSON serialization functions for client-side code.

The format used for this serialization is identical to the format used by inferred Sitelets. This means that you can now easily craft your request data on the client, perform an AJAX call to your Sitelets API, and parse the reply, all of this type-safely!

This new API is located in the module WebSharper.Json. Its only limitation compared with Sitelets is that the [<DateTimeFormat>] attribute is currently ignored, as JavaScript doesn't have built-in datetime formatting capabilities. We might consider using an external library such as moment.js for this purpose in the future.

Future plans

We have lots of exciting things to come in WebSharper. Here is what you can expect from upcoming releases:

A new, cleaner HTML combinator syntax. This syntax will supersede the current Html.Server, Html.Client and UI.Next.HTML with a unique type. This means that the same HTML code will be usable both from the server and client side.

Previously using interfaces generated invalid IL, implementations were missing.
Also interface methods had no Inline attributes for WebSharper translation.

Now an interface is auto-implemented on the class.
Inlines are copied from the interface declaration, no customization is possible currently.
If there are multiple interfaces defining the same method, the inline found on the first interface definition will be used.

WebSharper Warp is a friction-less web development library for building scripted and standalone full-stack F# client-server applications. Warp is built on top of WebSharper and is designed to help you become more productive and benefit from the rich WebSharper features more quickly and more directly. While Warp shorthands target the most typical applications (text, SPAs, multi-page) and easy exploration, you can extend your Warp applications with the full WebSharper capabilities at any time.

Installing

To get started with Warp is super-easy, all you need is to open a new F# Console Application (or any other F# project type if you want to script applications), and add WebSharper.Warp to it:

Single Page Applications

While serving text is fun and often useful, going beyond isn't any complicated. Warp also helps constructing HTML. In the most basic form, you can create single page applications (SPAs) using Warp.CreateSPA and WebSharper's server-side HTML combinators:

Multi-page applications

Using multiple EndPoints and Warp.CreateApplication, you can define multi-page Warp applications. When constructing the actual pages, Warp.Page comes handy - allowing you to fill the Title, Head, and the Body parts on demand. Warp.Page pages are fully autonomous and will automatically contain the dependencies of any client-side code used on the page.

Adding client-side functionality

Warp applications can easily incorporate client-side content and functionality, giving an absolute edge over any web development library. The example below is reimplemented from Deploying WebSharper apps to Azure via GitHub, and although it omits the more advanced templating in that approach (which is straightforward to add to this implementation), it greatly simplifies constructing and running the application.

We are thrilled to announce the availability of WebSharper 3.2, paving the road to further upcoming enhancements to streamline developing and deploying WebSharper apps, and also shipping several key changes summarized here.

Dot-syntax for chained event handlers

This syntax is more familiar to many developers, eliminates the need for a special operator (|>!), and makes code more discoverable by having API comments and code completion choices available when attaching the event handler.

Server-side templating enhancements

Traditionally, in sitelet templates you had the following line in the <HEAD> section to stand for the placeholder for including generated page dependencies (e.g. all the CSS, JS, etc. files that are implicitly referenced in your page):

1

<meta name="generator" content="websharper" data-replace="scripts" />

With 3.2, you can now refine how these dependencies are inserted if you provide additional placeholders:

styles: output the generated stylesheets only. Usually, you will want to put this placeholder in the <HEAD> section.

meta: output the client-server integration (arguments to server-side controls, etc.) bits only. You will want this in <HEAD>

When either of these are present, scripts only outputs the JavaScript dependencies, making it possible to place this placeholder anywhere else, away from the other bits, say, to the tail of the <BODY> element.

It's barely been a month since we released WebSharper 3.0, and we are now at it again with the release of WebSharper 3.1. Without further ado, here are the main highlights.

ASP.NET MVC support

WebSharper has supported including client-side controls in ASPX pages since version 1.0, and running sitelets alongside ASP.NET since version 2.0. With version 3.1 and WebSharper.AspNetMvc, WebSharper now has extended support for running together with ASP.NET MVC in the following scenarios:

Including WebSharper client-side controls in pages that use the Razor view engine. Here is an example:

Lightweight syntax to embed client-side elements in sitelets markup

Until now, in order to include client-side generated markup (whether using Html.Client or UI.Next) inside Html.Server markup, you had to create a new class inheriting from Web.Control and override its Body property. There is now a much easier syntax that you can use thanks to the ClientSide function:

Unlike the presence of a quotation suggests, this doesn't run any F#-to-JavaScript compilation at runtime. The quotation is only here to allow looking up the fully qualified name of the function you are calling (Client.myContent in the above example) and inlining it in the resulting page, alongside its JSON-serialized arguments.

Multiple actions with the same prefix

You can now create an action with several cases that parse the same prefix (ie. have the same [<CompiledName>]) on the same method. They will be tried in the order in which they are declared, until one of them matches. This is very convenient for REST-style URLs where additional information can be added with additional URL fragments.

Parsing form post data

Web forms using method="post" send their data in the request body with a format determined by enctype (generally either application/x-www-form-urlencoded or multipart/form-data). This data is available in the sitelet context as Request.Post. It is now also possible to directly parse it in the action using [<FormData>]. This attribute is used in a similar way as [<Query>].

Disposable enumerators

Perviously WebSharper translation didn't dispose enumerator objects used internally in for ... in loops. Also, enumerators created by Seq module functions didn't dispose the wrapped enumerators. These all now follow semantics of their .NET counterparts.

The future

As you can see, we are now committing to a higher turn-around of WebSharper releases. Among enhancements you can expect in the future, we will be adding proxies for the new library functions as soon as F# 4.0 hits the shelves.

We are also preparing a service to try WebSharper F#-to-JavaScript compilation online. You will be able to experiment with F#-based web applications quicker and more easily than ever!

We cannot wait to make this available for you to try. In the meantime, happy coding!

More and more .NET developers come to appreciate functional programming, and this is really good news for F#. A couple weeks ago Scott Hanselman ran a short article on running Suave.io apps as Azure web apps deployed via GitHub. His setup was the following:

You configure your Azure web app to be sourced from a GitHub repository. This sets up a GitHub hook that notifies Azure on every commit.

On a commit, Azure executes a deployment script (deploy.cmd via .deployment) found in your project.

This script uses Paket to restore FAKE and Suave, and uses FAKE to execute an F# script (build.fsx) by passing it to fsi.exe shipped with FAKE.

This FAKE script can optionally execute various build tasks, if necessary, to build a site - in Scott's example it was just used as a placeholder script.

Finally, the web app is copied to the right folder in your Azure web app.

When starting, the app executes a "setup" step, configured as an <httpPlatform> directive. This in turn uses FAKE to execute site\webserver.fsx, which starts Suave.io and listens on a given port that is then mapped to the standard HTTP port.

This sequence is more complicated than it needs to be because it has to work around the lack of the F# tools and core libraries when setting up a new Azure web app deployment. Since Scott's article, I filed a ticket to bundle the F# compiler and tools in a Nuget, and thanks to Don Syme and Steffen Forkmann, that Nuget was out within a couple days.

Armed with that, we quickly put together a similar deployment setup for WebSharper client-server apps (other types of WebSharper apps are equally possible.) This has the obvious advantage that:

It uses WebSharper, so you can add client-side (e.g. JavaScript) functionality as well and write it in F#.

It produces an ASP.NET app that serves fine in Azure without the need to run a separate server process like Suave.io (although you can also create OWIN-based self-hosted WebSharper applications and run them as in Scott's scenario.)

We are often asked what the deployment story is like for WebSharper applications. Our usual reply has long been that WebSharper applications follow standard formats, in particular:

Client-Server Web Applications are simply ASP.NET applications, and can be deployed using usual methods such as publishing from Visual Studio or using Azure's git integration;

HTML Applications are composed of static files located in $(WebSharperHtmlDirectory) (which is bin/html by default) and can be deployed from there using the method of your choice.

Single-Page Applications are also composed of static files, index.html and the Content folder, so the same methods apply.

However there can be some caveats, in particular with regards to running the F# compiler and referencing FSharp.Core.dll in build-and-deploy environments.

Fortunately, the recently released NuGet package FSharp.Compiler.Tools combined with the excellent package manager Paket now provide a nice and streamlined development and deployment experience for git-hosted, Azure-deployed applications.

This article presents the build and deployment setup for a reimplementation of the popular game 2048, available on GitHub. To try it out, simply click the button "Deploy to Azure" and follow the instructions.

The project

This particular project was created as a Single-Page Application; this project type was chosen because the application runs on a single page and is only composed of client-side code. The solution, 2048.sln, contains a single project located at Game2048/Game2048.fsproj.

If you want to recreate this setup, you can create a Single-Page Application from Visual Studio or Xamarin Studio / MonoDevelop with the WebSharper extension installed. This deployment setup will also work if you create a Client-Server Application or an HTML Application instead. For Self-Hosted Client-Server Applications, you will additionally need to set up an HttpPlatformHandler to run the generated executable, similarly to Scott Hanselman's Suave setup.

Paket

Note that paket restore is run in the build script before running MSBuild. Indeed, since we will be importing several .targets files that come from packages, the packages must be restored before running MSBuild or opening the project in an IDE. So for your first build after cloning the 2048 project, you can either run the full build.cmd, or if you only want to restore the packages, you can run:

1

.paket/paket.bootstrapper.exe && .paket/paket.exe restore

If you want to reproduce this setup for your own project as created in the previous section, here are the steps:

Remove the WebSharper NuGet package from the project and delete the file <your_project_name>/packages.config if it exists.

Download paket.bootstrapper.exe and paket.targets from here into the folder .paket.

To ensure that you build with the right package versions after a git pull, add the following to <your_project_name>.fsproj:

The files paket.dependencies, paket.lock and <your_project_name>/paket.references must be committed.

The F# Compiler

Since fsc is not available on Azure, we retrieve it from NuGet. We reference the package FSharp.Compiler.Tools which contains the compiler toolchain. By importing tools/Microsoft.FSharp.targets from this package in our project file, we instruct MSBuild to use the F# compiler from the package. This means that even when building locally, fsc from the package will be used. This ensures consistency between local and deployment builds.

If you want to apply this change to your own project, here are the steps:

Install the F# compiler package:

1

.paket/paket.exe add nuget FSharp.Compiler.Tools

Use it in your project: in <your_project_name>.fsproj:

Remove any references to Microsoft.FSharp.targets and FSharp.Core.dll. In a Visual Studio-created project, this means removing this whole block:

Build: Azure conveniently points the environment variable MSBUILD_PATH to the path to MSBuild.exe; in order to be also able to run this script locally, we check for it and set it to the standard installation location if it doesn't exist. Then, we run it.

Deploy: Deploying the application simply consists in copying the application files to the Azure-provided DEPLOYMENT_TARGET folder. The actual file in the 2048 repository is a bit more complex than necessary for Azure because it is also used on AppVeyor to deploy the application to github-pages. But a simple implementation can just copy all files and subdirectories from the project directory to DEPLOYMENT_TARGET:

And there you have it! A WebSharper application easily deployed to Azure with a simple configuration and consistent build setup between local and deployed.

Note that this particular example is a Single-Page Application, but the same setup can be used for Client-Server Applications and HTML Applications. For the latter, make sure to copy the WebSharperHtmlDirectory (<your_project_name>/bin/html by default) in the final step rather than the project folder itself.

Thanks to Steffen Forkmann and Don Syme for their quick response on creating the FSharp.Compiler.Tools NuGet package, and to Scott Hanselman for his Suave Azure deployment tutorial which has been of great help to create this one despite the fairly different final setup.