WebFront C++23Volume II / CHAPTER 01
For understanding and contributing
Going further
We have learned to use WebFront. Now let us look at what happens on the other side of its functions.
Notation conventions
Function names, types, commands, options and filenames appear in monospace, for example describe, wf test or main.cpp. Italics introduce a term at its definition. Code blocks give the fragments to enter; the preceding text states their location and prerequisites.
- C++ application
- HTTP / WebSocket core
- Bridge and browser page
The frontend opens the page; the resource provider supplies HTTP. Bridge calls travel in both directions.
From the example to the implementation
When we write app.show(), a page opens and our program can receive calls from the browser. That line is convenient precisely because it lets us ignore a good deal of work. To understand WebFront, we shall go back through that work, one operation at a time.
This second volume is for you if you want to know what lies behind a call, find the cause of unexpected behaviour or change the framework. We shall use the first volume’s examples as small programs to examine.
Some familiarity with C++ and object lifetimes will help. Browser-specific ideas will be introduced as we need them.
Opening the page
Let us start by opening the application. The browser requests a page, followed by its scripts and other resources. The C++ server answers these HTTP requests. A WebSocket connection then lets the page and program continue exchanging messages without reloading the document for every call.
We have already encountered two parts of the system: the C++ core and code running in the browser. During development, a third part supplies the terminal, TypeScript compiler and test tools. This environment is loaded on demand; a distributed application can run without it.
We shall find these parts in the repository by following the resources and messages they exchange. That will give us a reason to visit each file.
Finding a route through the code
A first reading of WebFront.hpp can make everything seem to arrive at once: templates, connections, callbacks and asynchronous tasks. We need not understand all of it before continuing. Instead, let us choose a familiar operation, such as the click that requests a Game of Life generation.
We can follow its message from JavaScript to the C++ function and return with the result. At each step, we shall look for the object retaining the data and what allows the next step to proceed. If the window closes during the wait, we shall also need to understand what becomes of that data.
The chapters follow this thread: construct the objects, carry a call and then finish whatever remains in progress.
Reading the documents alongside the implementation
An explanation is easier to follow when its links keep leading to the same code. Links in this volume therefore target revision 056d0c8, dated 5 November 2026. The first volume’s examples remain based on version 0.7.0. The revision studied here also contains work that has not yet appeared in a release.
Guides describe interfaces in detail. Architecture decision records, or ADRs, explain why a solution was chosen and which alternatives were considered. We shall return to them when a choice helps explain the code.
An ADR may also describe a proposal. Its status matters as much as its text: to establish what the studied revision does, we shall compare the document with the implementation and tests.
Check your understanding