Bootsharp: calling C# from TypeScript in a web app

The problem: a C# backend behind a TypeScript frontend

Bootsharp is described as a tool for using C# in web apps with comfort, and its one line summary is that it streamlines the integration of .NET C# apps and libraries into web projects. The situation it targets is specific: the domain, meaning the backend, is authored in .NET C#, while the user interface is a standalone TypeScript or JavaScript project.

The README puts the design in a lineage. It compares itself to Embind for C++ and to wasm-bindgen for Rust, and both of those are the established tools for exposing a native language to JavaScript through WebAssembly. So the category is clear: Bootsharp is a binding generator for the .NET and WebAssembly combination, and it is trying to be the one that does not require you to hand write the interop surface.

What the tool produces is a modern ES package with modules and types, and the bindings it generates sit over abstract C# API surfaces. That last phrase is the design decision worth pausing on. Rather than exposing every C# type to the JavaScript side, you describe an abstract API in C# and let the generator produce the bindings over it. The result is a smaller, more intentional surface area, and a JavaScript API that reads like an interface you designed rather than a mirror of your object graph.

The interop is high level, and the feature list claims it handles any type on the interop surface. The generated API patterns are customizable, which is the escape hatch for when the default shape does not fit your TypeScript conventions.

The audience is a team with a C# codebase they want to keep and a frontend team that wants to work in the JavaScript ecosystem with industry standard tooling and frameworks, React and Svelte named in the README. The project is then published to the web or bundled as a native desktop or mobile application with Electron or Tauri.

Where the compiled output goes

The build path is the part of the system with real engineering weight, and the README describes it in one line: Bootsharp compiles optimized WASM with NativeAOT-LLVM and Binaryen.

NativeAOT is the .NET native ahead-of-time compiler, and pointing it at LLVM means the C# code is compiled to native code and then to WebAssembly rather than being interpreted in a .NET runtime inside the browser. That is a significant departure from how .NET normally runs on the web, where the usual approach ships the runtime itself and the managed assemblies alongside it.

Binaryen is then the optimization and transformation stage, which is the standard tool in the WebAssembly toolchain for shrinking and tuning a module. So the pipeline is a native compile followed by a WebAssembly optimization pass, and the result is a module rather than a runtime plus bytecode.

That has an obvious consequence for page weight, and it is the question a team should ask first. A full .NET runtime in the browser is a large download, and the reason to use a native ahead-of-time compile is precisely to avoid paying for the runtime. But the module is still generated from your whole application surface, and the README does not document how the output is split or trimmed per page.

The samples directory hints that trimming is a supported concern rather than an afterthought. There are five samples: bench, minimal, react, trimming and vscode. A sample named trimming exists precisely because the whole-program compile is the default and a smaller surface is a goal. The bench sample presumably exists to measure, and the minimal one is the smallest possible project to check the toolchain end to end.

The vscode sample suggests the development loop is part of the design rather than an afterthought either. A WebAssembly interop tool is much easier to use if there is a way to run it inside an editor with the C# and TypeScript sides side by side.

The generated package and the abstract API surface

The unit of delivery is a package that behaves like any other modern JavaScript dependency. The output is a modern ES package with modules and types, and the feature list says the bindings work in browsers and in JavaScript runtimes, with Node, Deno and Bun named.

That last point is worth dwelling on, because it is a bigger claim than it first looks. A tool that only worked in a browser would force you to stub things out for server-side rendering, for tests running in Node, and for a build pipeline that touches the module. Saying the bindings work in Node, Deno and Bun means the same generated package can be imported by a React server component, by a unit test, and by a desktop shell, which is what makes a shared C# domain layer practical in a modern frontend stack.

The generation model is what keeps the surface small. You define an abstract API in C#, and the generator produces bindings over it, intelligently handling any type that appears on that surface. The word intelligent in the feature list is doing some work, since the alternative is a type mapping table you have to maintain.

