https://donhopkins.medium.com/alan-kay-on-should-web-browser...

>Alan Kay answered: “Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).”

"virtual machine" is clearly not

that said, i love WASM in the browser, high time wrapping media with code to become "new media" wasn't stuck solely with a choice between JS and "plugins" like Java, Flash, or Silverlight

it's interesting to look back at a few "what might have been" alternate timelines, when the iPhone was intended to launch as an HTML app platform, or Palm Pre (under a former Apple exec, the "pod-father") intended the same with WebOS. if a VM running a web OS shows a PDF or HTML viewer in a frame, versus if a HTML viewer shows a VM running a web OS in a frame...

we're still working on figuring out whether new media and software distribution are the same.

today, writing Swift, or Nim, or whatever LLVM, and getting WASM -- I agree with you, feels like a collective convergence on the next step of common denominator

* note: those are all documents and document workflows with skeuomorphic analogs in the same headspace, and newspaper with "live pictures" has been a sci-fi trope for long enough TV news still can't bring themselves to say "video" (reminding us "movie" is to "moving" as "talkie" was to "talking") so extending document to include "media" is reasonable. but extending that further to be "arbitrary software" is no longer strictly document nor media

And this comes from someone who started with Flash, built actual video editing apps with it, and for the last 25 years build application with "it's not a web app, it's a desktop app that lives in a browser" attitude [1].

Even with Flash we often used hybrid approach where you had two builds from same codebase - a lite version running in the browser and an optional desktop app (AIR) with full functionality. ShareObjects and LocalConnection made this approach extremely feasible as both instances were aware of each other and you could move data and objects between them in real time.

The premise is great, but it was never fully realized - sure you have few outliers like Figma, but building a real "desktop app" in a browser comes with a lot of quirks, and the resulting UX is just terrible in most cases.

[1] just to be clear, there's a huge difference between web page and web app ;D

imo when you start talking about dynamic documents the distinction starts to blur but it should be fine if it's just a few parameters that are meant to be manually updated... beyond that "document" seems like the wrong term (and tech)

those artificial distinctions are essential and perfectly practical as they can convey expectations just fine

GP is correct in that the browser has generalised to a point it has clear drawbacks for its original intended purpose, but that is just a fact of life at this point

IMO, html should have scaled back from 5.0 to the feature-set of 4, if not 3, with mass deprecations and beyond that it shouldn't be called html even if the main browsers carried on adding features and interoperable OS-like characteristics, so people could see beforehand if they were visiting hypertext documents or application sites, because certainly most of the web right now could not be reasonably called "hypertext"

but that isn't the way it was handled and tbh it was to be expected

"What if we made a new WASM-based platform for apps, separate from the browser?"

Heh, reminds me of those boxes Sun used to make that only ran Java. (I don’t know how far down Java actually went; perhaps it was Solaris for the lower layers now that I think about it…)

Secure? Debatable. Functional? Not really.

For example, try accessing a security key and watch the fun. Sure, if you access it exactly the way Google wants you to, things kinda-sorta work, sometimes. If you don't want to obey your Google masters, good luck getting your Bluetooth or USB packet to your security key.

And because you are "secure", you can't store anything on the local hard drive. Oh, and you can't send a real network packet either. All you can do is send a supplication request to a network database owned by somebody else that holds your data--"Please, sir, can I have some more?". The fact that this prevents you from exporting your data away from cloud-centered SaaS providers is purely coincidental, I'm sure. </sarcasm>

So in the name of security we just kneecap the end users--if the users can't do anything, they're secure, right? Diana Moon Glampers would be proud.

This multi-memory setup reminds me of my array juggling I had to do back then. While intellectually challenging it was not fun at all.

With 64-bit addresses, and the requirements for how invalid memory accesses should work, this is no longer possible. AND-masking does not really allow for producing the necessary traps for invalid accesses. So every one now needs some conditional before to validate that this access is in-bounds. The addresses cannot be trivially offset either as they can wrap-around (and/or accidentally hit some other mapping.)

With 64-bit pointers, you can't really reserve all the possible space a pointer might refer to. So you end up doing manual bounds checks.

To operate on any other size, you need to insert extra instructions to mask addresses to the desired size before they are used.

How is that data stored?

