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

A sandboxed tab is not a desktop. These commands are unavailable: SYSTEM, the serial port commands (SERIALOPEN and friends), the whole NET… family, 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.

• Networking is off entirely, not only server sockets. NETCONNECT, NETREAD, NETWRITE, NETDATA and NETADDRESS are unavailable alongside NETLISTEN. Loading media over HTTP is a separate path, and that does work — see below.
• Files a program creates with OPEN and WRITE live in an in-browser filesystem rather than on your disk, and last only for the current browser session.
• What you type is kept. Since 2.1.1 every open editor tab survives a refresh, a closed tab or a restarted browser, and so do your preferences. Saving is still a download — this is a safety net, not a replacement for saving. A program opened straight from a link (?run=, ?url=, ?src=) is not autosaved.
• Media loads from your own site. SOUNDLOAD, IMGLOAD and the sprite loads resolve a relative path against the page’s own URL, so sounds/bounce.mp3 is fetched from the server that served the page. That is same-origin by construction; an absolute URL to another host is subject to that site’s CORS policy, exactly like any other browser page.
• 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.
• Speed is still below the native build, though 2.1.1 roughly doubled it — the browser gained more than any other platform.

include is not a limitation any more: the module library is built into the page, so include "math.kbs" means the same thing here as it does on the desktop.

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