carado.moe

tammy's blog about
AI alignment, utopia, anthropics, and more;

also on twitter, lesswrong, rss, and at

Saving The Client-Side Web: just WASM and the DOM

the stack of technologies involved in the client side of the web is a huge mess, and i don't like most of it. it requires browsers to implement basically an entire operating system.

i propose here a vision that can vastly simplify the web — especially client-side — allowing clients (and possibly, to an extent, servers) to function much more easily, and all that with mostly just existing tech.

here's the idea:

we keep WebAssembly and we keep the DOM client-side. we discard the textual format that is HTML, and we definitely discard JavaScript. CSS can probly stay.

WebAssembly is quite easy to run in a sandbox; it's much easier to make a WASM VM than a JS VM, it leads to much more optimizable code (though it could be better), and it's easily sandboxed (such that, for example, one WASM can run another WASM with tight control over what calls that sub-instance has access to).

the HTTP server (or whatever content delively system) sends the client a single WASM file, with maybe some parameter data, whose "start" method is called. this method will build up the DOM (using API calls, not textual HTML), request files (images, etc. in whatever order it wants), and so on. it can depend on other WASMs as dependencies, just as many pages with JS currently import jquery or other JS frameworks.

there's no need for clients to know anything about HTML. if you want to serve static HTML, it's probly relatively easy to make a web server that sends a static WASM along with some HTML, and that WASM can parse the HTML and produce the corresponding DOM with API calls; and the browser doesn't have to have any special code for that.

if you want easy javascript (or any other scripting language!) you can just send a static WASM that is a javascript interpreter compiled into WASM, and have that interpret attached JS. there's no need for the browser to know anything about JS, let alone embed a JS VM.

plus, you get all the advantages of WASM: easy implementation, portability, performance, and easy sandboxing (even nested sandboxing!).

as a bonus: if you ship browsers with a WASM handling all the usual JS and HTML interpreting, then you can probly make this whole stack retrocompatible with the old web.