The customization point matters just as much. Allowing the emitted interop API patterns to be customized means the default output does not have to be the output you ship. If the generator names methods in a way that does not match your frontend conventions, or exposes a shape that does not fit your state management, you can change the pattern rather than wrapping everything by hand on the TypeScript side.

That combination, an abstract C# surface plus customizable generated patterns, is the actual contribution. A raw C# to JavaScript binding would be usable and unpleasant. An abstract surface with a customisable pattern is something you could design an API around.

Getting started, and what the documentation has to carry

The README is a summary, and it says so. The get started section points to a guide at bootsharp.com/guide, and that is where the actual workflow lives, including the install step, which the README itself does not spell out.

The published package is on NuGet as Bootsharp, and the project home is bootsharp.com. The repository carries a docs directory that holds the documentation site, with the assets referenced from the README living under docs/public, and a samples directory with the five projects named earlier. There is no application code at the top level beyond src, and no test or build configuration files listed, which suggests the samples carry their own per-project setup and the repository is arranged as a tool plus a set of examples rather than a single buildable solution.

The presence of a CodeQL workflow badge and a codecov badge in the README says the project treats supply chain scanning and coverage as part of its process, which is a reasonable signal for a tool that generates code you then commit to a repository and run in production.

The one production reference in the README is a good sign for a different reason. Bootsharp is used in Naninovel, a visual novel, dialogue and cutscene storytelling engine, which is a real commercial application with real users, and a cutscene engine is an unusually demanding case for this kind of tool because it is largely synchronous calls in a tight loop.

If you are evaluating it, the samples are the fastest route. The minimal sample tells you the smallest thing that works, react shows the intended frontend shape, trimming shows how to reduce the compiled surface, and bench is there to tell you what the compilation costs.

The limits, and the honest comparison

The biggest structural limit is that everything crosses the WebAssembly boundary, and that boundary has rules. A call into C# from JavaScript is not free, and the generated bindings carry a marshalling cost for every argument and return value. For a domain layer that does real work, the call overhead is irrelevant. For a UI that calls the backend on every keystroke, it is not.

The second limit is the shape of the application. A native ahead-of-time compile of a .NET application produces a module of the whole program, and the surface you expose is the surface you designed. If your C# side relies on reflection, dynamic loading, configuration binding or plug-in discovery at runtime, a native compile is a poor fit, because those features depend on a runtime that is not there.

The third is the debug and profile story. The vscode sample tells you that editing in an editor with the C# and TypeScript together is a supported path, but the README does not describe stepping into the C# from the browser, or how you inspect managed state in a WebAssembly debugger. For a project where a defect is hard to reproduce, that is a real cost.

The comparison with the alternatives is instructive. A normal ASP.NET application with a JSON API keeps the C# where it belongs and lets the frontend talk HTTP, which costs a network hop and a serialization step but gives you the whole .NET debugging experience, hot reload and all. A different WebAssembly approach, compiling the C# with the standard .NET WebAssembly tooling, keeps the runtime in the browser and therefore carries a much larger download, but you keep reflection and the rest of the framework. And writing the boundary in JavaScript, with the C# called through a thin host, is the approach with the least machinery and the least benefit from a tool like this one.

Bootsharp is for the case where the C# is substantial and the frontend is substantial, and neither side can be given up. If only one of those is true, a simpler arrangement wins.

Editorial conclusion

Adopt Bootsharp if your domain logic belongs in C# but your UI is React, Svelte or plain TypeScript, and you can accept a WebAssembly compilation step in your build. Do not adopt it for a pure .NET application, since a normal ASP.NET application already solves that, and skip it if you need synchronous calls that block the browser event loop. Verify first that the abstract C# API surface you want to expose has no types the generator cannot marshal, that the interop API pattern matches what your frontend expects, and that the Wasm bundle size is acceptable for the pages that load it.

Frequently asked questions

Official sources

1. elringus/bootsharp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases