Is anyone developing a SPA package like R/Shiny or Python/Dash?

You could program for the future (don’t we always?), and IE situation might take care of itself in the meantime. When do you expect to have something working? Yes, WebAssembly is a little new, maybe that’s the problem in the short term, but not for most common browsers:

Notably absent, Internet Explorer… might be a problem (it however supports asm.js, if that is an alternative or some way of using as a [restricted?] fallback):
“WebAssembly CG members representing four browsers, Chrome, Edge, Firefox, and WebKit, have reached consensus that the design of the initial (MVP) WebAssembly API and binary format is complete to the extent that no further design work is possible without implementation experience and significant usage. This marks the end of the Browser Preview and signals that browsers can begin shipping WebAssembly on-by-default.”

Enabled by default (launch bug) in:

Chrome for desktop release 57
Chrome for Android release 57

Consensus & Standardization

Firefox: Shipped
Edge: In development
Safari: In development
Web Developers: Positive

@Palli Maybe I’m missing something but I fail to understand the enthusiasm around WebAssembly. Seems more fit for developing apps with a focus on 2D/3D rendering and custom UIs (mostly gaming) – and games were the most (only?) successful showcases of the technology so far.

How do you envision an architecture that addresses our issue? How would you render the UI with pure Julia (I presume that’s the goal with using WebAssembly)? How will it be better than using an HTML and JS UI toolkit?

Probably and/or to compile Julia code to run on the web.

For reusing JavaScript code, then of course not needed (and JS nowadays is fast, that’s not the problem with it).

I’m not up-to-speed on any specific JS code/libraries/frameworks or how SPA is done now.

People often assume JavaScript is the only language that can work on the web (the frontend, even it being brought to the backend), neglecting transpiling to it and now WebAssemby. I just think the latter will be a huge thing - maybe soon.

OK, you compile it, but you still need something that produces a UI. You can use for example the Unreal engine, assuming there’s a Julia interface to Unreal or maybe ccall, but then you’d have to define all the UI elements in Unreal. Overkill.

Sorry for bringing this old subject back to life. Just to check if there is any news or plans regarding this topic.

I have played a bit with Julia and I love it, but when I try to play with JavaScript I suffer. The ecosystem is way too complex for me (not a professional developer). I was pretty happy with Python also. If you want to serve something Genie (or Flask in Python) seem like they are sufficient.

It would be nice being able to perform frontend (web based or mobile) without having to switch programming languages (js, html, css).

Last time I checked, python has made a lot of progress in that regard. Kivy is amazing in that regard. You can use Material Design based widgets with it also. I am not an expert, but it looks like Kivy has been made mixing opengl (from python and cpython), SDL. Another thing that I like from kivy is the way in which the UI can be described by means of the KV language(easier and less verbose than html) and programmatically.

It looks like something like kivy could be made in Julia. Lot of effort I bet.

Other interesting thing that I found is the WebAssembly approach. It seems that something like nanogui might be possible. There exists Charlotte.jl. This mixes GLSL and WebAssembly.

In the future, the DOM might be accesible from WebAssembly. In the short term, in rust there exists wasm-bindgen that enables that access now. Maybe that could be possible from Julia.

Interesting time. Food for though.

Since you reopened this thread I’ll answer… first for the non-WebAssembly example:

Yes, recreating (this or anything) from scratch is possible in theory, but I assume reusing Kivy would then be the better option. Without knowing almost anything on it (first now hearing of its KV language), I’ve suggested that (don’t know that anyone has done or tied that). Maybe there are issues reusing it using PyCall, and using pyjulia is better to use Julia code from Kivy/Python?

Kivy is for mobile: Android and iOS; at first I believe only for that but at least also for Windows, OS X and Linux. Supporting Android fully has special issues of its own (and to be cross-platform across mobile, let alone to desktops too). Only JDK languages have it at the moment, and Go.

Go using gomobile build can also support Android (and iOS) by but any non-JDK language, with or without the help of Go, will at least have some of the same limitations (also Kivy, but it or at least Go should be good enought for most games):

Current limitations are listed below.

  • Only a subset of Go types are currently supported.
  • Language bindings have a performance overhead.
  • There are a few limitations on how the exported APIs should look due to the limitations of the target language.

