BASIC-256 in the browser

Hosting it yourself

Unpack the archive onto any static host served over HTTPS, and make sure the server sends these two headers for that directory:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

They are not optional. The build is multithreaded, so it needs SharedArrayBuffer, which browsers only hand to a cross-origin-isolated page — and the headers are ignored outright on a plain-HTTP origin, which is why HTTPS is part of the requirement rather than a recommendation. Without all of this the page loads and then sits on the Qt logo forever, with nothing in the console to explain why.

Serve .wasm as application/wasm too, or the browser cannot stream-compile it.

With the headers in place the page loads in a single pass, and the coi-serviceworker helper bundled in the archive is not needed — it exists only because GitHub Pages cannot send those headers itself and has to fake isolation with a service worker and a reload.

On Apache, an .htaccess in that directory does it:

Header always set Cross-Origin-Opener-Policy   "same-origin"
Header always set Cross-Origin-Embedder-Policy "require-corp"
AddType application/wasm .wasm

Add folders of your own beside it — /demos, /images, /sounds — and your programs can reach them.

Running a program straight from a link

Once it is hosted, a URL can name a program to run and how to display it — which is what makes it possible to put a working demo in a page or hand a class a single link.

Three ways to name the program:

Dropping a .kbs file on your server does not make it visible to ?run= — that only sees the bundled Examples, and ?url= is what your own files are for. ?url= is restricted to the site serving the page, so a link cannot point the app at somebody else’s server.

Then &mode= chooses the layout, mirroring the desktop command-line switches:

So ?run=BubbleUniverse_variations opens the IDE with the demo loaded and running, and adding &mode=graph gives you the bare canvas with no menus or toolbars — the form to use when embedding a demo in a page.

What a browser cannot do

The browser build is v1 and works, but a sandboxed tab is not a desktop. These commands are unavailable: SYSTEM, the serial port commands (SERIALOPEN and friends), NETSERVER and TCP server sockets, DBOPEN and the SQL statements, and PRINTER…. A program that calls one gets a clear “Feature not available on this platform” error and carries on — it does not crash or hang.

• Files live in an in-browser filesystem rather than on your disk, and anything a program creates lasts only for the current browser session. There is no persistent storage yet.
• include cannot reach the standard library. With no native filesystem to read from, modules such as math.kbs are not available the way they are in every other build.
• Sound and say use the browser’s own audio and speech. The first sound may need you to click or tap the page first — browsers block audio until you interact with them.
• NETREAD is subject to the target site’s CORS policy, exactly like any other browser page.
• Speed is lower than the native build, so large fractals and particle simulations run at a gentler pace.

If any of that matters for what you are writing, the desktop builds have none of these limits.