Are there plans to do so? I think it may open up new horizons: web UIs, …
1 Like
https://github.com/Keno/julia-wasm
and I think (literally) transpile to JS is in general impossible.
4 Likes
I am asking because I just saw the VPython’s successful branching out into collaboration with JS (and the WebGL enabled by this marriage of convenience).
If the transpilation of Julia to JS was really impossible, that would be a pity.
Another option would be to compile a web engine together with julia and an interface to manipulate the document object model directly from julia. That would make it possible to build nice user interfaces based on web technologies without going via javascript.
(This wouldn’t be a web browser. It would only run julia code supplied by the user, so one would not have to worry about all the security implications of running potentially malicious code.)
2 Likes
Julia transpile (btw: why trans? it’s called compile) to anything would include a method to compile to static code and that would limit/exclude a long list of optimizations.
What would that give you that a wasm compiler target wouldn’t?
Access to JS libraries?
1 Like
You can call JS from wasm, not a problem. The issue is just the maturity of the platform.
5 Likes
Is there something in wasm preventing it working as a full featured julia compilation target? Curious what the state of julia-wasm is.
1 Like
It needs some features in wasm that are implemented, but experimental. Last I tried (about 6 months ago), the browsers liked to crash on our wasm output. I filed relevant bugs, so my hope is that when I have the time to look again, it’ll just work.
9 Likes
btw: why trans? it’s called compile
I think because not exactly translation nor compilation. Source-to-source translation implies that a human might look at the result, or interact with it in some way before compiling it. They want source. Otherwise they should just compile directly to a linkable library (e.g. *.so object code). And traditionally, compilation refers to converting source into (non-readable) object code.
Here, translation is done to JS but with no interest in human reading. It’s meant to be executed (by a browser), and yet it’s neither object nor machine code. But it’s roughly equivalent to a platform-independent object code, made fast by good interpreters/JITs. See Gary Bernhardt’s talk about this very topic.
Nowadays, the lines are quite blurry. Machine code isn’t what it used to be, because underneath it is not “bare metal” but more layers of interpretation, e.g. micro-code or micro-operations. The CPU is interpreting instructions and doing all sorts of re-ordering, branch prediction, pipelining, cache management, etc. So maybe we should do away with the word compilation, since it’s turtles many levels down. (There is bare metal down there, somewhere.) But almost everything these days is interpretation or a translation (transpilation?) to another intermediate representation.
2 Likes