WebSharper: compiling F# and C# web applications to JavaScript

What WebSharper is: a compiler from .NET languages to the browser

WebSharper is described as a web programming platform including compilers from F# and C# code to JavaScript. That single phrase sets the whole shape of the project. It is not a .NET web server that serves HTML and occasionally calls out to JavaScript; it is a compiler that turns .NET source into browser code, with the platform around it providing the runtime pieces a web application needs.

The project is open source under the Apache 2.0 licence and is developed by IntelliFactory, with contributions from the community. That combination matters for anyone assessing the project: the licence is permissive, and the maintenance sits with a company rather than with a rotating set of individual maintainers, which is the arrangement that tends to keep a compiler project alive across a decade.

The repository topics describe the intended scope: functional, reactive, fullstack, microservices, and MVU, along with static-site-generator, which tells you that the same toolchain is meant to serve a range of shapes from a static site to a service with a browser front end. The related repositories list makes the architecture legible, because WebSharper core is the compiler and the platform, while the user interface, the templates and the build helpers live next door.

The project also has a live try environment. The README links live try examples for WebSharper 4x at try.websharper.com, which is the fastest way to see the language surface before installing anything, and it points at current documentation at docs.websharper.com.

Sitelets: the abstraction behind routing and serving pages

The README names sitelets as the main abstraction for routing and serving pages of web applications in WebSharper, and that single concept carries most of the framework's design weight.

A sitelet is a value that can produce a response for a request, and the application wires sitelets into a router at startup. The one line of code shown in the README's hosting setup shows the shape of that wiring, and it is F# rather than C#, which tells you the platform is designed around functional composition rather than an imperative controller class:

app.UseWebSharper(fun ws -> ws.Sitelet(Site.Main) |> ignore)

The lambda receives the WebSharper context and selects a sitelet from it, here the one named Site.Main, and pipes it into the pipeline that serves it. Because sitelets are ordinary values, they compose: a sitelet can be built from smaller sitelets, which is the pattern that makes functional reactive programming and the MVU style work in this setting.

For a team coming from ASP.NET, this is the piece to evaluate before anything else. The routing and serving model is not MVC controllers, and the abstractions you will spend your time learning are sitelets and whatever the UI library exposes on top of them. The documentation page on sitelets is the one to read, since the README defers to it rather than attempting a summary.

First run: the dotnet new templates and a local project

The quick start is four commands, and they are the whole onboarding path:

dotnet new install WebSharper.Templates
dotnet new websharper-web -lang F# -n MyWebSharperApp
cd MyWebSharperApp
dotnet run

The first line installs the template package, the second creates a project named MyWebSharperApp in F#, the third moves into it and the fourth runs it locally. The template itself ships a Startup.fs or Startup.cs file showing the recommended hosting setup, which is the sitelet wiring shown above, so the generated project starts from the shape the framework considers canonical rather than from an empty file you have to invent.

Two things are worth noting about the template approach. First, the templates are a separate repository, WebSharper.Templates, which means the template version is not necessarily tied to the compiler version you have installed, and updating them is a matter of reinstalling the package. Second, for an existing codebase rather than a new one, the README sends you to the Getting Started page in the documentation, which covers the other project types and how to add WebSharper to a project that already exists.

The documentation set is organised separately from the code. The docs live in their own repository under the dotnet-websharper organisation, and the README distinguishes the legacy website at websharper.com from an upcoming site at websharper.io, with docs.websharper.com as the current documentation. Support plans and a contact form are offered through the new site, which tells you the project is being repositioned commercially at the same time as the code is maintained.

The client side: WebSharper.UI, the MVU library and the extension ecosystem

The compiler produces JavaScript, but a compiler alone is not an application framework. The rest of the story is in the sibling repositories.

WebSharper.UI is a library for building reactive user interfaces in WebSharper, and the MVU repository holds a library for building applications in the Model-View-Update architecture style based on WebSharper.UI. Model-View-Update is the pattern where the view is a function of state, and an update is a function of the previous state and an event, which is the shape the repository topics tag as mvu. Putting the two together describes the intended application structure: reactive views built on a value-passing update loop, which is where the functional style pays off and where the compiler's static typing does the most work.