Because (2^32)÷(1920×1080×4) = 518 which is still low but not 86 so I'm curious what I'm missing?

https://cheerpj.com/

OTOH you still need to start a wasm runtime first, then import the WASI module into the wasm host.

P.S.: used to tinker with wasmtime and wasmi to add wasm support to my half abandoned deno clone ;) I learned this the hard way

I see good use cases for building entirely in html/JS and also building entirely in WASM.

The only issue is that there’s a performance cost. Not sure how significant it is for typical applications, but it definitely exists.

It’d be nice to have direct DOM access, but if the performance is not a significant problem, then I can see the rationale for not putting in the major amount of work work it’d take to do this.

yes, e.g. with Leptos you don't have to touch JS at all

But further, WASM is more than just a browser thing at this point. You might be running in an environment that has no DOM to speak of (think nodejs). Having this bolted on extension simply for ease of use means you now need to decide how and when you communicate its availability.

And the benefits just aren't there. You can create a DOM exposing library for WASM if you really want to (I believe a few already exist) but you end up with a "what's the point". If you are trying to make some sort of UX framework based on wasm then you probably don't want to actually expose the DOM, you want to expose the framework functions.

https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

> Using them for GUI applications is wild and obviously a bad idea.

I agree it's wild, but bad idea implies there are better options for cross platform applications with the same ease of distribution, and accessibility as the web.

1. Opening the native keyboard and plumbing those events through to the WASM runtime sounds pretty easy. It's probably not cause modern software, but conceptually it should be trivial.. right??

2. In terms of 'the boss' wanting to do 'that one weird thing' that there isn't a library/plugin/whatever for in DearImgui land. If dev time for everything else gets faster, than the 10x cost of that small corner case can be absorbed by net win. Now, I'm pretty sus on the claim everything else gets better today, but we can certainly imagine a world where they do, and it's probably not far away