Right, and that sound very interesting, for web use. Compiling to JavaScript will allow you to have its GC, but while WebAssembly currently doesn’t have GC capability, it may not be a showstopper. You could always distribute one as part of a Julia runtime and it should be able to be smaller than the 60 KB Blazar runtime. I’m just using that as an example for what it possible. As I understand it, it includes a full .NET runtime (“CLR”, not sure if it has JIT; but it must have a GC at least). Julia’s runtime that needs to run in the WebAssemly/browser could be stripped down to just GC. I’m not sure how easy that is or if it’s better to adopt some other GC that already exists. I believe other language target WebAssembly, but I only recall Go, as another language with GC. Rust (and C/C++) also support, and we could reuse all from those three languages, but would still lack GC. One other option is (as with the robotics Julia example) is avoiding the GC. If you can do that then the lack og GC may not be a problem client-side.

Q: Does Blazor compile my entire .NET based app to WebAssembly?

No, a Blazor app consists of normal compiled .NET assemblies that get downloaded and run in a web browser using a WebAssembly based .NET runtime. Only the .NET runtime itself is compiled to WebAssembly. That said

Q: Wouldn’t the app download size be huge if it also includes a .NET runtime?

Not necessarily. .NET runtimes come in all shapes in sizes. Early Blazor prototypes used a compact .NET runtime (including assembly execution, garbage collection, threading) that compiled to a mere 60KB of WebAssembly.

Q: What features will Blazor support?

Blazor will support all of the features of a modern single page app framework:

A component model for building composable UI
Forms and validation
Dependency injection
JavaScript interop
Live reloading in the browser during development
Server-side rendering
Full .NET debugging both in browsers and in the IDE
Rich IntelliSense and tooling
Publishing and app size trimming


Q: Can I use Blazor without running .NET on the server?

Yes […]

[interesting what they build on, seem all platforms are relevant for this project…]

Building the Repo


Run end-to-end tests


Rust has it easier, as it’s a language without GC, so it’s a good fit for WebAssembly. Like I said, we could reuse everything from Rust (just as with C, using same ccallkeyword), and maybe this project fits into our picture, but we still need GC, at least usually, and that project doesn’t predictably seem to fix that issue for us, as Rust has no need for a GC (and I didn’t immediately see anything related to such; I DID notice “Julia set”, and of course that was what’s expected, having noting to do with the Julia language…).

The caveat section is predictable regarding Int64, and IE11 (while not ruling out as WebAssembly doesn’t); but also interesting that wasm-bindgen has an issue with Edge:

Thanks for your reply. It is really amazing what it is being done in all these projects. It is good to see that the GC is just a matter of time.

The possibility of creating a web app using just Julia, defining the UI in something like KV (better fit for UI), sounds really appealing. Just with a transpiling step similar to webpack which bundles the whole web app.

Besides, the new possibility of addressing the mobile world by means of Progressive Web Apps (i.e. telegram). And also the desktop (instead of electron/Blink).

It seems like a beautiful way of using one nice modern language such as Julia (well suited for WebAssembly by the way) where one base code can address: the desktop, the web and mobile. For sure this won’t cover all use cases, but it will cover a lot.

As I said, interesting time. I cannot wait for the coming years.

Well, right, and it will be “Language-independent” while it probably means that it needs to be supported (plugged into) somehow. It’s just unclear to me.

But even while we can wait for it, we need not. I believe, just as with regular assembly (CPUs don’t have GC), we could build, or rather port our own GC (just as Blazor is already working). Just as an implementation was built for Julia (and for each other language, Go, Java etc.).

I don’t know the pros and cons (other than all coding similar stuff, even in the same language C…), of using the “standard” WebAssembly GC vs. other implementaions. I do however understand the need for some of the array of choices you have for e.g. Java, and the same argument could be for alternative GC implementaion, for a better than the standard forthcoming GC, for hard-real-time (I do not expect it to be good for that…).

It’s unclear to me that you even need GC for WebAssemly if you use the “hybrid” approach Charlotte.jl uses, also generating JavaScript.

See also: and

[Some projects are on hold waiting for Julia 1.0; I’m not sure if they’re just dead, redundant with others.]

Let’s say there’s a wait for GC (e.g. by porting) and you really need it for WebAssembly [only or with JS]; it’s unclear to me that compiling to JavaScript alone isn’t good enough, for many. JavaScript is even quite fast. Just not a nice language to use directly.