saucer reuses the browser engine your operating system already ships

No bundled renderer, and that is the whole design

Saucer is a modern C++ webview library, and the introduction is plain about the scope, a cross-platform desktop application built with C++ and web technologies, supporting all three major desktop operating systems with several backend implementations. The weight argument is stated first in the feature list, because it is unusual, and it follows from using the operating system's native web renderer, or a commonly used one, which makes binaries as small as around 250KB possible. Compare that with the usual shape of a webview toolkit, where the renderer is compiled in and the application carries a browser with it. The trade is that the rendering, the behaviour and the available features differ per platform, so an application that leans on a web engine quirk has to think about which engine it will run under. The rest of the feature list is oriented the same way, with custom schemes, script injection, favicons, Unicode support, coroutine support, thread safety and support for embedding the front end into the binary.

The backend table is the compatibility matrix

The table of backends is the most useful thing in the README, and it is worth reading as a compatibility statement. Windows has Win32 with WebView2, Linux has GTK4 with WebKitGTK, and macOS has Cocoa with WKWebView, and across all three the Qt with QWebEngine option is available as an alternative. So the library is not a single engine with a compatibility layer, it is several engines, one per platform, behind one interface. The `data-webview` attributes that the feature list mentions for building a custom title bar are the concrete example of what that buys, since a frameless window with a hand drawn title bar is easy when the window is yours and awkward when the title bar belongs to the web view. The other half of the table is the cost, since a feature implemented on one backend and not another is a portability bug waiting to be found.

Interoperability runs through reflection

The interop feature is described as a convenient API, powered by reflection, to evaluate JavaScript code or expose C++ functions to JavaScript, and the example in the readme shows both directions. The C++ side exposes a function named `add_demo` that takes two doubles and returns a task of a double, and inside it the code awaits a JavaScript evaluation of `Math.random()`, so the two sides meet inside one coroutine. The shape of the call is what makes it interesting, since a webview library that only lets you run a script and get a string back is a debugging tool, while one that lets a JavaScript event handler call a C++ function directly is an application framework. The code in the readme is short:

    auto window  = saucer::window::create(app).value();
    auto webview = saucer::smartview::create({.window = window});

    window->set_title("Hello World!");
    window->set_size({.w = 800, .h = 600});

The design is also visible in how the application is started, with the entry point a coroutine that creates the window, creates the web view against it, loads a local page and then awaits the end of the application.

Exceptions and RTTI are things you opt out of

Two entries in the feature list are about what the library does not require. It compiles with `-fno-exceptions`, and it compiles with `-fno-rtti`, and the second of those is the more unusual claim for a C++ library that ships a reflection based interoperability layer, since reflection is usually implemented with RTTI or with a code generator. There is a footnote that qualifies the exception behaviour, that Saucer catches exceptions thrown in exposed functions if it was not compiled with `-fno-exceptions`, by default, and that this can be turned off explicitly with `set(saucer_exceptions OFF)`. For a team that wants exceptions off across its whole codebase, the default is doing the opposite of what they would expect, so the flag is worth knowing about. Thread safety is listed as well, which matters as soon as the C++ side calls into JavaScript and back from more than one thread.

Embedding, frameless windows and three extension modules

Three capabilities are about the shape of the finished application rather than the web view itself. The first is embedding the front end into the binary, so the application ships as one contained file with no loose assets to deploy. The second is built-in support for frame-less windows and transparency, with the `data-webview` attributes used to make a custom title bar effortless, and the documentation for the window decorations is linked from the feature list. The third is the extension modules, and the readme lists three official ones. The desktop module adds a file picker, mouse position retrieval and URI launch support. The PDF module exports the current page as PDF. And the loop module is described as a legacy loop implementation, with the footnote offering the phrase for lack of a better word, which is a fair warning that a newer option exists. The library also exposes platform specific implementations so that you can tweak it, with the native documentation linked.

Two ways to consume it, and a set of community bindings

The installation section offers the two usual CMake routes. With CPM you point at the repository and a version:

CPMFindPackage(
  NAME           saucer
  VERSION        8.0.5
  GIT_REPOSITORY "https://github.com/saucer/saucer"
)

With FetchContent you declare it and make it available, and then in both cases you link the target with `target_link_libraries(<target> saucer::saucer)`. The version in the examples, 8.0.5, is a detail worth noticing, because the listed releases are 8.0.0, 7.0.0 and 6.0.1, so the tags in the examples are ahead of the release list. On top of the C++ library there is a C interface, and the readme points at bindings for other languages, with Java, PHP and Rust repositories listed, and a note in bold that all bindings are community maintained. That is the arrangement to plan for, since the C interface is the stable contract and the language wrappers are somebody else's work.

A passion project with products built on it

The readme closes with a sponsorship request that says the project is a passion project developed in the author's free time, and then a table of who is using saucer, which names Casterlabs Caffeinated and TopNotify with screenshots. The project is MIT licensed, developed in C++23, mirrors its repository on Codeberg as well as GitHub, and the community channels are a Discord server and a Matrix room. The release cadence is quick, with 8.0.0 in December 2025, 7.0.0 in October 2025 and 6.0.1 in January 2025, and the last push to the repository was on 2026-09-06, so it is maintained without a monthly cadence. The documentation is published on a site of its own with a getting started guide, and the examples directory in the tree holds one folder per feature, with desktop, embedding, expose, loop, multiple and pdf among them, which is a quick way to see what the library can do before reading the prose.

Editorial conclusion

Saucer suits a C++ developer who wants a web front end in a native application without shipping a browser, and it suits anybody who cares about the binary size, since relying on the platform renderer is what keeps a build in the hundreds of kilobytes rather than the tens of megabytes. It is a poor fit if you need one rendering engine everywhere, because the point is that each platform gets its own, and it is a poor fit if you need a stable release line, because the version numbering moves fast, with 8.0.0 in December 2025 after 7.0.0 in October 2025. Before you adopt it, check three things: which backend you will use and whether the platform features you need exist in it, whether you want exceptions and RTTI, since the library is designed to compile with both switched off and the default behaviour catches exceptions thrown in exposed functions, and the version you pin, with the installation examples pointing at 8.0.5 and the last push to the repository on 2026-09-06.

Frequently asked questions

Official sources

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