Our docs (https://docs.wasmtime.dev/stability-tiers.html) put GC at tier 2 with reason "production quality" and I believe the remaining concerns there are that we want to do a semi-space copying implementation rather than current DRC eventually. Nick could say more. But we're spec-compliant as-is and the question was whether we've implemented these features -- which we have :-)

Oops, I did not read that before going ham in the editor. It seems that the files are stored inside the emscripten file system, so they are not lost. I could download my exported 'test.stl' with the following JavaScript code:

    var data = FS.readFile('test.stl');
    var blob = new Blob([data], { type: 'application/octet-stream' });
    var a = document.createElement('a');
    a.href = URL.createObjectURL(blob);
    a.download = 'test.stl';
    a.click();

My argument is that, code that goes on the web-side mostly would adhere to the subset, many of the ref-cases can be statically compiled away and what remains is infrequent enough that for most users it'll be a major win compared to avoid lugging along the GC,etc.

Also just there will be a special version of those language runtimes which probably won't be supported in 10 years time. Just like a lot of languages no longer have up to date versions that can run on the common language runtime.

We're working on WASM for embedded over at atym.io if you're interested.

There is WARDuino (https://github.com/TOPLLab/WARDuino and https://dl.acm.org/doi/10.1145/3357390.3361029).

A runtime that accepts Wasm modules that use a large fraction of the functionality, there is going to be a RAM requirement in the few KiB to few tens of KiB. There seems to be a branch or fork of Wasm3 for Arduino (https://github.com/wasm3/wasm3-arduino).

If you are willing to do, e.g. Wasm -> AVR AOT compilation, then the runtime can be quite small. That basically implies that compilation does not happen on device, but at deployment time.

It's neither directly related to the web, nor is it an assembly syntax.

It's just another virtual ISA. "Direct DOM access for WASM" makes about as much sense as "direct C++ stdlib access for the x86 instruction set" - none ;)

The bottleneck is in the DOM operations themselves, not javascript. This is the reason virtual-dom approaches exist: it is faster to operate on an intermediate representation in JS than the DOM itself, where even reading an attribute might be costly.

WASM isn't going to magically make the DOM go faster. DOM will still be just as slow as it is with Javascript driving it.

WASM is great for heavy-lifting, like implementing FFMPEG in the browser. DOM is still going to be something people (questionably) complain about even if WASM had direct access to it. And WASM isn't only used in the browser, it's also running back-end workloads too where there is no DOM, so a lot of use cases for WASM are already not using DOM at all.

E.g. the "DOM peeps" would need to make it happen, not the "WASM peeps".

But that would be a massive undertaking for minimal benefit. There's much lower hanging fruit in the web-API world to fix (like for instance finally building a proper audio streaming API, because WebAudio is a frigging clusterf*ck, and if any web API would benefit from an even minimal reduction of JS <=> WASM marshalling overhead it would be WebGL2 and WebGPU, not the DOM. But even for WebGL2 and WebGPU the cost inside the browser implementation of those APIs is much higher than the WASM <=> JS marshalling overhead.

Many important libraries have been written in C and only come with a C API. To use those libraries in non-C languages (such as Java) you need a mechanism to call from Java into C APIs, and most non-C language have that feature (e.g. for Java this was called JNI but has now been replaced by this: https://docs.oracle.com/en/java/javase/21/core/foreign-funct...), e.g. C APIs are a sort of lingua franca of the computing world.

The DOM is the same thing as those C libraries, an important library that's only available with an API for a single language, but this language is Javascript instead of C.

To use such a JS library API from a non-JS language you need an FFI mechanism quite similar to the C FFI that's been implemented in most native programming languages. Being able to call efficiently back and forth between WASM and JS is this FFI feature, but you need some minimal JS glue code for marshalling complex arguments between the WASM and JS side (but you also need to do that in native scenarios, for instance you can't directly pass a Java string into a C API).

The good news is that you can use very minimal glue code with just a few functions to do most JavaScript operations

Anyway I am quite sure that you could almost completely get rid of js glue code by importing the static Reflect methods and a few functions like (a,b)=>a+b for the various operators, add a single array/object References to hold refs and you can do pretty much everything from wasm by mixing imported calls

...is already possible, see for instance:

https://rustwasm.github.io/docs/wasm-bindgen/examples/dom.ht...

You don't need to write Javascript to access the DOM. Such bindings still call JS under the hood of course to access the DOM API, but that's an implementation detail which isn't really important for the library user.

Wasm is not now and will never be a magic "press here to replace JS with a new language" button. But it works really well for bringing systems software into a web environment.

1. Non browser application (lightweight cloud, plugins, sandboxing)

2. Performance kernels (like compiling a game/rendering engine or AI stuff)

3. Compiling js-like applications from other languages (eg blazor wasm and others)

The only case where DOM access would be useful is 3 and even there 90% of the gains are already available from the JS-strings proposal to avoid copying+reencoding.

Direct DOM access is otherwise mostly a red herring

https://github.com/emscripten-core/emscripten/blob/main/syst...

Garbage collection is a small part of the go run time, but it's not insignificant.

A: look slow compared to other engines that supported it

B: implement it

Now, stuff like the exception handling stuff and tail calls probably aren't shimmable via JS, but at this point they don't gain much from being obstructionists.

Say you have a WASM module, straight line code that builds a stack, runs quickly because apart from overflow checks it can just truck on.

Now add this JS-Promise thing into the mix:

A: now how does a JS module handle the call into the Wasm module? classic WASM was a synchronous call, now should we change the signature of all wasm functions to async?

B: does the WASM internal calls magically become Promises and awaits (Gonna take a lot of performance out of WASM modules), if not we now have a 2 color function world that needs reconciliation.

C: If we do some magic, where the full frame is paused and stored away, what happens if another JS function then calls into the WASM module and awaits and then the first one resumes? Any stack inside the wasm-memory has now potential race conditions (and potentially security implications). Sure we could make locks on all Wasm entries but that could cause other unintended side-effects.

D: Even if all of the above are solved, there's still the low-level issues of lowlevel stack management for wasm compiled code.

Looking at the mess that is emscripten's current solution to this, I really hope that this proposal gets very well thought out and not just railroaded in because V8's compiler manages to support it because.

1: It has the potential to affect performance for all Wasm code just because people writing Qemu,etc are too lazy to properly abstract resource loading to cooperate with the Wasm model.

2: It can become a burden on the currently thriving Wasm ecosystem with multiple implementations (honestly, stuff like Wasm-GC is less disruptive even if it includes a GC).