The beauty of WebAssembly is that you don't need Google's permission to add support. Just send your Wasm blob to the browser and Chrome's existing Wasm runtime will just run it.

My knowledge is years out of date, but does WASM still require the application to request its maximum memory footprint up-front? Granted, that's what Sun/Oracle's JVM has been doing to allocate its heap from the OS for well over a decade, but I'm also not aware if WASM is able to use the equivalent of madvise() to tell the browser/OS that it's fine to unmap a region of memory and map it back zeroed-out when it's next needed.

Yep you need to specify the maximum memory amount up-front. Its defined as "webassembly memory pages". Each page is 64kb. You need to specify an initial and a maximum amount. The webassembly module can call memory.grow() to grow it by a page until it reaches the maximum. Though you can't "un-grow" or decrease the amount of allocated memory.

This is not correct, it is not necessary to specify a maximum memory size. See the WebAssembly specification https://webassembly.github.io/spec/core/syntax/modules.html#.... Due to 32-bit address space, the maximum memory is limited to 4GB however.

(In asm.js, memory was provided by an ArrayBuffer of fixed size, so there memory could truly not grow at runtime.)

You'd need a pretty solid reason to want users to download the Python engine to run your code in their browser every time they visit an updated version of your site though. "I like writing Python better than JS" would be a sucky excuse.

If anyone does choose to do this I hope they spend significant amount of effort making their caching and code splitting optimal.

Given that there were people paying ActiveState for their Python ActiveX, I assume there are enough people that care enough for such use cases.

Many devs already make me download their SPA to display static text and images.

Say what you will about Jupyter notebooks and all that, but the talent pool for Python is still at a higher level. Then, this could be the worse-is-better equilibrium, but there's also a market-for-lemons situation regarding web dev these days.

https://en.wikipedia.org/wiki/The_Market_for_Lemons

My impression was that top-dollar was being payed for web-devs, with competition from some of the biggest tech giants driving the trend. Not sure that's a market for lemons, unless you are talking about the lower-end of web dev.

What the caching story like? Is it possible to cache the Python interpreter in one (unchanging between apps) blob and then send another blob with your app-specific code? I’m imagining a world where lots of apps want to use WASM Python but don’t want to have to ship the whole interpreter with their page.

Cross-Origin resource caching has been disabled by all modern browsers by now. So your page could use the same cached Python interpreter again and again, but you and example.com would each have to download the interpreter, even if it comes from the same URL.

With normal Wasm blobs that’s more of an issue. It wouldn’t be an issue in this case because you would just pass your Python script in as text.

There is this: https://pyodide.org/en/stable/console.html Not sure what you mean by python in chromium however, I assume, pyiodide may already be doing this.

I want Python to be used the same way JS is used. As in a native 3.7 interrupter in Chrome

I don’t see how that could be done without nerfing a lot of the power of JS. JS was bred by the web and is entirely async. Python has no concept of callbacks or promises etc. JS is perfect for frontend design because that’s what it was created from the ground up for

Python has always had the ability to do callbacks (ie. first class functions), though admittedly it's not a common pattern and the stdlib doesn't support it for IO (also its anonymous function syntax is poor).

There have been several libraries that provide the concept of a promise, but with modern python these are built into the stdlib with native async/await support, though many interfaces are still sync-only (though you can work around that with things like gevent that monkey-patch those interfaces to work with an event loop under the hood).

I agree that python would be a poor fit for the kind of uses that JS in the browser usually serve, but it's really a matter of ecosystem, not core language design.

Python would be optional here.

You could still use JS while Python support catches up.

They did wasm to not do it and have it at the same time.

What they can do is to provide GC to unbloat a lot of those runtimes I guess.

i don't know the story under wasm, but i looked into what it would take to embed python into a browser years ago.

the hard part at the time was obviously all the hooks between the dom and the javascript runtime as well as concurrency story. python 2 was not built to be driven by callbacks, which is how the whole browser/javascript ecosystem works.