Dart could very well end up being the secret weapon behind Flutter. Not only does Dart compile to JavaScript -- it's done this from day 1 -- but it also compiles to ARM binary via LLVM for iOS applications... meaning that compiling to WASM should be a trivial option to enable bringing near-native computational speeds to any targeted platform.
> but it also compiles to ARM binary via LLVM for iOS applications
[disclaimer: I am TL for Dart Native Compilers]
We currently don't use LLVM for compiling Dart to native and we actually never used it in production - though we previously built couple of prototypes to evaluate potential benefits of using LLVM.
We use our own AOT compilation toolchain which has roots in our JIT compiler for Dart.
> meaning that compiling to WASM should be a trivial option
It's not really trivial because you still need to figure out some things - most importantly GC. On ARM you can scan the stack - on WASM you can't. They are working on GC support from WASM, but I don't think it is ready yet. And some things are just unfortunate (e.g. i31ref type which mimics V8's SMI - Dart SMI's are 63-bit on 64-bit platforms).
In the two experiments that we did LLVM brought only marginal benefits so we could not warrant the huge dependency and associated maintenance costs. We already have a good compilation pipeline, which was developed for the JIT mode and we use that for AOT with good results. Adding LLVM on top increases complexity - suddenly to tweak things you need to be an expert both in our compilation pipeline and LLVM (which is probably 100x larger than the whole Dart VM source code).
A lot of optimizations which benefit Dart code size and performance require high level optimizations anyway, so having LLVM does not help you in any way.
That said there are obvious benefits for having LLVM as a backend - so we are planning to explore it yet again in the near future.