Around that core sits an extension ecosystem. The README says the organisation hosts many more repositories with extensions wrapping popular JavaScript libraries and frameworks, and names WebSharper.React as an example. That is the pragmatic answer to the obvious objection: if your team needs a specific JavaScript library, the pattern is an extension that wraps it, written by someone in the community, rather than a hand-written interop layer in your project.

It is also the main risk in that ecosystem. The wrappers are separate repositories with separate maintainers, and the README describes the pattern as many more repositories rather than a curated set with a single release train. If your application depends on three extensions, you are depending on three projects that version independently of the compiler.

Inside the repository: Paket, MSBuild, FAKE scripts and browser tests

The core repository is laid out like a .NET compiler project that has been through several toolchains. There are four solution files, WebSharper.sln, WebSharper.NoTests.sln, WebSharper.Tools.sln and WebSharper.Compiler.sln, which is the usual way to split a large build into a full one, a fast one and a compiler-only one.

Dependency management goes through Paket, with paket.dependencies and paket.lock committed, and there is a msbuild/ directory for the MSBuild integration that the .NET toolchain expects. The build itself is scripted in F#: build.fsx sits alongside build.cmd, build.sh and rebuild.cmd, so the canonical build entry point is an F# script rather than a hand-written command line. That is a deliberate signal about the project, since it dogfoods the language it compiles.

Testing has two halves, and the second half is the interesting one. Alongside the .NET test projects under tests/ and src/, the repository carries chutzpah.json and runtests.js, and the package.json declares a single devDependency, node-qunit-puppeteer. Chutzpah is a .NET test runner that drives browser-based tests through QUnit, and running it through Puppeteer means the JavaScript that WebSharper generated can be executed in a real browser as part of the .NET test cycle. For a compiler project, that is the correct shape: the output under test is JavaScript, so the tests have to run in JavaScript.

Around that sit the working files of a modern repository: .config/ for dotnet tooling, .github/ for workflows, global.json pinning the .NET SDK, .gitpod.yml for a hosted dev environment, and both .vscode/ and .serena/ for editor and assistant configuration.

Release rhythm and where WebSharper stops being the right tool

The release history shows a steady but unhurried cadence. Version 10.1.5 shipped on 2026-05-22, 10.1.6 on 2026-06-26, and 10.1.7 on 2026-10-18. The last push to the repository was on 2026-10-22 and the project is not archived, so the core is still being worked on. The version numbers themselves carry a build counter, 10.1.7.680, which suggests patch builds are produced from the same minor line rather than being cut and tagged only at feature boundaries.

The first wrong-tool case is a team that wants a specific JavaScript framework. WebSharper's own UI library and the MVU library are the intended path, and the React extension is an example of a wrapper in the organisation rather than a first-class integration. If your roadmap says the frontend will be React, Vue or Svelte, the effort of building that application on WebSharper is larger than the effort of using it, and the honest answer is to pick the framework you already have.

The second wrong case is a team with no appetite for compiler work. A WebSharper project has a.NET build that produces JavaScript, a set of extensions to track, and a sitelet model to learn. If your application is a conventional server-rendered site with a small amount of interactivity, plain ASP.NET or any other.NET web stack is less work.

The third wrong case is JavaScript library coverage. The extension model is community-driven, and the README's phrasing about many more repositories in the organisation is a description of coverage, not a guarantee of it. Before committing, check that extensions exist for the specific libraries your application needs, and pin them, because they version independently of the compiler.

The fourth is the documentation transition itself. The README lists a legacy website, an upcoming website, a current documentation site and a try environment that still runs the 4x examples. During a migration like that, expect some friction finding the current answer to a question, and prefer the documentation repository on GitHub when the site and the code disagree.

Editorial conclusion

WebSharper fits .NET shops that want to write client code in F# or C#, keep their models and services on the server, and ship a single compiled artefact to the browser without a JavaScript build chain. It does not fit teams that want React or Vue components, teams that need a JavaScript ecosystem the extensions do not yet wrap, or projects that cannot carry a compiler in their build. Verify first that the sitelet model in WebSharper matches how you want to structure routes, that WebSharper.UI or the MVU library covers the interaction patterns you need, and that the template project in your .NET SDK version compiles before you commit a codebase to it.

Frequently asked questions

Official sources

1. dotnet-websharper/core on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases