I thought this article on WASM and Julia was interesting and a good idea - maybe even inevitable. This is a short excerpt:
Julia in WebAssembly by Raymond Minor Huffman
B.S. in Computer Science and Engineering
Massachusetts Institute of Technology (2022)
"WASM support for Julia would enable applications written in Julia to run natively in a web browser without the need for users to download and install a local copy of Julia. As an example, consider interactive notebooks like Jupyter and Pluto.jl. To view and interact with these notebooks, users must install a local copy of Julia, install all the notebook’s required packages, and have some ability to debug any issues related to this installation process. With WASM support, users could open Julia notebook directly in their web browser without the need to install any software.This would also expand support to platforms like iOS, Android, and ChromeOS that do not have native Julia support.
In addition to interactive notebooks, any web application that would currently offload complex computation to a backend server could instead implement that logic in Julia and execute it locally on the user’s device. Applications such as image processing, generating charts and figures, and solving differential equations are just a few examples.
Researching this further, it seems that there are barriers - Julia’s JIT compiler is one of its great strengths, but it prevents programs from being compiled into small and easily distributed binaries. Also, Julia relies on an asynchronous task runtime, and WebAssembly currently lacks native support for managing task stacks in the WASM heap. This would require Julia to explicitly manage task stacks and perform compiler transformations, which would impact the performance of Julia on the WASM platform.
I dont know, if that is any help, and it would obviously not help to run in the browser, but there is a wasm implementation for the server, that runs all its tasks async: https://lunatic.solutions/
Since you’re new here, no currently not trivial to get AOT compilation, at least that way, just with a switch to the REPL, though something equivalent is possible, already, plus AOT compilation is however coming with upcoming juliac, then with much smaller binaries than already possible with PackageCompiler.jl. Both have basically no limitations on Julia features, and there are also other limited options.
So the former is getting solved, and maybe also the latter, I’m not up-to-speed on all the WASM work for Julia, I think they are still mostly demos, nobody using in production (also I think actually still relatively few using WASM without Julia…).
Worth mentioning the proprietary AOT compiler SyslabCC, which answers the question of possibility and helps explains some of the limitations that trimmed executables must have. The type stability requirement in particular is important for limiting executable size; 11:11 of the talk introducing the development of juliac explains that dynamic dispatches with few enough options could be feasible, but otherwise supporting too many runtime branches requires too much AOT-compilation. In fact, JIT compilation is usually more efficient by compiling anything that is called in a session, not everything that could be. An AOT compiler can support dynamic features like JIT compilation, but it also needs the memory and runtime overheads, as PackageCompiler.jl and JuliaScript.jl demonstrate.
AOT-only compilation is not a desirable setting for a REPL or any interactive shell. Any new code you write can’t be compiled interactively and at best gets interpreted a la default Debugger.jl, which is slow. Interactive work requires metadata like module namespaces and method tables, which you would want to trim out for minimal executables; 9:36 of the juliac talk explains limitations that comes with trimming. An AOT-only REPL would have less overhead, but it’s still too much for the small executable crowd, and everyone else has better options. We already AOT-compile code per package, which unlike other AOT compilation approaches mentioned so far has the necessary conditions to import them interactively in a REPL.