The core in the browser through WebAssembly

The core runs on the user's device: how the exchange works, what it gives you, and what limits to account for.

What the setup consists of

The core computes on the user’s device. There’s less work for you here than in the other environments: the core arrives together with the page — you don’t have to install it, update it, or restart it after a crash. The scheme has four participants:

Your server — serves the page, the build, and the file, issues the session and permissions, and accepts the saved result.
The browser or WebView — the SumSheet shell and a background thread.
The core in WebAssembly — the workbook session and computation live in the browser’s memory.
Your product — versions, audit, approval routes, notifications.

Where the build comes from

The WebAssembly build of the core and its bridge module ship as SumSheet engine packages — a separate delivery artifact, see What is delivered. They’re not in the desktop installer: that has the native processor, which doesn’t run in the browser.

What’s available in the browser

The operation set is the same as in the desktop app: the browser build accepts the same contract requests and passes them to the same core — it has no trimmed-down list of its own.

One caveat, and it’s not about the environment. Anything that touches the network — Postgres and SQL Server connections, https requests — doesn’t work in the browser. The reason is the same as everywhere else: the core has no network of its own, and it asks whoever’s nearby to go fetch. In the desktop app, a host sits nearby and answers such requests; in the browser, the bridge is responsible only for passing requests along and the session’s lifetime, and there’s no one there to serve the request. The operations still exist and refuse honestly — why, and with what codes.

The browser’s other limits are about the environment: memory, threads, and first-load time.

Which workbooks the browser won’t take

These limits aren’t vague: the core checks the workbook against them before parsing, and on overflow it responds with the wasm-memory-envelope-exceeded refusal, naming both the limit that was broken and the actual value in the details.

Limit	Value
Workbook file size	256 MB
Rows per sheet	1 000 000
Filled cells	8 000 000
Estimated peak memory	1.5 GB

All four are calculated from the environment’s ceiling: wasm32’s address space is 4 GB for everything, including the build itself and working structures, and the margin is left deliberately. The desktop app and the server have none of these limits — there, only the machine limits the workbook.

How the exchange works

The shell talks to the WebAssembly session, which remembers the workbook’s state between calls. The workbook stays in the tab’s or background thread’s memory, and the file only goes to your server on open and save, or on a separately agreed event.

Strength	Cost / limit
The document is processed without going out to any external cloud.	Memory and processing power are limited by the device and the browser.
There’s almost no delay between the user’s action and the core.	The first load of the code and opening a large workbook take time you need to budget for.
The same behavior with or without a network.	Vector computation (SIMD) isn’t in every browser, and multithreading needs all three conditions at once: the site is origin-isolated with two headers — COOP and COEP; the browser supports SIMD (the multithreaded core is built only for that variant); and the delivery has the multithreaded core itself — a separate build, not the one that ships by default. If any one is missing, the core falls back to the single-threaded variant and names the reason, down to `simd-required-for-threaded-core` and `threaded-core-artifact-not-built`. The ordinary build needs none of this.
Your server is simpler: storage, sign-in, and versions.	Long operations need to move to a background thread, be cancelable, and account for the tab possibly being closed.