How does a NoDOM app load?

Initially the NoDOM app loading process is very similar to that of an SPA app; however, things diverge when we get to loading wasm. Before we get into more detail, a note on terminology. We use canonical names for the first three files loaded by HTTP: shell.html, nodom.js and nodom.wasm. You'll see the names vary across the example apps. One factor that drives that variance is the use of DuckDB. The example add_server app doesn't use a bulk cache for instance. The important point to remember about those canonical names is that they define the roles of the files.

shell.html: called shell.html because it is the shell for the app loading process. shell.html has minimal HTML: body has only two child elements, canvas and script. It's primary purpose is to load nodom.js

nodom.js: think of nodom.js as a dynamic linker loading a DLL or .so. In this case the DLL is nodom.wasm, which has the NoDOM render engine.nodom.js downloads nodom.wasm, and invokes Chrome's WebAssembly API to load and link the wasm. If you look towards the bottom of nodom.js, you'll see the JS code that does callMain(args); this is where control passes to C++ wasm, and is the end of the conventional HTML page load. Continue below this diagram for more detail on the WebSock stage of the loading process.

nodom.wasm is compiled from C++ by emscripten's emcc, which uses clang. This is where the heavy lifting happens.

The first thing nodom.wasm does after init is to request data and layout from the server. Naturally, CORS means we cannot open a websock to a different server, so nodom.wasm will hit the same endpoint that served it for the app description JSON.